Copr build produces two SRPM files

[penguinpee]

I rebuild spyder to see if updated dependencies would have any impact on the package. To my surprise, I found two SRPM files in the results dir:

• spyder-6.0.0~a1-13.20240115gitv6.0.0a1.fc40.src.rpm
• spyder-6.0.0~a1-13.20240117gitv6.0.0a1.fc40.src.rpm

The date, included in the version/release string for pre-releases, is different. I haven't looked at the contents of either of those files, yet. It looks like the %autorelease expansion, possibly in combination with forge macros, has gone wrong.

The spec file uses both:

Name:           spyder
Version:        6.0.0~a1
Release:        %autorelease
Summary:        Scientific Python Development Environment
%global tag v%{version_no_tilde %{quote:%nil}}
%forgemeta
License:        MIT
URL:            https://www.spyder-ide.org/
Source:         %forgesource

[nikromen]

Hello, I was trying to reproduce this one for a while but without success. I can't reproduce it locally inside container either on our prod https://copr.fedorainfracloud.org/coprs/nikromen/playground/build/7095409/ and stg instance https://copr.stg.fedoraproject.org/coprs/nikromen/playground/build/2917394/

Probably this was resolved in the latest copr release?

Please let me know if the issue happens again

[praiskup]

Have you tried that with the same package? This should be totally reproducible.

[penguinpee]

I just tried with the current rawhide and also by resubmitting the original build, the one I linked in this issue. However, currently both builds fail on appstream validation. I'll see if I can figure out why and how to fix that.

[penguinpee]

I simply skipped the entire %check part and rebuilt spyder. No duplicate SRPM this time. However, the build that lead to this issue is still there, if you feel like poking it a bit more.

[nikromen]

Have you tried that with the same package? This should be totally reproducible.

Yes, please look at the linked builds - I used the same build method, and package (and hopefully commit). The build failed for some reason but the SRPM build succeeded with only 1 srpm. I got the same result locally. I don't know what other way to try it to reproduce it.

However, the build that lead to this issue is still there, if you feel like poking it a bit more.

I tried to rebuild it but without the duplicate SRPM, maybe there's a way how to reproduce it but right now I don't know how to :/ So it seems to me like it got fixed in previous release

[FrostyX]

@praiskup I created a reliable reproducer. I based it on the hello package and didn't use the %forgemeta macro, so it is minimal and easily understandable.

## START: Set by rpmautospec
## (rpmautospec version 0.6.1)
## RPMAUTOSPEC: autorelease, autochangelog
%define autorelease(e:s:pb:n) %{?-p:0.}%{lua:
    -- Packages use something like this:
    -- release_number = 18;
    -- base_release_number = tonumber(rpm.expand("%{?-b*}%{!?-b:1}"));
    -- print(release_number + base_release_number - 1);

    -- But a more reliable reproducer is the following
    print(os.time())
}%{?-e:.%{-e*}}%{?-s:.%{-s*}}%{!?-n:%{?dist}}
## END: Set by rpmautospec

Name:           hello
Version:        2.12.1
Release:        %autorelease
Summary:        Prints a familiar, friendly greeting
# All code is GPLv3+.
# Parts of the documentation are under GFDL
License:        GPL-3.0-or-later AND GFDL-1.3-or-later
URL:            https://www.gnu.org/software/hello/
Source0:        https://ftp.gnu.org/gnu/hello/hello-%{version}.tar.gz

BuildRequires:  gcc
BuildRequires:  gnupg2
BuildRequires:  make
Recommends:     info
Provides:       bundled(gnulib)

%description
The GNU Hello program produces a familiar, friendly greeting.
Yes, this is another implementation of the classic program that
prints “Hello, world!” when you run it.

However, unlike the minimal version often seen, GNU Hello processes
its argument list to modify its behavior, supports greetings in many
languages, and so on. The primary purpose of GNU Hello is to
demonstrate how to write other programs that do these things; it
serves as a model for GNU coding standards and GNU maintainer
practices.


%prep
%setup -q


%build
%configure
%make_build


%install
%make_install
rm -f %{buildroot}%{_infodir}/dir
%find_lang hello


%files -f hello.lang
%license COPYING
%{_mandir}/man1/hello.1*
%{_bindir}/hello
%{_infodir}/hello.info*


%changelog
%autochangelog

In Copr it reliably produces two SRPM files in the resultdir. However, locally in Mock the result is:

$ mock -r fedora-39-x86_64 ~/rpmbuild/SRPMS/hello-2.12.1-1709636826.fc39.src.rpm
...

$ ls /var/lib/mock/fedora-39-x86_64/result |grep src
hello-2.12.1-1709637124.fc39.src.rpm

Only one SRPM file, so the bug is probably in Copr code, not in Mock. However, notice the different release number in the result but that's probably okay.

[FrostyX]

However, locally in Mock the result is:
Only one SRPM file, so the bug is probably in Copr code, not in Mock.

Not true, I was reproducing it incorrectly. The issue happens only when Mock is called with --spec and --sources. I reported this as a Mock issue - rpm-software-management/mock#1344

So anyone interested, please follow that one. I am closing this issue since there is nothing we can do about it in Copr, only wait until it gets fixed in Mock.