On Thu, Jun 17, 2021 at 09:02:12PM +0300, Otto Urpelainen wrote:
Ken Dreyer kirjoitti 17.6.2021 klo 19.04:
On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw <hobbes1...@gmail.com> wrote:
On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden
<ewoud+fed...@kohlvanwijngaarden.nl> wrote:
To be clear: I don't want to fiddle with the sources file, hence this
email. However, I would like to at least complete a local mockbuild
before uploading to the lookaside cache. It is my understanding that
new-sources always does this.
That's actually a nit I've been tempted to complain about. If I'm upgrading a
package to a new version I update the spec file:
rpmdev-bumpspec -n <version> -c "Update to <version>." *.spec
And download the new source:
spectool -g *.spec
But then I have to upload the new source with 'fedpkg new-sources' if I don't
want it to download the old version.
Yeah, the way I deal with this is I zero out the sources file, like ">
sources". Or another alternative that I use sometimes is "sha512sum
--tag", like:
sha512sum --tag kstart-4.2.tar.gz > sources
This is really helpful! I did not know it's the output of the --tag
parameter.
Hi Ewould and everybody,
I am a bit confused about this discussion. My fedpkg does not care
about the 'sources' file or the lookaside cache at all on 'fedpkg
mockbuild'. It simply looks up the expected filename of downloaded
Source, grabs it from the local working directory and uses that. So
for me this works:
rpmdev-bumpspec -D -n 1.2.3 *.spec
# Update specfile as needed
spectool -g *.spec
fedpkg mockbuild
Now it also downloads the old files mentioned in sources. In my
experience it certainly does care about it.
Maybe my request can be reduced to: mockbuild should not download files
not mentioned in the spec file. Ken did give a good workaround. Taking
that a step further I think something like this would suffice for me:
spectool -l *.spec | awk '/https?:/ { print $2 }' | xargs -n 1 basename | xargs
sha512sum --tag > sources
After that is done, the rpm is available at results_mypackage, I
install it locally and see that everything works. At that point it is
a good time do 'fedpkg new-sources'.
This I understand.
This also means that non-packagers actually *can* properly test their
changes. The maintainer has to do new-sources, commit, push and build
after merging the pull request, so annoyingly there are those steps to
remember. But at least the pull request author does not have to submit
their changes blindly.
A simple test to make sure that it really uses the local download:
$ sed -i 's/^Source.*/Source:https:\/\/example.com\/foo/' *.spec
$ fedpkg mockbuild
SOME_OUTPUT
error: Bad file: SOMEPATH/foo: No such file or directory
$ touch foo
$ fedpkg mockbuild
LOTS_OF_OUTPUT
SOME_ERROR_DUE_TO_EMPTY_SOURCE
When I started, I was having exactly the same trouble, so wrote
something in the wiki:
https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously
That's certainly a good start. I'm hoping to remove even more obstackles
for new contributors.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
