Arch Linux User Repository

Please note the following additions: # Bug reports can be filed at https://bugs.square-r00t.net/index.php?project=3 # News updates for packages can be followed at https://devblog.square-r00t.net (If you want an RSS-feed only pertaining to my AUR packages, you can subscribe to https://devblog.square-r00t.net/rss/?category=aur in your favourite RSS reader.) Note that you should still use the AUR web interface for flagging packages as out-of-date if a new version is released; the aforementioned bug tracker is to aid in issues with building/packaging/the PKGBUILD formats/etc. specifically. GPG signature "errors" are explained here: https://devblog.square-r00t.net/articles/a-note-on-using-gpg-signatures-in-pkgbuilds Please read; it's not a bug. Thanks!

@dreieck-

thanks! for some reason i was never alerted to new versions, either. so:

• source url fixed (the url= param was checked and works)
• updated to 4.8.6

It cannot download the source anymore. ftp.debian.org has to be changed to http.debian.net (two things: 1. debian.org changed to debian.net, 2. ftp.debian.<tld> needs to be changed to http.debian.<tld>).

Error message:

==> Retrieving sources...
  -> Downloading debianutils_4.8.1.1.tar.xz...
--2018-06-29 11:47:22--  <http://ftp.debian.org/debian/pool/main/d/debianutils/debianutils_4.8.1.1.tar.xz>
Resolving ftp.debian.org (ftp.debian.org)... failed: Connection timed out.
wget: unable to resolve host address ‘ftp.debian.org’
==> ERROR: Failure while downloading <http://ftp.debian.org/debian/pool/main/d/debianutils/debianutils_4.8.1.1.tar.xz>
    Aborting...

After correcting the source entry, download works.

Please, also check and correct the url=-entry.

Please correct in your AUR package.

@hawkeye- see 2016-06-03 comment. more information: https://devblog.square-r00t.net/articles/a-note-on-using-gpg-signatures-in-pkgbuilds

PGP Error

@miqueldvb- Thanks! Updated and pushed.

=> ERROR: Failure while downloading http://ftp.debian.org/debian/pool/main/d/debianutils/debianutils_4.8.tar.xz Aborting... It looks like version 4.8.1 is out

sanerb: I am not miguided, there is no reason to validate your signature on software you are not a part of upstream. If upstream is signing their packages you should use their signature files and it's absolutely no different to add their keys to my own personal keyring (because makepkg doesn't touch pacman's keyring) than it is to use yours. The point of validating signatures is another validation on top of checksums and to verify you're getting what upsteam is intending you to get which using yours means YOU could apply a patch and we could be using something not by the Debian developers. I do not know of any other source packages here (other than perhaps yours) on the AUR that do what you're doing and I will probably bring this up on aur-general and get a TU's opinion. As for the Arch Linux repositories (core, extra, ...), those are binary packages being signed and are irrelevant. I would also like you to look at packages in the ABS, (install abs package and run abs as root) and note that the Arch Linux developers and TUs do not sign source tars in the source packages.

@markzz I think you may be misguided. Arch packages in non-AUR, Arch-supplied repositories are signed- by the packager/maintainer. More and more AUR maintainers are doing the same with their own signatures. Some projects do provide upstream signatures, sure- but it's just as unlikely you'd have the Debian maintainers' pubkeys in your keyring as it is you have mine. (Because otherwise a Base install would have to install the pubkeys for ALL those upstream sigs instead of just the TU's et. al. into pacman's/the system's keyring. And they most certainly do not do that.) The point of signatures in PKGBUILDs is to verify against the packager/maintainers, I'd argue, for the AUR as we have no binary package to distribute. No need to go lambasting this, as I very clearly provide[0] further information on the usability aspect. However, if you disagree, I'd ask why you find it acceptable that Arch maintainers provide signatures of their own rather than upstream, and why this is unacceptable for the AUR. (edited for clarity) [0] https://devblog.square-r00t.net/articles/a-note-on-using-gpg-signatures-in-pkgbuilds

Why, may I ask, are we validating a signature that isn't from upstream? This seems (and most likely is) wrong. The point of signatures is to validate the upstream packager's sigs, not the AUR maintainer's. I would advise users of this PKGBUILD to remove the signature from the sources and sums arrays and just not bother.

Please note the following additions: # Bug reports can be filed at https://bugs.square-r00t.net/index.php?project=3 # News updates for packages can be followed at https://devblog.square-r00t.net (If you want an RSS-feed only pertaining to my AUR packages, you can subscribe to https://devblog.square-r00t.net/rss/?category=aur in your favourite RSS reader.) Note that you should still use the AUR web interface for flagging packages as out-of-date if a new version is released; the aforementioned bug tracker is to aid in issues with building/packaging/the PKGBUILD formats/etc. specifically. GPG signature "errors" are explained here: https://devblog.square-r00t.net/articles/a-note-on-using-gpg-signatures-in-pkgbuilds Please read; it's not a bug. Thanks!