bug#22883: gpg2 vs. gpg
Leo Famulari skribis: > On Sun, Jun 05, 2016 at 09:51:45AM +0200, Werner Koch wrote: >> Given that Guix is a new distro you should really try to get rid of 1.4 >> and only use 2.1. For Windows we use the name "gpg" for a long time now >> and there is a configure option --enable-gpg2-is-gpg to make it easier. > > If a Guix user installs GnuPG without specifying the version, which I > think is the typical behavior, they will get the latest version that we > package (currently 2.1.12). That's not exactly what you are requesting, > but it should steer some users towards the modern branch :) > > For your reference, we package the classic, stable, and modern branches. Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if that’s what Werner recommends. Thanks, Ludo’.
bug#23718: guix import shows wrong program
I ran `guix import gnu make' and got the following output: http://sprunge.us/LHGD I separately downloaded make-4.2.tar.bz2 and the displayed hash was the correct one, but the other fields were wrong. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#22883: gpg2 vs. gpg
On Tue, 7 Jun 2016 10:08, l...@gnu.org said: > Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if > that’s what Werner recommends. It would help to avoid trouble in the future. Debian will also install gpg2 as gpg and provide 1.4 only a non-mandatory package gnupg1. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */
bug#22883: gpg2 vs. gpg
On 2016-06-07(01:25:44+0200), Werner Koch wrote: > On Tue, 7 Jun 2016 10:08, l...@gnu.org said: > > > Nevertheless, we could configure GPG 2.x with --enable-gpg2-is-gpg, if > > that’s what Werner recommends. > > It would help to avoid trouble in the future. Debian will also install > gpg2 as gpg and provide 1.4 only a non-mandatory package gnupg1. > > > Shalom-Salam, > >Werner I can add Gentoo to the list of gpg2 -> gpg symlinking systems, though this is expected with 2.x version and GnuPG having this as quasi default: ~$ ls -al /usr/bin/gpg* lrwxrwxrwx 1 root root 4 May 20 13:45 /usr/bin/gpg -> gpg2 ... lrwxrwxrwx 1 root root 5 May 20 13:45 /usr/bin/gpgv -> gpgv2 -- ♥Ⓐ ng0 For non-prism friendly talk find me on psyced.org / loupsycedyglgamf.onion signature.asc Description: Digital signature
bug#23723: patch-shebang phase breaks symlinks
Hi Guix, It seems that the patch-shebang functionality does not deal gracefully with symlinks: it just overwrites them! After struggling somewhat with getting the recently packaged node 6.0.0 to behave, I found out that `patch-shebang' in (guix build gnu-build-system) does not work properly on symlinks. To illustrate, in this specific case, there was an executable script included with the node tarball, namely `lib/node-modules/npm/bin/npm-cli.js' with an env-based shebang: `/usr/bin/env node'. As the `node' executable will only be available after the `install' phase of the build system, it is not patched before hand. During the `install' phase, a symlink is created from `bin/npm' to `lib/node-modules/npm/bin/npm-cli.js' (in the store output directory this time, of course). Then the `patch-shebangs' phase finds this symlink and proceeds to patch it. Instead of transparently following the symlink and patching the `npm-cli.js' script, the `npm' symlink is overwritten with a shebang-patched copy of `npm-cli.js'. For node, this is a problem because of how node loads run-time dependencies; load paths are resolved relative to the actual file, not the symlink. - Jelle
