bug#22402: info guix pages
carl hansen skribis: > On Mon, Jan 18, 2016 at 5:47 PM, Leo Famulari wrote: > >> On Mon, Jan 18, 2016 at 03:43:35PM -0800, carl hansen wrote: >> > I do >> > "info guix" >> > and I don't get the info pages, although OTHER info pages work >> > and INFOPATH seems correct. >> > BUt if I am root then I do get >> > info guix correctly. >> > I can see the files are there in the file system. >> > It seems that the guix.info should be automatically accessible >> > to regular users, or do I have to do some additonal step? >> > Or is it just me? >> >> Are you using GuixSD or Guix on a "foreign distro"? >> > > ubuntu Where is Guix installed? If you used the “binary installation” method, Guix is installed in /root/.guix-profile, which is why you only get to see its manual when running ‘info’ as root. HTH, Ludo’.
bug#22402: info guix pages
On Tue, Jan 19, 2016 at 1:01 AM, Ludovic Courtès wrote: > carl hansen skribis: > > > On Mon, Jan 18, 2016 at 5:47 PM, Leo Famulari wrote: > > > >> On Mon, Jan 18, 2016 at 03:43:35PM -0800, carl hansen wrote: > >> > I do > >> > "info guix" > >> > and I don't get the info pages, although OTHER info pages work > >> > and INFOPATH seems correct. > >> > BUt if I am root then I do get > >> > info guix correctly. > >> > I can see the files are there in the file system. > >> > It seems that the guix.info should be automatically accessible > >> > to regular users, or do I have to do some additonal step? > >> > Or is it just me? > >> > >> Are you using GuixSD or Guix on a "foreign distro"? > >> > > > > ubuntu > > Where is Guix installed? If you used the “binary installation” method, > Guix is installed in /root/.guix-profile, which is why you only get to > see its manual when running ‘info’ as root. > > HTH, > Ludo’. > Yes, that is the case, there is no mystery, there is indeed a /root/.guix-profile/share/info/guix.info and there is NOT a ~user/.guix-profile/share/info/guix.info However I consider that a bug. Here I am a user, using guix, and I expect "info guix" to work. Why would the user have to switch to root just to read this one info file? After installing guix, I would expect guix.info to be in my defalt .guix-profile, or a least a notice of how to install guix.info. ( coping and linking I know how to do, that's not the problem. It's a question of creating a polished piece of software.) Would "guix package -i guix" do the right thing? That seems all wrong, would install stuff I already have. I acknowledge my understanding of the guix system is incomplete.
bug#22402: info guix pages
carl hansen skribis: > Yes, that is the case, there is no mystery, there is indeed a > /root/.guix-profile/share/info/guix.info > and there is NOT a > ~user/.guix-profile/share/info/guix.info OK. > However I consider that a bug. Here I am a user, using guix, and I expect > "info guix" to work. Why would the user have to switch to root just to read > this one info file? After installing guix, I would expect guix.info to be > in my defalt .guix-profile, or a least a notice of how to install > guix.info. ( coping and linking I know how to do, that's not the problem. > It's a question > of creating a polished piece of software.) Yeah, I agree this is bad. On GuixSD there’s no such problem because Guix is installed system-wide, so “info guix” always picks up the system-wide guix.info at least. > Would "guix package -i guix" do the right thing? That seems all > wrong, would install stuff I already have. It would do the trick, yes. I’m not sure how to fix that problem on foreign distros. Suggestions welcome. Ludo’.
bug#22408: wget rejects Let's Encrypt certs, although Icecat accepts them
On recent GuixSD, IceCat accepts the Let's Encrypt certificate from https://git.dthompson.us/, but 'wget' rejects it: mhw@jojen:~$ wget https://git.dthompson.us/presentations.git/blob/HEAD:/guix-blu-2016-01-20.pdf --2016-01-19 09:23:23-- https://git.dthompson.us/presentations.git/blob/HEAD:/guix-blu-2016-01-20.pdf Resolving git.dthompson.us (git.dthompson.us)... 23.92.20.238 Connecting to git.dthompson.us (git.dthompson.us)|23.92.20.238|:443... connected. ERROR: The certificate of ‘git.dthompson.us’ is not trusted. ERROR: The certificate of ‘git.dthompson.us’ hasn't got a known issuer. Mark
bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
Christopher Allan Webber writes: > From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 > From: Christopher Allan Webber > Date: Sun, 17 Jan 2016 20:34:25 -0800 > Subject: [PATCH] gnu: Add linux-libre-4.2.5 > > This older version of linux-libre is being added because it was found > that newer versions (or at least 4.3.3) of linux-libre were not reading > the hardware clock on (at least Libreboot-enabled) Thinkpad x200 > machines. > > * gnu/linux.scm (linux-libre-4.2.5): New variable. I would say that the variable should be named 'linux-libre-4.2', which would always be bound to the latest 4.2.x. However, there's another problem: the 4.2 branch is no longer supported upstream, so it will no longer receive security updates and other important fixes. I suggest that we instead add linux-libre-4.1, which is still supported upstream and is designated as an LTS branch. Would that be okay? Another issue is that the kernel config for 4.3 is being used here. I guess maybe that's working well enough in this case, but really our kernel packages should be refactored somewhat to make this nicer. One more thing: Francis Rowe told me that the coreboot developers have determined that this is a bug on their side, and libreboot will cherry-pick the fix soon, if it hasn't already. Thanks! Mark
bug#22402: info guix pages
On Tue, 19 Jan 2016 11:45:09 +0100 l...@gnu.org (Ludovic Courtès) wrote: > carl hansen skribis: > > [...] > > OK. > > [...] > > Yeah, I agree this is bad. On GuixSD there’s no such problem because > Guix is installed system-wide, so “info guix” always picks up the > system-wide guix.info at least. > > [...] > > It would do the trick, yes. > > I’m not sure how to fix that problem on foreign distros. Suggestions > welcome. > > Ludo’. > step 11 of binary install: $ guix package -i guix -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted pgpB6gdS6_MQh.pgp Description: OpenPGP digital signature
bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
Mark H Weaver skribis: > Christopher Allan Webber writes: > >> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >> From: Christopher Allan Webber >> Date: Sun, 17 Jan 2016 20:34:25 -0800 >> Subject: [PATCH] gnu: Add linux-libre-4.2.5 >> >> This older version of linux-libre is being added because it was found >> that newer versions (or at least 4.3.3) of linux-libre were not reading >> the hardware clock on (at least Libreboot-enabled) Thinkpad x200 >> machines. >> >> * gnu/linux.scm (linux-libre-4.2.5): New variable. > > I would say that the variable should be named 'linux-libre-4.2', which > would always be bound to the latest 4.2.x. However, there's another > problem: the 4.2 branch is no longer supported upstream, so it will no > longer receive security updates and other important fixes. > > I suggest that we instead add linux-libre-4.1, which is still supported > upstream and is designated as an LTS branch. Would that be okay? If it works for Christopher, that’s a good idea. > Another issue is that the kernel config for 4.3 is being used here. I > guess maybe that's working well enough in this case, but really our > kernel packages should be refactored somewhat to make this nicer. Yeah, though that’s probably beyond the scope of this particular issue. > One more thing: Francis Rowe told me that the coreboot developers have > determined that this is a bug on their side, and libreboot will > cherry-pick the fix soon, if it hasn't already. Interesting. Any links to the bug report or commit? Thanks for your feedback! Ludo’.
bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Christopher Allan Webber writes: >> >>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >>> From: Christopher Allan Webber >>> Date: Sun, 17 Jan 2016 20:34:25 -0800 >>> Subject: [PATCH] gnu: Add linux-libre-4.2.5 >>> >>> This older version of linux-libre is being added because it was found >>> that newer versions (or at least 4.3.3) of linux-libre were not reading >>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200 >>> machines. >>> >>> * gnu/linux.scm (linux-libre-4.2.5): New variable. >> >> I would say that the variable should be named 'linux-libre-4.2', which >> would always be bound to the latest 4.2.x. However, there's another >> problem: the 4.2 branch is no longer supported upstream, so it will no >> longer receive security updates and other important fixes. >> >> I suggest that we instead add linux-libre-4.1, which is still supported >> upstream and is designated as an LTS branch. Would that be okay? > > If it works for Christopher, that’s a good idea. > >> Another issue is that the kernel config for 4.3 is being used here. I >> guess maybe that's working well enough in this case, but really our >> kernel packages should be refactored somewhat to make this nicer. > > Yeah, though that’s probably beyond the scope of this particular issue. Agreed. >> One more thing: Francis Rowe told me that the coreboot developers have >> determined that this is a bug on their side, and libreboot will >> cherry-pick the fix soon, if it hasn't already. "determined" may have been too strong a word. Maybe better to say that they "think" it's a coreboot bug, exposed by a change in the kernel. > Interesting. Any links to the bug report or commit? https://review.coreboot.org/#/c/11853/ Mark
bug#22402: info guix pages
On Tue, Jan 19, 2016 at 4:34 AM, carl hansen wrote: > > Yes, that is the case, there is no mystery, there is indeed a > /root/.guix-profile/share/info/guix.info > and there is NOT a > ~user/.guix-profile/share/info/guix.info > > However I consider that a bug. Here I am a user, using guix, and I expect > "info guix" to work. Why would the user have to switch to root just to read > this one info file? After installing guix, I would expect guix.info to be > in my defalt .guix-profile, or a least a notice of how to install > guix.info. ( coping and linking I know how to do, that's not the problem. > It's a question > of creating a polished piece of software.) Would "guix package -i guix" do > the right thing? > That seems all wrong, would install stuff I already have. I think you need to adjust your expectations. You only have Guix available *in the root user's profile*. Each user has their own package profile, so running 'guix package -i guix' as your regular user is exactly what you want. Why would you expect the system to magically read the info pages out of root's profile? It's not installing stuff you already have because your user *didn't* have it. So, install the Guix package and set $INFOPATH to include $HOME/.guix-profile/share/info. Ludo, to avoid this confusion in the future, perhaps the binary installation instructions for folks on foreign distros could have an additional instruction. After symlinking root's guix to /usr/local/bin/guix, the documentation could suggest symlinking the docs to /usr/local/share/info. Would that help? - Dave
bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)
Ludovic Courtès writes: > Mark H Weaver skribis: > >> Christopher Allan Webber writes: >> >>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >>> From: Christopher Allan Webber >>> Date: Sun, 17 Jan 2016 20:34:25 -0800 >>> Subject: [PATCH] gnu: Add linux-libre-4.2.5 >>> >>> This older version of linux-libre is being added because it was found >>> that newer versions (or at least 4.3.3) of linux-libre were not reading >>> the hardware clock on (at least Libreboot-enabled) Thinkpad x200 >>> machines. >>> >>> * gnu/linux.scm (linux-libre-4.2.5): New variable. >> >> I would say that the variable should be named 'linux-libre-4.2', which >> would always be bound to the latest 4.2.x. However, there's another >> problem: the 4.2 branch is no longer supported upstream, so it will no >> longer receive security updates and other important fixes. >> >> I suggest that we instead add linux-libre-4.1, which is still supported >> upstream and is designated as an LTS branch. Would that be okay? > > If it works for Christopher, that’s a good idea. Fine by me, assuming it works. I can test it works fine probably tomorrow. >> Another issue is that the kernel config for 4.3 is being used here. I >> guess maybe that's working well enough in this case, but really our >> kernel packages should be refactored somewhat to make this nicer. > > Yeah, though that’s probably beyond the scope of this particular issue. I haven't noticed any problems, though >> One more thing: Francis Rowe told me that the coreboot developers have >> determined that this is a bug on their side, and libreboot will >> cherry-pick the fix soon, if it hasn't already. > > Interesting. Any links to the bug report or commit? Yeah, Francis told me this as well. I guess this means that I should reflash libreboot once this change happens. I'm a little bit nervous to do that! :)
bug#22402: info guix pages
On Tue, Jan 19, 2016 at 12:17:32PM -0500, Thompson, David wrote: > On Tue, Jan 19, 2016 at 4:34 AM, carl hansen wrote: > > > > Yes, that is the case, there is no mystery, there is indeed a > > /root/.guix-profile/share/info/guix.info > > and there is NOT a > > ~user/.guix-profile/share/info/guix.info > > > > However I consider that a bug. Here I am a user, using guix, and I expect > > "info guix" to work. Why would the user have to switch to root just to read > > this one info file? After installing guix, I would expect guix.info to be > > in my defalt .guix-profile, or a least a notice of how to install > > guix.info. ( coping and linking I know how to do, that's not the problem. > > It's a question > > of creating a polished piece of software.) Would "guix package -i guix" do > > the right thing? > > That seems all wrong, would install stuff I already have. > > I think you need to adjust your expectations. You only have Guix > available *in the root user's profile*. Each user has their own > package profile, so running 'guix package -i guix' as your regular > user is exactly what you want. Why would you expect the system to > magically read the info pages out of root's profile? It's not > installing stuff you already have because your user *didn't* have it. > So, install the Guix package and set $INFOPATH to include > $HOME/.guix-profile/share/info. > > Ludo, to avoid this confusion in the future, perhaps the binary > installation instructions for folks on foreign distros could have an > additional instruction. After symlinking root's guix to > /usr/local/bin/guix, the documentation could suggest symlinking the > docs to /usr/local/share/info. Would that help? I only just realized that I have been using root's `guix` as my user, because I have been relying on the `guix` in '/usr/local/bin'. I like Efraim's suggestion of instructing users to `guix package -i guix`. > > - Dave > > >
bug#22402: info guix pages
On Tue, Jan 19, 2016 at 2:02 PM, Leo Famulari wrote: > On Tue, Jan 19, 2016 at 12:17:32PM -0500, Thompson, David wrote: > > On Tue, Jan 19, 2016 at 4:34 AM, carl hansen > wrote: > > > > > > Yes, that is the case, there is no mystery, there is indeed a > > > /root/.guix-profile/share/info/guix.info > > > and there is NOT a > > > ~user/.guix-profile/share/info/guix.info > > > > snip snip Ok I did, as suggested, guix package -i guix which I was afraid of, fearing some ouroboros strange loop destruction of the universe; fears unfounded, only curious effect was dozens or hundreds of warning: collision encountered: /gnu/store/wfvxxpdhnzd59v ... warning: arbitrarily choosing /gnu/store/wfvxxpdhnzd59vkad1z... type messages. Otherwise, seems to work. As suggested by Efraim Flashner , add that command to the Binary install instructions. Now, about your fine manual, on http://www.gnu.org/software/guix/manual/ we see "last updated November 04, 2015" Please use a cronjob to update the manual nightly , or so, to the latest version. The universe will thank you.
bug#22402: info guix pages
On Tue, Jan 19, 2016 at 04:45:12PM -0800, carl hansen wrote: > On Tue, Jan 19, 2016 at 2:02 PM, Leo Famulari wrote: > > > On Tue, Jan 19, 2016 at 12:17:32PM -0500, Thompson, David wrote: > > > On Tue, Jan 19, 2016 at 4:34 AM, carl hansen > > wrote: > > > > > > > > Yes, that is the case, there is no mystery, there is indeed a > > > > /root/.guix-profile/share/info/guix.info > > > > and there is NOT a > > > > ~user/.guix-profile/share/info/guix.info > > > > > > > > snip snip > > Ok I did, as suggested, > guix package -i guix > which I was afraid of, fearing some ouroboros strange loop destruction of > the universe; > fears unfounded, only curious effect was dozens or hundreds of > > warning: collision encountered: /gnu/store/wfvxxpdhnzd59v ... > warning: arbitrarily choosing /gnu/store/wfvxxpdhnzd59vkad1z... > > type messages. Otherwise, seems to work. That's not optimal. Those messages mean that of the store directories linked to from your profile, more than one provide a given path. For example, GNU Parallel and moreutils both have a path "bin/parallel": /gnu/store/7ggbvsql79s5i05a3v8cbn48kdrzf7nc-parallel-20151222/bin/parallel /gnu/store/ax4ppgzmx5cjqr813l3djgzhiniam1yz-moreutils-0.57/bin/parallel If you install both in your profile, those two paths both become: ~/.guix-profile/bin/parallel And so you get a warning and the conflict is resolved arbitrarily. You can't have both of the "parallels" in your profile at once. Were the conflicting paths related to Guix? > > As suggested by Efraim Flashner , add that command to the Binary install > instructions. > > Now, about your fine manual, on http://www.gnu.org/software/guix/manual/ > we see "last updated November 04, 2015" > Please use a cronjob to update the manual nightly , or so, to the latest > version. The universe will thank you.
bug#22408: wget rejects Let's Encrypt certs, although Icecat accepts them
On Tue, Jan 19, 2016 at 09:27:09AM -0500, Mark H Weaver wrote: > On recent GuixSD, IceCat accepts the Let's Encrypt certificate from > https://git.dthompson.us/, but 'wget' rejects it: > > mhw@jojen:~$ wget > https://git.dthompson.us/presentations.git/blob/HEAD:/guix-blu-2016-01-20.pdf > --2016-01-19 09:23:23-- > https://git.dthompson.us/presentations.git/blob/HEAD:/guix-blu-2016-01-20.pdf > Resolving git.dthompson.us (git.dthompson.us)... 23.92.20.238 > Connecting to git.dthompson.us (git.dthompson.us)|23.92.20.238|:443... > connected. > ERROR: The certificate of ‘git.dthompson.us’ is not trusted. > ERROR: The certificate of ‘git.dthompson.us’ hasn't got a known issuer. I don't think this issue is specific to our packaging. On up-to-date Debian testing, I have the same result from Debian's wget. I don't know how good the ssllabs.com test is, but it did report some errors while testing the domain. Let's Encrypt certs can work in Debian's and Guix's wget. I could `wget --https-only` from my domain with a Let's Encrypt cert with HTTP Strict Transport Security enabled. > > Mark > > >
