Re: Cookbook translations
On Tue, 28 Apr 2020 14:23:32 -0400 Julien Lepiller wrote: > The translation project is already hosted outside the guix project, > so I don't see any issue if we're not able to package it just yet. > > hosted.weblate.org has some tracking in place (a matomo instance > hosted by the weblate author). I wouldn't like to expose our users to > it. Fedora has a weblate instance open to any free software project > with no tracking, so I was suggesting using it instead. The fedora project sounds good. Also the hosted.weblate.org site would be OK for me personally. I had more concerns with self-hosting software that is free software in theory but does not bootstrap in practice. Björn pgpFChzhn_ozp.pgp Description: OpenPGP digital signature
Re: Adding a subcommand "load-profile"
On Wed, 2020-04-29 at 15:48 +0200, zimoun wrote: > Dear Roel, > > On Wed, 29 Apr 2020 at 14:46, Roel Janssen wrote: > > > > > If there is interest in having this as a "load-profile" subcommand, I > > > > will > > > > post > > > > an initial implementation to the mailing list ASAP. > > > > > > Instead of another subcommand, I would suggest to add an option to > > > "guix environment". > > > Then an another further step should maybe combine "--load-profile" and > > > "--ad-hoc" in order to create a temporary "augmented" profile. > > > > I would strongly prefer to keep it backwards-compatible for our local HPC > > users. > > Also, the "environment" command generates a new profile, whereas the > > proposed > > "load-profile" merely applies the environment variables of an existing > > profile > > to a newly spawned shell. I think the way they work differs enough to > > warrant a > > separate subcommand. > > I understand that you would like to keep backward-compatibility with > your current tools and ease the switch for your users. But you could > do so by replacing all the shell code in the 'guixr load-profile' by > "guix environment --load-profile". :-) Well, I want to get rid of all the shell code. Not replace it with less shell code. :) And cluttering everyone's environment on our cluster with a bash function that figures out whether to emit "guix environment --load-profile" or another guix command seems far from optimal too. Kind regards, Roel Janssen
Re: unexpected reproducibility of reproducible blog post?
zimoun writes: > Argh! The author should watch the Fun MOOC about computational > reproducibility. ;-) That would probably help. I'll pass on the message ;-) I have also opened an issue for this: https://github.com/khinsen/reproducibility-with-guix/issues/2 > Grafts or maybe Guile 2 -> 3? With time-machine, you run the full Guix from back then, so you run Guile 2 if that's what it takes. What I am not so sure about is how the old Guix release is built. If the build uses the equivalent of "guix environment guix", it would start using Guile 3. Time travelling is not as simple as it looks, but then we should have expected that! Cheers, Konrad
Re: Adding a subcommand "load-profile"
Dear Roel, On Wed, 29 Apr 2020 at 14:46, Roel Janssen wrote: > > > If there is interest in having this as a "load-profile" subcommand, I will > > > post > > > an initial implementation to the mailing list ASAP. > > > > Instead of another subcommand, I would suggest to add an option to > > "guix environment". > > Then an another further step should maybe combine "--load-profile" and > > "--ad-hoc" in order to create a temporary "augmented" profile. > > I would strongly prefer to keep it backwards-compatible for our local HPC > users. > Also, the "environment" command generates a new profile, whereas the proposed > "load-profile" merely applies the environment variables of an existing profile > to a newly spawned shell. I think the way they work differs enough to > warrant a > separate subcommand. I understand that you would like to keep backward-compatibility with your current tools and ease the switch for your users. But you could do so by replacing all the shell code in the 'guixr load-profile' by "guix environment --load-profile". :-) On one hand, I am not convinced by adding another subcommand as I said above. :-) On the other hand, this new subcommand loading a profile could be the starting point of the "guix develop" subcommand that was mentioned some time ago. https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00613.html https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00019.html All the best, simon
Re: unexpected reproducibility of reproducible blog post?
Hi Ricardo, On Wed, 29 Apr 2020 at 14:44, Ricardo Wurmus wrote: > > > Konrad Hinsen writes: > > > One question I have been wondering about is the possibility of grafts > > being an obstacle to reproducibility. Grafts are something I don't > > really understand yet, so I cannot answer this question. In particular, > > does a grafted package get a different hash from a package built with > > grafting disabled? > > Yes. > > A grafted package is a copy of the original package but with all > references to /gnu/store/AA-… replaced with /gnu/store/BB-…. > This is done recursively starting with the direct users of the > replaced package and for all users of those users. Could the grafts explain the mismatch reported before? Cheers, simon
Re: core-updates call for testing
Ricardo Wurmus writes: > Leo Famulari writes: > >> I'm doing `guix pull --branch=core-updates`, with a `guix describe` of >> commit a533c5a183 (core-updates from 2 weeks ago), on Debian, in tmux, >> and I see this weird thing: >> >> -- >> substitute: updating substitutes from 'https://private.mirror'... 100.0% >> @ substituter-started >> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 substitute >> /@ download-started >> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 >> https://private.mirror/nar/lzip/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 >> 4856299 >> \@ download-progress >> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 >> https://private.mirror/nar > > These tags are status information that Guix should hide and use to build > progress bars and the like. They have been around for quite some time, > but they should not ever be visible. Could it be because locales are not yet available for the new Guix? signature.asc Description: PGP signature
Re: core-updates call for testing
Leo Famulari writes: > On Tue, Apr 28, 2020 at 03:17:06PM +0200, Marius Bakke wrote: >> Leo Famulari writes: >> >> > I reconfigured my Guix System based on core-updates, and afterwards I >> > was unable to login, either remotely over SSH, or on the Linux console. >> >> Do you still have the logs from this attempt? Curious what caused login >> to fail. > > Yes, they are excerpted below. First you'll see the remote login > attempts, and then the attempts at the Linux console: Thanks! > Apr 25 13:57:16 localhost sshd[2731]: Accepted publickey for leo from > 192.168.1.101 port 55512 ssh2: ED25519 SHA256:my-key > Apr 25 13:57:16 localhost sshd[2731]: error: PAM: pam_open_session(): Module > is unknown strace on the ssh server process after reconfiguring on core-updates shows: 966 sendto(8, "<83>Apr 29 14:38:19 sshd[966]: PAM unable to dlopen(/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so): /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libc.so.6: version `GLIBC_2.30' not found (required by /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so)", 340, MSG_NOSIGNAL, NULL, 0) = 340 966 getpid() = 966 966 sendto(8, "<83>Apr 29 14:38:19 sshd[966]: PAM adding faulty module: /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so", 142, MSG_NOSIGNAL, NULL, 0) = 142 Restarting 'ssh-daemon' allows login to succeed. [...] > Apr 25 13:58:17 localhost shepherd[1]: Respawning term-tty1. > Apr 25 13:58:17 localhost shepherd[1]: Service host-name has been started. > Apr 25 13:58:17 localhost shepherd[1]: Service term-tty1 has been started. > Apr 25 13:58:20 localhost vmunix: [433720.062263] login[2745]: segfault at 0 > ip 7f8fc66d0934 sp 7fffcf163610 error 4 in > libpthread-2.31.so[7f8fc66d+f000] > Apr 25 13:58:20 localhost vmunix: [433720.062271] Code: 82 e8 02 00 00 e0 ff > ff ff be 18 00 00 00 b8 11 01 00 00 48 89 ba d8 02 00 00 48 89 ba e0 02 00 00 > 0f 05 48 8b 05 84 56 01 00 <48> 8b 00 64 48 89 04 25 98 06 00 00 48 8d 05 09 > 9a 01 00 48 8d 8a I see a similar failure when tracing the associated mingetty process: 1003 sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM unable to dlopen(/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so): /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy 4pj-glibc-2.29/lib/libc.so.6: version `GLIBC_2.30' not found (required by /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so)", 342, MSG_NOSIGNAL, NULL, 0) = 342 1003 getpid() = 1003 1003 sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM adding faulty module: /gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so", 144, MSG_NOSIGNAL, NULL, 0) = 144 Again running 'herd restart term-tty1' lets me log in successfully. I'm not sure what to do about this. Can we get the Shepherd to automatically restart select services on reconfigure? For the term-tty services that are started on demand, one fix would be to have Shepherd start the new service without the explicit 'herd restart term-tty1' call. Thoughts? signature.asc Description: PGP signature
Re: Adding a subcommand "load-profile"
Dear Simon, Thank you for your ideas! On Tue, 2020-04-28 at 18:54 +0200, zimoun wrote: > > [...] > > > Would there be any interest from others to have this as well? And also, the > > shell implementation heavy relies on Bash. What other shells should I > > attempt > > to implement? > > It would be cool! > However, if I remember correctly the previous discussion on such > topic, the issue was to respect the user's shell ($SHELL). This > argument is mitigated by the fact that "guix environment" already uses > Bash to spawn the new shell, if I understand correctly. I think we can respect the user's shell for the implementation of "load- profile". We could use Guile's "getenv" and "setenv" to prepare the shell environment in Guile, and then spawn the $SHELL in such a way that it doesn't load the user's default configuration. > Well, I find annoying to not able to "go in" and "go out" in one > profile and I prefer having a Bash specific implementation than > nothing. > So, thank you for the initiative. :-) > > > > If there is interest in having this as a "load-profile" subcommand, I will > > post > > an initial implementation to the mailing list ASAP. > > Instead of another subcommand, I would suggest to add an option to > "guix environment". > Then an another further step should maybe combine "--load-profile" and > "--ad-hoc" in order to create a temporary "augmented" profile. I would strongly prefer to keep it backwards-compatible for our local HPC users. Also, the "environment" command generates a new profile, whereas the proposed "load-profile" merely applies the environment variables of an existing profile to a newly spawned shell. I think the way they work differs enough to warrant a separate subcommand. Kind regards, Roel Janssen
Re: unexpected reproducibility of reproducible blog post?
Konrad Hinsen writes: > One question I have been wondering about is the possibility of grafts > being an obstacle to reproducibility. Grafts are something I don't > really understand yet, so I cannot answer this question. In particular, > does a grafted package get a different hash from a package built with > grafting disabled? Yes. A grafted package is a copy of the original package but with all references to /gnu/store/AA-… replaced with /gnu/store/BB-…. This is done recursively starting with the direct users of the replaced package and for all users of those users. -- Ricardo
Re: core-updates call for testing
sirgazil writes: > And I've already seen that before (I mean those bars before the @ sign, > etc.), but I don't know how it is supposed to be presented. That information > usually makes no sense to me :P This is definitely not supposed to be shown. Things like @ download-progress /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 https://private.mirror/nar/lzip/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 4856299 1048605 are meant to be printed as a progress bar. -- Ricardo
Re: core-updates call for testing
Leo Famulari writes: > I'm doing `guix pull --branch=core-updates`, with a `guix describe` of > commit a533c5a183 (core-updates from 2 weeks ago), on Debian, in tmux, > and I see this weird thing: > > -- > substitute: updating substitutes from 'https://private.mirror'... 100.0% > @ substituter-started > /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 substitute > /@ download-started > /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 > https://private.mirror/nar/lzip/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 > 4856299 > \@ download-progress > /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 > https://private.mirror/nar These tags are status information that Guix should hide and use to build progress bars and the like. They have been around for quite some time, but they should not ever be visible. -- Ricardo
Re: core-updates call for testing
sirgazil writes: > By the way, it would be great if someone could review this patch: > https://issues.guix.gnu.org/issue/39069, which is supposed to fix bugs > like this one: https://issues.guix.gnu.org/issue/40686, which have > been around for a long time and make the GNOME experience unsatisfying > from day one. I applied the patch. -- Ricardo
Re: unexpected reproducibility of reproducible blog post?
Hi Konrad, On Wed, 29 Apr 2020 at 11:26, Konrad Hinsen wrote: > > Has the file 'guix-version-for-reproduction.txt' been tracked? > > Unfortunately not. The repository for the preparation of the post > is at > > https://github.com/khinsen/reproducibility-with-guix/ > > but it doesn't contain the file 'guix-version-for-reproduction.txt'. Argh! The author should watch the Fun MOOC about computational reproducibility. ;-) > > Is really the commit 769b96b62e8c09b078f73adc09fb860505920f8f used to > > produce the Docker image listed in the blog post? > > Hard to say... I can't play with that right now because I am running > jobs on my computer that eat all the memory. Leo reproduced the new observed hash. > One question I have been wondering about is the possibility of grafts > being an obstacle to reproducibility. Grafts are something I don't > really understand yet, so I cannot answer this question. In particular, > does a grafted package get a different hash from a package built with > grafting disabled? Grafts or maybe Guile 2 -> 3? Cheers, simon
Re: unexpected reproducibility of reproducible blog post?
Hi Simon, > Based on the nice blog post [1], instead of really travelling I just > travel in time. :-) > If I read correctly and if I did not do any mistake, the final hash is > not the same now than before. It is not what I was expecting. > > Expected output (blog post): > /gnu/store/iqn9yyvi8im18g7y9f064lw9s9knxp0w-docker-pack.tar > > Returned output: > /gnu/store/klisfr3a4wxb9dc5sgibb45kky72kg65-docker-pack.tar > > Has the file 'guix-version-for-reproduction.txt' been tracked? Unfortunately not. The repository for the preparation of the post is at https://github.com/khinsen/reproducibility-with-guix/ but it doesn't contain the file 'guix-version-for-reproduction.txt'. > Is really the commit 769b96b62e8c09b078f73adc09fb860505920f8f used to > produce the Docker image listed in the blog post? Hard to say... I can't play with that right now because I am running jobs on my computer that eat all the memory. One question I have been wondering about is the possibility of grafts being an obstacle to reproducibility. Grafts are something I don't really understand yet, so I cannot answer this question. In particular, does a grafted package get a different hash from a package built with grafting disabled? Cheers, Konrad.
Re: core-updates call for testing
sirgazil writes: > it seems that the comments mechanism in > issues.gnu.org does not work. yes, sorry about that. There’s a problem with the environment in which the mailer service runs. It’s on my list to investigate and fix it. (The messages aren’t lost. They are stuck in the queue.) -- Ricardo
