Recently the forge macros were ported to use distprefix on f30, as far as I can tell. An unrelated change followed and a new build was pushed to rawhide (maybe without realising that it would also push the forge macro changes). It looks like the forge macros weren't tested to be backwards compatible, because packages that build successfully now fail to build on rawhide (see, for example, build [0]). The reason: The %{gosource} macro now expands to a different string on rawhide. So, sources uploaded on <f29 won't be found by buildSRPMfromSCM on rawhide, and vice versa - see the failed SRPM build [1]. The difference is the inclusion (or lack thereof) of a leading "v" from the tag in the file name. Up to f29, it will include the leading "v" in the Source tag (and file download, and source file entry, and lookaside cache file), and on rawhide, it won't. !!! This will break koji builds of all packages that use the forge macros !!! (with a tag, not a commit) in rawhide. !!! Koschei builds are already starting to fail because of this change. Please fix this. Since backporting the change won't work due to distprefix not being available, I think the leading "v" in the version part of the Source tag has to be reintroduced. But I won't upload two differently named source archives just for building the same version of a package on different releases of fedora. [0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=30225034 [1]: https://kojipkgs.fedoraproject.org//work/tasks/5035/30225035/build.log
Fabio, The new behaviour removes the need to set vversion tags and matches the archive file names that GitHub offers when you click on their download links (so something GitHub uses itself and they need to keep working). So it's better (best would be GitHub commiting to a stable dowload API and stopping playing vversion games, though the last bit is probably something to lay on git upstream's door). The backport to stable versions is perfectly possible and already planified, it's just five lines of code in the macro, I actually test everything in rawhide and el7, if it can run on el7 it can run on f28/29. But give the new code some baking time in -devel first (that's what devel is about).
> But give the new code some baking time in -devel first (that's what devel is about). That's where we disagree, but well. Closing this bug report since the situation has changed.