I've got the same issue:
http://copr-dist-git.fedorainfracloud.org/per-task-logs/582235.log

It seems the spec parsing has changed recently, because I managed to build the previous version of the package (with a similar spec file) in the past without issues.

It is IMO mistake to parse the spec file on dist-git side (where we can not
guarantee all the dependencies in general) to get the package name.

When we already have spec_path, why not to get the package name from spec file?

(In reply to Pavel Raiskup from comment #2)
> It is IMO mistake to parse the spec file on dist-git side (where we can not
> guarantee all the dependencies in general) to get the package name.
Exactly!
> 
> When we already have spec_path, why not to get the package name from spec
> file?
you mean to s/\.spec$// ? I think there are problems in mock-scm / tito / whatsoever. But in case of plain SRPMs, it is correct approach.

(In reply to Igor Gnatenko from comment #3)
> you mean to s/\.spec$// ?

Yes.

> I think there are problems in mock-scm / tito / whatsoever. But in case of
> plain SRPMs, it is correct approach.

Well, I don't know what problems.  All the methods should still have specfile,
or?

(In reply to Julius Schwartzenberg from comment #1)
> I've got the same issue:
> http://copr-dist-git.fedorainfracloud.org/per-task-logs/582235.log
> 
> It seems the spec parsing has changed recently, because I managed to build
> the previous version of the package (with a similar spec file) in the past
> without issues.

The problem with the spec in build 582235 is that in the spec, there are 'if' conditions like 

if %{rhel}

or if 0%{rhel}

It will work if the conditions are changed to: if 0%{?rhel}

(In reply to Igor Gnatenko from comment #0)
> https://copr.fedorainfracloud.org/coprs/g/rust/playground/build/582231/
> 
> ---
> 
> Downloading
> https://copr.fedorainfracloud.org/tmp/tmpY4pqmB/rust-bytecount-0.1.7-1.fc27.
> src.rpm
> https://copr.fedorainfracloud.org/tmp/tmpY4pqmB/rust-bytecount-0.1.7-1.fc27.
> src.rpm
> Extracting srpm
> package_content: PackageContent({'spec_path':
> '/tmp/tmpGj3KZs/rust-bytecount.spec', 'extra_content':
> ['/tmp/tmpGj3KZs/bytecount-0.1.7.crate',
> '/tmp/tmpGj3KZs/bytecount-0.1.7-fix-metadata.diff'], 'source_paths':
> ['/tmp/tmpGj3KZs/rust-bytecount-0.1.7-1.fc27.src.rpm']})
> Could not parse /tmp/tmpGj3KZs/rust-bytecount.spec with error can't parse
> specfile
> 
> Exception raised during package import.
> Traceback (most recent call last):
>   File "/usr/share/copr/dist_git/importer.py", line 94, in do_import
>     package_content
>   File "/usr/share/copr/dist_git/helpers.py", line 40, in wrapper
>     return f(*args, **kwargs)
>   File "/usr/share/copr/dist_git/package_import.py", line 156, in
> import_package
>     pkg_name = helpers.get_package_name(package_content.spec_path)
>   File "/usr/share/copr/dist_git/helpers.py", line 311, in get_package_name
>     "Could not get package name from {}.".format(spec_path))
> PackageNameCouldNotBeObtainedException: Could not get package name from
> /tmp/tmpGj3KZs/rust-bytecount.spec.
> sending a responses for branches master, f26, f25
> Sending back: 
> {"branch": "master", "task_id": "582231", "error": "Could not import this
> branch."}
> Sending back: 
> {"branch": "f26", "task_id": "582231", "error": "Could not import this
> branch."}
> Sending back: 
> {"branch": "f25", "task_id": "582231", "error": "Could not import this
> branch."}
> 
> ---
> 
> I guess it is failing on parsing rich dependencies, so it is regression and
> blocks Rust SIG to build packages in COPR (again).

The spec file is not provided as an attachment but you probably use a macro in Name: and rpm experimental features at the same time.

It must always be possible to acquire package name. This is done by parsing spec file.

There is a regular expression fallback for cases when the spec file is not parsable but it does not do macro substitutions. The solution is not to use macro in Name: when you supply unparsable specfile. I understand this is a limitation but I think it's an acceptable one.

Can you, please, provide the specfile here so that I can see your use-case for using macros in name?

> It must always be possible to acquire package name.

Accepted.

> This is done by parsing spec file.

This is not clear.  Spec file name is name of package.  If not from the builder
POV, then from the dist-git POV.  In other words, even if I submit package
sclo-postgresql96-postgresql.src.rpm for build I want to import into
postgresql module name (because there's postgresql.spec).

I haven't studied this particular spec file (maybe that build failed
anyways)...  but as I claimed in https://pagure.io/copr/copr/issue/102 --
having such details like git import hardwired directly in dist-git code
makes it very, very hard to reproduce outside copr; and it is almost
impossible to debug issues _in specfiles_ for users.  IMVHO, to avoid all
of this burden, everything else than glob('*.spec')[0] should go out from
copr; either into rpkg, pyrpkg or at least separate and reproducible
script for the time being.

(In reply to Pavel Raiskup from comment #7)
> > This is done by parsing spec file.
> 
> This is not clear.  Spec file name is name of package.  If not from the
> builder
> POV, then from the dist-git POV.  In other words, even if I submit package
> sclo-postgresql96-postgresql.src.rpm for build I want to import into
> postgresql module name (because there's postgresql.spec).

Actually, it doesn't have to be (though enforced by Fedora Packaging Guidelines).

> Actually, it doesn't have to be

I don't understand.  What could happen if we imported 'foo.spec'
into foo.git, even when it generated 'Name: %{?scl_prefix}baz'?

That's what we do everywhere else...

> I don't understand.  What could happen if we imported 'foo.spec'
> into foo.git, even when it generated 'Name: %{?scl_prefix}baz'?

I mean, I hope you don't you want to mismatch dist-git for this package
with completely different package 'baz' coming from spec file named
'baz.spec'.

(In reply to Pavel Raiskup from comment #9)
> > Actually, it doesn't have to be
> 
> I don't understand.  What could happen if we imported 'foo.spec'
> into foo.git, even when it generated 'Name: %{?scl_prefix}baz'?
> 
> That's what we do everywhere else...

Nothing bad, I'm fine with this behavior. @clime didn't like this approach ;)

In theory, SRPM names might collide after all.

And also, please keep SCL stuff as much away as possible from me ;)

(In reply to Pavel Raiskup from comment #10)
> > I don't understand.  What could happen if we imported 'foo.spec'
> > into foo.git, even when it generated 'Name: %{?scl_prefix}baz'?
> 
> I mean, I hope you don't you want to mismatch dist-git for this package
> with completely different package 'baz' coming from spec file named
> 'baz.spec'.

depends, I don't know what are the reasons behind. Moreover, I don't want to know. myself I would prefer to have one single dist-git repository for one COPR repository.

So since @clime wanted me to file my use-case here:

We have everywhere Name: rust-%{crate} and we don't care how it will be stored in COPR. We use some special RPM features in BuildRequires/Requires, so Fedora's RPM can't parse such specfiles.

Our typical specfile look like:

# Generated by rust2rpm
%bcond_without check

%global crate ripgrep

Name:           rust-%{crate}
Version:        0.5.2
Release:        3%{?dist}
Summary:        Line oriented search tool using Rust's regex library

License:        Unlicense or MIT
URL:            https://crates.io/crates/ripgrep
Source0:        https://crates.io/api/v1/crates/%{crate}/%{version}/download#/%{crate}-%{version}.crate
# Initial patched metadata
# * No simd
# * No paths
# * Bump encoding_rs to 0.6, https://github.com/BurntSushi/ripgrep/pull/518
Patch0:         ripgrep-0.5.2-fix-metadata.diff

ExclusiveArch:  %{rust_arches}

BuildRequires:  rust-packaging
# [dependencies]
BuildRequires:  (crate(atty) >= 0.2.2 with crate(atty) < 0.3.0)
BuildRequires:  (crate(bytecount) >= 0.1.4 with crate(bytecount) < 0.2.0)
BuildRequires:  (crate(clap) >= 2.24.1 with crate(clap) < 3.0.0)
BuildRequires:  (crate(encoding_rs) >= 0.6.0 with crate(encoding_rs) < 0.7.0)
BuildRequires:  (crate(env_logger) >= 0.4.0 with crate(env_logger) < 0.5.0)
BuildRequires:  (crate(grep) >= 0.1.5 with crate(grep) < 0.2.0)
BuildRequires:  (crate(ignore) >= 0.2.0 with crate(ignore) < 0.3.0)
BuildRequires:  (crate(lazy_static) >= 0.2.0 with crate(lazy_static) < 0.3.0)
BuildRequires:  (crate(libc) >= 0.2.0 with crate(libc) < 0.3.0)
BuildRequires:  (crate(log) >= 0.3.0 with crate(log) < 0.4.0)
BuildRequires:  (crate(memchr) >= 1.0.0 with crate(memchr) < 2.0.0)
BuildRequires:  (crate(memmap) >= 0.5.0 with crate(memmap) < 0.6.0)
BuildRequires:  (crate(num_cpus) >= 1.0.0 with crate(num_cpus) < 2.0.0)
BuildRequires:  (crate(regex) >= 0.2.1 with crate(regex) < 0.3.0)
BuildRequires:  (crate(same-file) >= 0.1.1 with crate(same-file) < 0.2.0)
BuildRequires:  (crate(termcolor) >= 0.3.0 with crate(termcolor) < 0.4.0)
# [build-dependencies]
BuildRequires:  (crate(clap) >= 2.24.1 with crate(clap) < 3.0.0)
BuildRequires:  (crate(lazy_static) >= 0.2.0 with crate(lazy_static) < 0.3.0)

%description
%{summary}.

%package     -n %{crate}
Summary:        %{summary}

%description -n %{crate}
Line oriented search tool using Rust's regex library. Combines
the raw performance of grep with the usability of the silver searcher.

%prep
%autosetup -n %{crate}-%{version} -p1
%cargo_prep

%build
%cargo_build

%install
%cargo_install
install -D -p -m0644 doc/rg.1 %{buildroot}%{_mandir}/man1/rg.1

%if %{with check}
%check
%cargo_test
%endif

%files       -n %{crate}
%license LICENSE-MIT UNLICENSE COPYING
%doc README.md CHANGELOG.md
%{_bindir}/rg
%{_mandir}/man1/rg.1*

%changelog

Fixed by https://pagure.io/copr/copr/c/fc3cd9784ac19e0ee202e417c964000300b5100f.

New COPR version has been released.