Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#48208 - [fdupes] multiple packaging issues
Attached to Project:
Community Packages
Opened by Levente Polyak (anthraxx) - Tuesday, 16 February 2016, 17:10 GMT
Last edited by Xyne (Xyne) - Tuesday, 01 March 2016, 00:05 GMT
Opened by Levente Polyak (anthraxx) - Tuesday, 16 February 2016, 17:10 GMT
Last edited by Xyne (Xyne) - Tuesday, 01 March 2016, 00:05 GMT
|
Detailsfdupes-1.51-3 has three packaging problems, it would be great if you could rebuild and push an updated -4 pkgrel.
1) source tarball referencing git HEAD It looks the package is pulling directly from the git HEAD via https://github.com/adrianlopezroche/fdupes/archive/master.zip. I assume you used that for testing and accidentally commited it, it would be great to switch this to a versioned release tarball (like before) or pin it to a static commit hash if there is no release but you need (for whatever reason) a newer version. Pulling master tarball may always return different versions and rebuilding a package is not deterministic anymore. Upstream seems to provide the version you package via: https://github.com/adrianlopezroche/fdupes/archive/fdupes-1.51.tar.gz If you need some fixes that came after that I always either backport separate patch commits and apply them to the release version or try to convince upstream to create a new release tag. 2) chroot the .BUILDINFO file contains a reference to /home/tmp/xyne/usr/etc/tu/svn-packages/fdupes/trunk I assume you accidentally forgot to build this package in a chroot. We need packages to be always built in a chroot so the .BUILDINFO file can be used to properly recreate build environments for reproducible builds. 3) packager Currently the packager option contains the value "Unknown Packager", this should also be corrected. I assume this also happened because you accidentally did not built in your regular chroot setup via extra-x86_64-build/extra-i686-build that automatically provides a makepkg.conf from your host system with your packager name. cheers, Levente |
This task depends upon
Closed by Xyne (Xyne)
Tuesday, 01 March 2016, 00:05 GMT
Reason for closing: Fixed
Additional comments about closing: Sorry for the delay.
Tuesday, 01 March 2016, 00:05 GMT
Reason for closing: Fixed
Additional comments about closing: Sorry for the delay.