bug#38243: Zsh does not load /etc/profile values by default
Am Samstag, den 07.12.2019, 22:15 -0800 schrieb Danny O'Brien: > I took a closer look at this, and currently Zsh users have > /etc/profile included in their environment by virtue of a default > $HOME/.zprofile, which is created in their home directory when they > are created (via `useradd` and /etc/skel ). It appears, though, that some Guix users lack this skeleton, perhaps those who used it before the change. > I'm a little stuck to know what to do here -- if we source > /etc/profile in /etc/zprofile, then we risk sourcing it twice for > users who have the current default ~/.zprofile already in their home > directories`. OTOH, if users come to Guix System with their own pre- > existing home directory, then they may well struggle --- as I did -- > because important environment variables aren't set by their > established ~/.zshrc, ~/.zprofile or ~/.zlogin setups. I don't think the problem is as bad as you make it out to be. If we write channel news describing the move of .zprofile to /etc/zprofile, people ought to see it and be able to prevent the double-sourcing. > I *think* the right thing to do is to drop the current > /etc/skel/.zprofile and establish that /etc/zprofile (and other > shells) should source /etc/profile . Guix System does a lot of setup > in /etc/profile including including $GUIX_PROFILE/etc/profile. It > would be best if this automatically happened, whatever is going on in > individual home directories. I'm a Guix newbie though, so I'm happy > to take advice! Archlinux has a one-line /etc/zprofile which sources > /etc/profile ; Debian does not; I have not checked other > distributions, but I could. The real problem with $GUIX_PROFILE/etc/profile is its shell-specific behaviour. The weird syntax used there *happens* to be supported by zsh, but other shells (most notably fish, but e.g. also Eshell[1]) do not like it. To solve this problem not just for one shell, but for all of them, we should write a portable $GUIX_PROFILE/etc/profile. Same for /etc/profile. Then we can source it from other shells. Again, sourcing it from /etc/zprofile is fine even without that change, as zsh happens to eat this syntax without complaints, but other shells do not like it. Regards, Leo [1] Eshell is a weird one. Sourceing the file directly appears to work, but does nothing. Setting $GUIX_PROFILE instead causes the user to be prompted for an alias.
bug#38524: 'dhcp-client-service' crash when non-libre networking interface is present
The 'dhcp-client-service' fail to start when a non-libre network interface (here 148f:3070) is plugged-in even though there is an libre networking interface (here 01:00.0) available. Removing the non-libre networking interface from the system allow 'dhcp-client-service' to start correctly on the libre networking interface. I think the service shouldn't crash when there is an non-libre network interface connected, it should just skip it and maybe throw an error message. Allowing to specify the network interfaces on which 'dhcp-client-service' should run can also somewhat resolve the issue. #+begin_src sh $ sudo herd start networking [ 2758.305139] 1-3:1.0: Missing Free firmware (non-Free firmware loading is disabled) [ 2758.395791] ieee80211 phy0: rt2x00lib_request_firmware: Error - Failed to request Firmware herd: exception caught while executing 'start' on service 'networking': In procedure set-network-interface-flags: set-network-interface-flags on wlp0s20f0u3: No such file or directory $ ip a s 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:e0:4c:68:67:77 brd ff:ff:ff:ff:ff:ff 3: wlp0s20f0u3: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:c0:ca:77:05:e7 brd ff:ff:ff:ff:ff:ff $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub $ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 02) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02) 00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1) 00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO UART Controller #0 (rev 21) 00:1e.4 SD Host controller: Intel Corporation Device 9d2b (rev 21) 00:1e.6 SD Host controller: Intel Corporation Sunrise Point-LP Secure Digital IO Controller (rev 21) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) #+end_src #+begin_src scheme (services (append (list (service openssh-service-type) (service dhcp-client-service-type)) %base-services))) #+end_src
bug#38500: Ruby is built against libruby-static.a
Python and Ruby link dynamically by default from the executable of the runtime to the runtime library. Most runtimes do that, it is a good design that allows reusing the runtime to the embedders. As exception of NodeJS which avoids this because of a design decision related to the distribution, and because it hasn't got an embedding API and an stable extension API (N-API) until 8.x, and Rust, due to lack of ABI stability. I didn't check GHC and Java yet, but most languages that have extension and mainly embedding API do that (JVM has embedding and extension API). I am not an expert about Guile but I can check the configure/Makefile of Ruby in order to see what flags do it need to compile against the dynamic library, and providing the static too as Debian distribution does for Ruby (or Guix itself for Python and libpython3.7m.so). El sáb., 7 dic. 2019 17:44, Brett Gilio escribió: > Vicente Eduardo writes: > > > I would like to have two versions, or at least the dynamic one, that's > the common way > > Ruby should be built, and also the Guixy style. > > This actually brings up a rather interesting point. What is the Guix > protocol on compilation for dynamic vs statically linked interpreters? > This is a prevalent issue not just for Ruby, but for also how we handle > GHC, Rust, JDK, and so on. > > Generally, I think we dynamically link most objects. _BUT_, I could be > missing part of the story here. So I am going to wait for the higher > powers that be to respond. > > In the mean time, when I get a moment, I will do some auditing on this > package to see if the issue is just that we are missing some compilation > procedure. Hopefully it is just as simple as that, but I still think the > issue of linkage style (dynamic vs static linkage) remains prevalent. > > Hopefully we hear some noise on this soon. > > -- > Brett M. Gilio > https://git.sr.ht/~brettgilio/ >
bug#38500: Ruby is built against libruby-static.a
I have checked the flags needed for compiling dynamically. It should be very easy to solve, just by adding this flag to the configure: --enable-shared This should be enough to compile Ruby runtime dynamic library and to compile Ruby interpeter executable against this lib. Reference: https://github.com/ruby/ruby/blob/0d63a2104777e467568a31037a6573e1879870c7/configure.ac#L3136 El dom., 8 dic. 2019 15:44, Vicente Eduardo escribió: > Python and Ruby link dynamically by default from the executable of the > runtime to the runtime library. Most runtimes do that, it is a good design > that allows reusing the runtime to the embedders. As exception of NodeJS > which avoids this because of a design decision related to the distribution, > and because it hasn't got an embedding API and an stable extension API > (N-API) until 8.x, and Rust, due to lack of ABI stability. > > I didn't check GHC and Java yet, but most languages that have extension > and mainly embedding API do that (JVM has embedding and extension API). > > I am not an expert about Guile but I can check the configure/Makefile of > Ruby in order to see what flags do it need to compile against the dynamic > library, and providing the static too as Debian distribution does for Ruby > (or Guix itself for Python and libpython3.7m.so). > > El sáb., 7 dic. 2019 17:44, Brett Gilio escribió: > >> Vicente Eduardo writes: >> >> > I would like to have two versions, or at least the dynamic one, that's >> the common way >> > Ruby should be built, and also the Guixy style. >> >> This actually brings up a rather interesting point. What is the Guix >> protocol on compilation for dynamic vs statically linked interpreters? >> This is a prevalent issue not just for Ruby, but for also how we handle >> GHC, Rust, JDK, and so on. >> >> Generally, I think we dynamically link most objects. _BUT_, I could be >> missing part of the story here. So I am going to wait for the higher >> powers that be to respond. >> >> In the mean time, when I get a moment, I will do some auditing on this >> package to see if the issue is just that we are missing some compilation >> procedure. Hopefully it is just as simple as that, but I still think the >> issue of linkage style (dynamic vs static linkage) remains prevalent. >> >> Hopefully we hear some noise on this soon. >> >> -- >> Brett M. Gilio >> https://git.sr.ht/~brettgilio/ >> >
bug#38528: Add test for `guix pull'
It would be nice to add a `guix pull' test as part of the test suite. This was discussed in bug #38455. The test should run `guix pull' but not apply change any symlink. Note that `guix pull --dry-run' does not catch enough errors. The current way to do it is to run guix pull --url=/path/to/checkout --profile=/tmp/guix.master -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
bug#38500: Ruby is built against libruby-static.a
Vincente, Brett, Brett Gilio 写道： Vicente Eduardo writes: I would like to have two versions, or at least the dynamic one, that's the common way Ruby should be built, and also the Guixy style. Important: static linking isn't the Guixy style at all! Statically linking different packages ‘subverts’ Guix, can subvert grafting and lead to undetected security holes. Generally, I think we dynamically link most objects. Correct. _BUT_, I could be missing part of the story here. So I am going to wait for the higher powers that be to respond. You could ask Pjotr Prins and David Thompson but I suspect that it was simply an oversight: most packages link dynamically by default because it's the sane thing to do, and it would have been reasonable to assume Ruby did too. If there is a good reason to link statically, it should be added in a comment. Kind regards, T G-R signature.asc Description: PGP signature
bug#38533: emacs-auctex breaks url package
Hi Guix, AUCTeX breaks Emacs' bult-in url package. This bug appears to have been introduced with commit 3ffdd00 and can be reproduced as follows: 1) Install ‘emacs’ and ‘emacs-auctex’. 2) Start Emacs and do M-: (require 'url), which will produce the following backtrace: --8<---cut here---start->8--- Debugger entered--Lisp error: (void-function TeX-add-style-hook) (TeX-add-style-hook "url" #f(compiled-function () #) LaTeX-dialect) require(url) eval((require (quote url)) nil) eval-expression((require (quote url)) nil nil 127) funcall-interactively(eval-expression (require (quote url)) nil nil 127) call-interactively(eval-expression nil nil) command-execute(eval-expression) --8<---cut here---end--->8--- It looks like Emacs tries to load the file $GUIX_PROFILE/share/emacs/site-lisp/style/url.elc, which is provided by ‘emacs-auctex’, instead of $GUIX_PROFILE/share/emacs/26.3/lisp/url/url.elc, which is provided by Emacs itself. Regards, Diego
bug#38528: Add test for `guix pull'
Hi, Thank Pierre to raise this issue. On Sun, 8 Dec 2019 at 16:40, Pierre Neidhardt wrote: > The current way to do it is to run > > guix pull --url=/path/to/checkout --profile=/tmp/guix.master When I put that in a test -- say tests/guix-pull.sh -- troubles arises... The main one appears because there is no user (chroot environment I guess). Currently, Guix looks at $USER and $LOGNAME then goes in "default" and applies "Migrating" profile code. Note that it appears too with non login shell as reported here [1], perhaps not related. [1] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00021.html What is the best: - set manually the variable USER to `whoami`? or - change to scheme code to call `whoami`? Does Guile expose that? All the best, simon
bug#38529: Make --pure the default for `guix environment'?
Hi Pierre, I agree. And also change the default which populates by the dependencies. Something like: guix environment foo --inputs-of bar should spawn an environment containing foo and the dependencies bar. Well, keeping the --ad-hoc option for compatibility. What do you think? All the best, simon
bug#38418: EXWM fails to start after a "reconfigure": split-string error
Hello! Pierre Neidhardt writes: > I've tested again after Clément pushed your fix, and the problem seems > to be gone with the following steps. > > - guix system reconfigure ... > - guix package -m manifest-including-emacs-and-exwm (not sure exwm > matters here) > - Log in. > > Closing this then. OK, good to know that your problem got resolved :-) Maxim
bug#30961: Byte compilation problem with emacs-org
Hello Konrad, Konrad Hinsen writes: > An Emacs installation that includes package emacs-org exhibits a > well-documented bug: certain uses of org-babel, such as using the > R language, lead to the error message > >Invalid function: org-babel-header-args-safe-fn > Does this still occur on latest master? If so, could you provide more detailed reproduction steps? I'd be interested in fixing any remaining problems. Thanks, Maxim
bug#38529: Make --pure the default for `guix environment'?
On Sun, Dec 08, 2019 at 04:42:07PM +0100, Pierre Neidhardt wrote: > --pure seems to be the more sensible behaviour. "Impure" environments > can have unexpected behaviours, so it makes sense to only allow them > when the user explicitly asks for it. I don't have an opinion about this in general except that I think that --ad-hoc should continue to work the way it does now, without --pure being implied.
bug#38533: emacs-auctex breaks url package
Hello Diego, Diego Nicola Barbato writes: > Hi Guix, > > AUCTeX breaks Emacs' bult-in url package. This bug appears to have been > introduced with commit 3ffdd00 and can be reproduced as follows: > > 1) Install ‘emacs’ and ‘emacs-auctex’. > 2) Start Emacs and do M-: (require 'url), which will produce the >following backtrace: > > Debugger entered--Lisp error: (void-function TeX-add-style-hook) > (TeX-add-style-hook "url" #f(compiled-function () #) > LaTeX-dialect) > require(url) > eval((require (quote url)) nil) > eval-expression((require (quote url)) nil nil 127) > funcall-interactively(eval-expression (require (quote url)) nil nil 127) > call-interactively(eval-expression nil nil) > command-execute(eval-expression) > > It looks like Emacs tries to load the file > $GUIX_PROFILE/share/emacs/site-lisp/style/url.elc, which is provided by > ‘emacs-auctex’, instead of > $GUIX_PROFILE/share/emacs/26.3/lisp/url/url.elc, which is provided by > Emacs itself. > > Regards, > > Diego This was caused by Emacs site-lisp/subdirs.el file, which when found in a profile's union was causing Emacs to *recursively* add everything under site-lisp to the load-path. Fixed with commit a7a492899a. Thank you for the report! Closing, Maxim
bug#38529: Make --pure the default for `guix environment'?
Hi Pierre, Pierre Neidhardt writes: > --pure seems to be the more sensible behaviour. "Impure" environments > can have unexpected behaviours, so it makes sense to only allow them > when the user explicitly asks for it. Unfortunately Guix packages often don't work well with --pure. Be it magit that depends on git, or Emacs that depend or coreutils, etc., there are many things that are expected to be propagated and aren't explicitly, by omission or sometimes for closure's size sake (when the feature is optional). We could argue that is a good reason for the proposed change :-). I think environments are great mostly for hacking and trying stuff quickly, where the guarantees of Guix do not matter as much as for profiles (and if they did, you'd be better with guix environment --container anyway). So, I guess that makes me more on the side of "let's no change the defaults for now". Maxim
