https://bugzilla.redhat.com/show_bug.cgi?id=1424890 --- Comment #18 from Andrew Toskin <andrew@xxxxxxx> --- (In reply to Per Bothner from comment #16) > sources file doesn't exist. Source files download skipped. This part you can ignore for the moment. This isn't documented very well, and I'm planning on fixing that as soon as I can set aside the time for it: After your package is approved and you've been added to the packagers group, you can use fedpkg to generate the `sources` file and upload the source tarballs to the "lookaside cache" for building on the Fedora infrastructure. The warning about the sources file is sort of pointless for a package that hasn't been approved yet. > error: File > /home/bothner/DomTerm/d66241a62eb4cc9ffe90760ef39c7d890ef627a0.tar.gz: No > such file or directory It's funny, fedora-review will download files for you, but for fedpkg, you have to download the source tarball before fedpkg can build with it. When the Source0 resolves to a valid online URL, you can download the tarball with `spectool --get-files ./domterm.spec`. You could also manually feed the tarball URL to wget or curl, but downloading via spectool helps to make sure your RPM spec has the correct URL. fedpkg should build just fine after that. Doing a `mockbuild` instead of a `local` build provides a more consistent build environment, and helps make sure you've properly listed all dependencies. I would usually do something like this: fedpkg --release f27 mockbuild --no-clean-all ...Or, this *should* work. When I use the most recently linked spec file, and download https://github.com/PerBothner/DomTerm/archive/%{commit0}.tar.gz and do a fedpkg mockbuild, it fails with this error message: File not found: /builddir/build/BUILDROOT/domterm-0.74-1.fc26.x86_64/usr/share/applications/domterm.desktop And likewise for the qtdomterm.desktop. The Makefile.am does create the directory `$(DESTDIR)$(datadir)/applications`, but doesn't seem to actually install the .desktop files. In fact, I didn't see any mention of "desktop" in the Makefile at all, so I added these lines to the spec file, at the end of the %install section. cp -p domterm.desktop %{buildroot}/%{_datadir}/applications/domterm.desktop cp -p qtdomterm.desktop %{buildroot}/%{_datadir}/applications/qtdomterm.desktop The fedpkg mockbuild for DomTerm runs successfully then. The equivalent Makefile commands might be better than appending to the spec file, though. (In reply to Per Bothner from comment #17) > - see this comment in the spec file: > > Java is needed for the stylesheet-manipulating subcommands of dt-util... Right, DomTerm itself doesn't really *need* Java, it's optional for only a couple features. But you are choosing to *build* with Java. I haven't tested this, but I wondered if DomTerm would crash or throw errors when launching on a system that does not have Java installed, if you're configuring it to expect Java. If it would only be an issue when trying to use those optional features, and preferably if DomTerm can gracefully handle Java's absence, then I guess you're fine. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx