Re: ‘sudo’ leaves PATH unchanged… so what?
Hi Ludo, On Sat, 19 Jan 2019 23:52:59 +0100 Ludovic Courtès wrote: > Currently the ‘xdg-directory’ procedure (and thus ‘config-directory’, > which by default gives ~/.config/guix) does this: > > (or (getenv variable) > (and=> (or (getenv "HOME") > (passwd:dir (getpwuid (getuid > (cut string-append <> suffix))) > > I think giving $HOME higher precedence than /etc/passwd is the “right” > behavior (the behavior people expect from programs in general), but it’s > true that it’s confusing in this case. I think it's good that one can override defaults using environment variables. But if it was this instead: > (or (getenv variable) > (and=> (cond ((getenv "SUDO_USER") (passwd:dir (getpwnam (getenv "SUDO_USER" ((getenv "HOME") (getenv "HOME")) (_ (passwd:dir (getpwuid (getuid) > (cut string-append <> suffix))) ... it would be still overridable by the user (by unsetting SUDO_USER and setting HOME), so it would be fine. (sudo without "-E" also nukes XDG_CONFIG_HOME, so it's ok if that gets preferred if it's there) Or we could just document "sudo -E" in the documentation and do nothing. I have a slight preference for the latter since it's less magical. But from a user experience standpoint the former does what is probably expected. pgp4KWOSTD6NV.pgp Description: OpenPGP digital signature
Re: 01/01: tests: docker: Run a guest guile inside the docker container.
Hi Mark, Mark H Weaver skribis: > This introduces a duplicate field initializer in the expanded 'package' > object, because the 'dummy-package' macro introduces its own > 'build-system' field initializer. From (guix tests): > > (define-syntax-rule (dummy-package name* extra-fields ...) > "Return a \"dummy\" package called NAME*, with all its compulsory fields > initialized with default values, and with EXTRA-FIELDS set as specified." > (package extra-fields ... > (name name*) (version "0") (source #f) > (build-system gnu-build-system) > (synopsis #f) (description #f) > (home-page #f) (license #f))) I realized I must have used the same idiom in some of the unit tests. Did you catch anything there, Mark? Ludo’.
Re: Swag for FOSDEM!
Hi Chris! Christopher Baines skribis: > Ludovic Courtès writes: > >> Hello Guix! >> >> I realize we don’t have a coordinated plan to get stickers to FOSDEM, >> and maybe we should address that. :-) >> >> Is anyone willing to help with that? (We could consider reimbursing >> using the FSF fund if it’s a reasonable amount.) > > I'll bring some stickers along, the same I've brought to FOSDEM the last > time. There not the best stickers for mass distribution though, as the > sheets are rather large to give out. Awesome! Someone had show pictures of stickers that included the word “Guix” and were probably easier to distribute, but I forgot who it was. It’d be nice to have some like this as well. Thank you, Ludo’.
Re: [PATCH] gnu: Add glibc-locales variants for older versions of glibc.
Hi, Ricardo Wurmus skribis: > Ricardo Wurmus writes: > >> * gnu/packages/base.scm (make-glibc-locales, make-glibc-utf8-locales): New >> procedures. >> (glibc-locales): Express in terms of make-glibc-locales. >> (glibc-utf8-locales): Express in terms of make-glibc-utf8-locales. >> (glibc-locales-2.27, glibc-utf8-locales-2.27): New variables. > > This is for the benefit of people who run Guix on top of a foreign > distro. On a Guix system people can simply use the “locale-libcs” field > of their operating system declaration, but on a foreign distro there is > no way to install a locales package for older versions of glibc. > > This patch generates variants for version 2.27 and overrides the name so > that both “glibc-locales” and “glibc-locales-2.27” can be installed into > the same profile. (Without the name override that’s not possible.) Adding the packages makes sense to me. I don’t like the package name trick, but I don’t have a better solution. Perhaps we could have a special property to explicitly allow for several versions of this package in the same profile (say ‘allow-multiple-versions?’), but that’s a bit more work. Thanks, Ludo’.
Re: ‘sudo’ leaves PATH unchanged… so what?
Danny Milosavljevic skribis: > There's an environment variable "SUDO_USER" which still contains the name > of the original user. > > We could check SUDO_USER instead of USER if USER=root, otherwise check USER. Or perhaps we could ignore HOME when SUDO_USER is set, and instead honor /etc/passwd only? Ludo’.
Re: ‘sudo’ leaves PATH unchanged… so what?
Hey, Caleb Ristvedt skribis: > I'd just like to add that if a user has guix installed for root but only > really keeps their user's guix up to date (I imagine a fairly common > situation), they're in for a weird situation when using sudo: a > bleeding-edge guix will complain about being outdated, since sudo (even > with -E) sets $USER, which is used to determine which file's timestamp > should be used for deciding whether the installed guix is outdated. > Basically, your shiny new guix warns you that someone else's dirty old guix > is old. True, that’s super weird! (Actually I think it’s $HOME, not $USER.) Currently the ‘xdg-directory’ procedure (and thus ‘config-directory’, which by default gives ~/.config/guix) does this: (or (getenv variable) (and=> (or (getenv "HOME") (passwd:dir (getpwuid (getuid (cut string-append <> suffix))) I think giving $HOME higher precedence than /etc/passwd is the “right” behavior (the behavior people expect from programs in general), but it’s true that it’s confusing in this case. Thoughts? Ludo’.
Install doc + templates overhaul
I've just re-installed Guix from a 0.16 image. My first time in a year, and I've had the opportunity to have a fresh look at the installation manual. I've taken note of a few confusing points that gave me a hard time installing Guix (even the 2nd time :p) so here they are. I'll send a patch to address them if you people agree. - From the manual, 6.1.4 Preparing for Installation: --8<---cut here---start->8--- If you instead wish to use EFI-based GRUB, a FAT32 “EFI System Partition” (ESP) is required. This partition should be mounted at ‘/boot/efi’ and must have the ‘esp’ flag set. E.g., for ‘parted’: --8<---cut here---end--->8--- Actually the EFI partition can be mounted anywhere (/efi or /boot are also customary), it's up to the users to make sure they are pointed at the right mounted location. --8<---cut here---start->8--- Also mount any other file systems you would like to use on the target system relative to this path. If you have ‘/boot’ on a separate partition for example, mount it at ‘/mnt/boot’ now so it is found by ‘guix system init’ afterwards. --8<---cut here---end--->8--- That's not consistent with /mnt/boot/efi that was just mentioned above. Besides, I think we should mention the word "EFI" in this paragraph so that people find this paragraph when they search for the EFI term to make sure they've covered everything - From 6.1.5 Proceeding with the Installation --8<---cut here---start->8--- • Make sure the ‘bootloader-configuration’ form refers to the target you want to install GRUB on. It should mention ‘grub-bootloader’ if you are installing GRUB in the legacy way, or ‘grub-efi-bootloader’ for newer UEFI systems. For legacy systems, the ‘target’ field names a device, like ‘/dev/sda’; for UEFI systems it names a path to a mounted EFI partition, like ‘/boot/efi’, and do make sure the path is actually mounted. --8<---cut here---end--->8--- At the end, it's unclear whether the EFI partition must be _currently_ mounted or if the config.scm must have a mount point declaration. Actually, it's both, and that be made explicit I think. Also see the next point: - From gnu/system/examples/desktop.tmpl: --8<---cut here---start->8--- ;; Use the UEFI variant of GRUB with the EFI System ;; Partition mounted on /boot/efi. (bootloader (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi"))) ;... (file-systems (cons (file-system (device (file-system-label "my-root")) (mount-point "/") (type "ext4") (dependencies mapped-devices)) %base-file-systems)) --8<---cut here---end--->8--- The EFI partition is missing from the file-systems declaration!! - All templates: I remember this was discussed before, but shouldn't we replace (cons* ...) with (list ...)? It's easier to grok for users new to Lisp. - In the operating-system record, what's the default value of home-directory (in (users (list (user-account (home-directory ...)? Shouldn't default to (string-append "/home/" name)? That could also spare us some potential mistakes at install-time. - I was surprised to see that from the install image, curl, git, etc. would fail with an SSL error. It's annoying because I really needed to get my config.scm from an online source. I only briefly investigated: the environment has --8<---cut here---start->8--- SSL_CERT_DIR=/etc/ssl/certs SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt --8<---cut here---end--->8--- but the install image only has a /etc/ssl file. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: perl for arm-linux-gnueabihf
Hi Gérald, > *guix build --target=arm-linux-gnueabihf* *perl* fails with the following > output: https://pastebin.com/QF0xKAmR Here’s the output copied from pastebin: --8<---cut here---start->8--- starting phase `remove-extra-references' Backtrace: 13 (primitive-load "/gnu/store/rdqwl7zaa2nrqpw954aq9pzlllp…") In ice-9/eval.scm: 191:35 12 (_ _) In srfi/srfi-1.scm: 863:16 11 (every1 # …) In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm: 799:28 10 (_ _) In ice-9/eval.scm: 619:8 9 (_ #(#(#(#(#(#(#) …) …) …) …) …)) In ice-9/boot-9.scm: 841:4 8 (with-throw-handler _ _ _) In ice-9/ports.scm: 444:17 7 (call-with-input-file _ _ #:binary _ #:encoding _ # _) In /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm: 641:26 6 (_ _) 667:26 5 (_ # …) In srfi/srfi-1.scm: 466:18 4 (fold # …) In ice-9/eval.scm: 202:51 3 (_ #(#(#(#(#(#(# …)) …) …) …) …)) 163:9 2 (_ #(#(#(#(#(#(# …)) …) …) …) …)) In unknown file: 1 (string-append "incpth='" #f "/include'\n") In ice-9/boot-9.scm: 752:25 0 (dispatch-exception _ _ _) ice-9/boot-9.scm:752:25: In procedure dispatch-exception: In procedure string-append: Wrong type (expecting string): #f builder for `/gnu/store/zj5xld149ibdyc4nlm2dj41jnjm9bqyn-perl-5.28.0.drv' failed with exit code 1 build of /gnu/store/zj5xld149ibdyc4nlm2dj41jnjm9bqyn-perl-5.28.0.drv failed --8<---cut here---end--->8--- I have never tried to cross-compiled packages for “arm-linux-gnueabihf”. I don’t know if this is expected to work. -- Ricardo
