error: Bad source: ./Scalar-List-Utils-1.62.tar.gz: No such file or directory

[adelton]

In https://bugzilla.redhat.com/show_bug.cgi?id=2065327, the attempt to scratch build the new version of package failed with

BuilderException: Build started, but failure happened during post build operations:
Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-yuvcgwi8/perl-Scalar-List-Utils.spec']' returned non-zero exit status 1.

StdOut:
error: Bad source: ./Scalar-List-Utils-1.62.tar.gz: No such file or directory


Traceback:
  File "/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build
    result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line 188, in build
    raise BuilderException(

I would expect the tool that tries to do that rebuild to fetch the sources with something like spectool -g *.spec.

[Zlopez]

These are the commands that are ran by the-new-hotness:

git clone <dist_git>
rpmdev-bumpspec --new <version> --c "Update to <version> (#<bug_id>)" --u <hotness_user> <specfile>
fedpkg --user hotness sources
spectool -g <specfile>
rpmbuild -D _sourcedir -D _topdir --bs <specfile>

As you can see the spectool -g <specfile> is executed just before the build. Maybe trying it manually will show you what was actually happened.

[adelton]

In my case the result is

I assume there is some cd there to the checkout directory or that fedpkg sources does not work.

That spectool -g gives me

Downloading: https://cpan.metacpan.org/authors/id/P/PE/PEVANS/Scalar-List-Utils-1.62.tar.gz
100% of 173.6 KiB |######################| Elapsed Time: 0:00:00 Time:  0:00:00
Downloaded: Scalar-List-Utils-1.62.tar.gz

But then

# rpmbuild -D _sourcedir -D _topdir --bs perl-Scalar-List-Utils.spec 
error: Macro %_sourcedir has empty body

Are the the log from the actual runs available somewhere, so that we can check what exactly happened for that https://bugzilla.redhat.com/show_bug.cgi?id=2065327#c1 ?

[Zlopez]

This is a different error I see. The logs are available on OpenShift node, but the sheer amount of messages that are processed by hotness make it hard to find the exact error.

My guess would be that there was some issue when downloading the source and thus the source wasn't available. This is not something that happens often, but sometimes it does.

But what I noticed is that the traceback is not posted in full. Which is something I should probably address.

[Zlopez]

I checked the log now and there isn't any additional info (just the error message you got, but the log level is set to INFO only), but I see plenty of build that are going through, for example https://koji.fedoraproject.org/koji/taskinfo?taskID=84503206

[Zlopez]

Just for the info, here are all the builds that the-new-hotness started https://koji.fedoraproject.org/koji/tasks?owner=the-new-hotness/release-monitoring.org&state=all

[bcl]

Seeing a similar problem with today's parted 3.5 release - https://bugzilla.redhat.com/show_bug.cgi?id=2076360
which was probably caused by the alpha releases being served from alpha.gnu.org and the stable release being served from ftp.gnu.org.

[Zlopez]

I'm not really sure if there is anything that could be done on hotness side about this. I will keep this open for investigation.

[claviola]

@Zlopez I just opened #442 before searching for "bad source", so feel free to close it as a duplicate.

Considering that this happened just a day after (22-03) it might have been a transient issue. Is there a way to just trigger a retry?

[bcl]

I'm not really sure if there is anything that could be done on hotness side about this. I will keep this open for investigation.

understood. Unless there is a way to add an exception for packages that change their source lines I don't see a way to deal with this. With parted this will happen when transitioning from stable -> alpha and alpha -> stable which doesn't happen very often currently. Usually I am adding patches to stable which works fine.

[Zlopez]

Hotness does only bump of the version, so if anything fails it is on the packager to check what happened.

[sergiomb2]

same here
https://bugzilla.redhat.com/show_bug.cgi?id=2087046

import subprocess as sp
specfile="./ImageMagick.spec"
tmp = "."
cmd_output = sp.check_output(
[
"rpmbuild",
"-D",
"_sourcedir .",
"-D",
"_topdir .",
"-bs",
specfile,
],
cwd=tmp,
stderr=sp.STDOUT,
)
cmd_output

Out[41]: b'setting SOURCE_DATE_EPOCH=1652313600\nWrote: ./SRPMS/ImageMagick-6.9.12.48-3.fc35.src.rpm\n'

note that ImageMagick.spec have %global to define sources but it works on my machine ...
https://src.fedoraproject.org/rpms/ImageMagick/blob/rawhide/f/ImageMagick.spec#_16

Version:        6.9.12.48	
Release:        4%{?dist}	
Summary:        An X application for displaying and manipulating images	
 	
%global VER %(foo=%{version}; echo ${foo:0:6})	
%global Patchlevel %(foo=%{version}; echo ${foo:7})	

License:        ImageMagick	
Url:            https://legacy.imagemagick.org/	
Source0:        https://www.imagemagick.org/download/releases/%{name}-%{VER}-%{Patchlevel}.tar.xz

[Zlopez]

Let me try this manually in the hotness dev env. It's possible that the %global macro could be the issue here.

[Zlopez]

I tried it in hotness dev environment and got

$ fedpkg --user "hotness" sources
Not downloading unused ImageMagick-6.9.12-50.tar.xz

Which is really strange, but it has nothing to do with the issue.

Bumping the spec file (no issue with %global macro) and downloading the new sources by spectool works fine. Even the rpmbuild finished fine.

Only thing that comes to my mind is that the source download was currently unavailable and didn't download anything, but the request was processed without error. If there would be any error code returned by spectool Hotness would raise an exception, but this didn't happened. It definitely needs more investigation.

[sergiomb2]

I think I found the issue, version is 6.9.12-50 , when we work with version 6.9.12.50 , that why first global works but not the second

%global VER %(foo=%{version}; echo ${foo:0:6})
%global Patchlevel %(foo=%{version}; echo ${foo:7})

foo="6.9.12.50"
echo ${foo:0:6}
echo ${foo:7}

seems to me that hotness use version 6.9.12 only

[Zlopez]

In this case this is not something caused by the-new-hotness. Maybe this is the issue in other cases as well.

[sergiomb2]

in my case yes, the other case is more likely that spectool -g had failed ... (it will explain why source is not there)
i.e. (alos in my case) when spectool -g fails should stop with that error , I guess
Thank you for your support

[ppisar]

# rpmbuild -D _sourcedir -D _topdir --bs perl-Scalar-List-Utils.spec 
error: Macro %_sourcedir has empty body

Your -D arguments have a macro name but are missing a macro value. Expected is -D '_sourcedir .'.

[ppisar]

These are the commands that are ran by the-new-hotness:

git clone <dist_git>
rpmdev-bumpspec --new <version> --c "Update to <version> (#<bug_id>)" --u <hotness_user> <specfile>
fedpkg --user hotness sources
spectool -g <specfile>
rpmbuild -D _sourcedir -D _topdir --bs <specfile>

As you can see the spectool -g <specfile> is executed just before the build. Maybe trying it manually will show you what was actually happened.

A problem is that spectool failing to download does NOT raise an error. Here I injected a nonexistant version "0.X22":

$ spectool -g perl-XS-Parse-Keyword.spec 
Downloading: https://cpan.metacpan.org/authors/id/P/PE/PEVANS/XS-Parse-Keyword-0.X22.tar.gz
Download failed:
404 Client Error: Not Found for url: https://cpan.metacpan.org/authors/id/P/PE/PEVANS/XS-Parse-Keyword-0.X22.tar.gz
-   0.0 B Elapsed Time: 0:00:00                                                                       
$ echo $?
0

Reported to rpmdevtools https://bugzilla.redhat.com/show_bug.cgi?id=2096624.

[Zlopez]

A problem is that spectool failing to download does NOT raise an error. Here I injected a nonexistant version "0.X22":

$ spectool -g perl-XS-Parse-Keyword.spec 
Downloading: https://cpan.metacpan.org/authors/id/P/PE/PEVANS/XS-Parse-Keyword-0.X22.tar.gz
Download failed:
404 Client Error: Not Found for url: https://cpan.metacpan.org/authors/id/P/PE/PEVANS/XS-Parse-Keyword-0.X22.tar.gz
-   0.0 B Elapsed Time: 0:00:00                                                                       
$ echo $?
0

Reported to rpmdevtools https://bugzilla.redhat.com/show_bug.cgi?id=2096624.

Nice catch, if the spectool returns 0 even when there is an error hotness will not catch it.