IRC channel logs

<Rukako>H-Hi, I am interested in applying to join the guix gsoc and so was wondering if there is any mentor around here.

<civodul>hello Rukako

<civodul>Rukako: i'd be a (co-)mentor but... i'm going to bed right now :-)

<Rukako>ah, okay

<Rukako>see you tomorrow then hopefully!

<civodul>right, or let's talk by email?

<civodul>or you can chat with those still around here

<Rukako>ah, okay

<civodul>good night/day!

<Apteryx>Why did we add a new boost package for 1.66 instead of just upgrading our existing boost package?

<pkill9>does --with-input also affect propagated inputs?

<pkill9>meaning, can you dynamically change propagated inputs with --wtih-input ?

<g_bor>hello guix!

<civodul>Hello Guix!

<catonano>hi civodul !

<catonano>hi g_bor !!

<rekado_>Hi Guix!

<rekado_>when I check out the same version of Guix on two different computers, shouldn’t the derivations be identical?

<rekado_>I currently have the problem that for some reason they are not.

<rekado_>I do “guix build -d r-rcas” on both machines and the derivations differ.

<rekado_>they are both on python-updates

<civodul>rekado_: that would be a bug, indeed

<civodul>could you try to diff the .drv files?

<rekado_>will do

<civodul>you can "guix copy" it from one maching to another, then ediff-regions-wordwise

<rekado_>the order of items differs

<civodul>could you paste it?

<rekado_>one of them has the r-plotly derivation listed first and the sed derivation second, the other has the sed derivation first.

<civodul>are these the exact same file names?

<rekado_>no. The plotly derivation name differs.

<civodul>ok, so we need to recurse and find out the first one that differs

<rekado_>another one that differs is r-shiny

<civodul>could you try going deeper in the graph until you find the package that differs?

<rekado_>will try that.

<civodul>cool

<jboy>does anybody have experience with using this TP-Link PCI-e wifi card with linux-libre? It apparently uses ath9x drivers, which should be fine, in my understanding. Is that right? https://wikidevi.com/wiki/TP-LINK_TL-WN781ND_v2

<civodul>jboy: ath9x should definitely be fine

<civodul>i use it with a wifi dongle, though it's a different one

<jboy>thanks civodul

<jboy>it's not on the h-node list, so I wanted to make sure.

<civodul>jboy: if you're sure that it's ath9k, it sould be fine

<civodul>*should

<efraim>Enlightenment's language switcher doesn't work

<rekado_>efraim: language switching in general is a bit wonky.

<rekado_>efraim: Arabic via ibus doesn’t seem to work; and that’s using some X11 feature IIRC.

<efraim>It was working between English and Hebrew on xfce, without adding he_IL.utf8 locale

<efraim>My guess is ibus is an input somewhere on xfce, EFL is built without it to keep the closure smaller but it might be needed, I'll try to check it out

<riscii>i am getting this error on 'guix system reconfigure': https://pastebin.com/9G0RGSPw

<riscii>is this how i should use mapped devices and filesystems, https://pastebin.com/ma5Rfg2P

<rekado_>civodul: in the derivation for r-shiny it is curious that the derivations for *all* javascript packages differ; and it’s *only* these derivation, none other.

<rekado_>the module-import and module-import-compiled derivations differ for js-datatables. Nothing else differs.

<rekado_>checking those now

<rekado_>civodul: the module-import derivation differs in which popen.scm they use. The only difference here is an embedded reference to bash-minimal.

<rekado_>On one machine this reference is "/gnu/store/mm0zclrzj3y7rj74hzyd0f224xly04fh-bash-minimal-4.4.12/bin/bash"

<rekado_>one the other it is "/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12/bin/bash"

<rekado_>I would like to note that my workstation has both of these variants of bash-minimal

<rekado_>the same is true for the other machine whose derivations I’m comparing.

<rekado_>I have to admit that I’m not clear on where that bash-minimal comes from. When I build bash-minimal on both of these machines I get /gnu/store/v1hqynfc538v3gdq5fmr15y1bk939f5k-bash-minimal-4.4.12, which is different from either of these references.

***fkz is now known as Guest18039

<civodul>rekado_: "guix build -e '(@@ (gnu packages commencement) bash-final)' --no-grafts" gives /gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12

<rekado_>civodul: yes. It’s also the same on these two machines.

<rekado_>so where does /gnu/store/mm0zclrzj3y7rj74hzyd0f224xly04fh-bash-minimal-4.4.12 come from?

<civodul>hmm

<rekado_>it looks like they ended up with different guile variants from which to pick the popen.scm source file.

<civodul>/gnu/store/mm0zclrzj3y7rj74hzyd0f224xly04fh-bash-minimal-4.4.12 derives from /gnu/store/s3vbai7lawhb2nn73gg2063ilgsvvdyk-bash-minimal-4.4.12.drv which was built from guile-2.0.14 (bootstrap guile)

<civodul>ooh, not bootstrap guile actually, but really guile@2.0, which we use for grafts

<civodul>right, /gnu/store/mm0zclrzj3y7rj74hzyd0f224xly04fh-bash-minimal-4.4.12 is a graft

<civodul>of "/gnu/store/icz3hd36aqpjz5slyp4hhr8wsfbgiml1-bash-minimal-4.4.12"

<civodul>which is the ungrafted 'bash-final'

<civodul>so far so good

<rekado_>interesting

<civodul>so isn't the difference simply --no-grafts vs. with-grafts?

<rekado_>no

<rekado_>the difference is in popen only.

<civodul>right, but popen refers to the grafted bash-final in one case, and the ungrafted one in the other case

<rekado_>when I build js-datatables on both machines without grafts I get different derivations.

<civodul>ok, lemme try

<rekado_>I get /gnu/store/2rhdycz2vip4j68q3ikk4d4dxpijr1wq-js-datatables-1.10.15.drv on my workstation

<civodul>i have /gnu/store/wh5i2jvws5yvppvmnwx7np38mq4c7rmm-js-datatables-1.10.15 like on berlin

<rekado_>(that’s all on python-updates btw)

<civodul>is the problem only on python-updates?

<rekado_>and I get /gnu/store/6873lrg8xa5vd021v4cqsqifd93n2sl1-js-datatables-1.10.15.drv on my local cuirass VM.

<rekado_>I have only tried it with python-updates, because that’s what I’m using for the paper.

<rekado_>(this is all the result of failing to run guix challenge for the final reproducibility analysis)

<civodul>ACTION tries

<civodul>on commit 82a63cbf789e0a1a9f519d90ec2fe4d95283dd64, --no-grafts, i have /gnu/store/2rhdycz2vip4j68q3ikk4d4dxpijr1wq-js-datatables-1.10.15.drv

<civodul>like you on your workstation

<rekado_>I’m on the same commit on both machines.

<civodul>ok

<civodul>how did you obtain /gnu/store/6873lrg8xa5vd021v4cqsqifd93n2sl1-js-datatables-1.10.15.drv in your VM?

<civodul>by running "./pre-inst-env guix build js-datatables"?

<rekado_>I’m running cuirass in the VM.

<civodul>so that drv was computed by Cuirass?

<rekado_>so it had built this at some point earlier. Now when I ask for it with "./pre-inst-env guix build js-datatables" I get this derivation.

<rekado_>erm "./pre-inst-env guix build -d --no-grafts js-datatables"

<civodul>ok

<civodul>found it: a mistake in build-system/minify.scm

<rekado_>the VM hadn’t been updated in a long time. It was at 0.13 or something. Then I upgraded to the latest Guix, reconfigured, rebooted, modified the cuirass specs to build python-updates.

<rekado_>hah!

<civodul>it imports (ice-9 popen) in the build env

<civodul>thus, the (ice-9 popen) you get depends on the one you run "on the host side"

<civodul>it's annoying that it's so easy to make this mistake

<civodul>(and so hard to find out ;-))

<rekado_>… where does this happen?

<rekado_>I only see one use-modules expression

<civodul>in %minify-build-system-modules

<rekado_>ah.

<rekado_>so it’s not a problem when the modules there are Guix modules only, but it is a problem if these are other Guile modules?

<civodul>rather, we *want* (guix ...) modules to be imported on the build side

<civodul>but we don't want Guile modules to be imported there, because they're already available

<rekado_>I see.

<civodul>IOW, (ice-9 *) is something we take for granted on the build side

<rekado_>As the author of that file I’m very sorry!

<civodul>no problem!

<rekado_>thanks for finding the cause!

<civodul>as i said, it's very easy to get that wrong

<civodul>because there's "modules in scope" and there's "imported modules"

<civodul>rekado_: i let you commit the fix?

<rekado_>I’ll give it a try.

<rekado_>at some point I’ll still need to (use-modules (ice-9 popen)), because that’s used in guix/build/minify-build-system.scm

<rekado_>I’ll play with this first to get a feeling for it.

<civodul>then you need to add it to #:modules but not to #:imported-modules

<civodul>but currently (ice-9 popen) is not in (use-modules ...) anyway

<rekado_>I just added “(use-modules (ice-9 popen))” to the “minify” procedure in minify-build-system.scm and removed (ice9 open) from the list of modules.

<rekado_>if we can take it for granted on the build side then this should be enough, no?

<rekado_>(I built js-datatables successfully with this change)

<rekado_>but maybe not even that is necessary; (guix build minify-build-system) already has a use-module line for (ice-9 popen)

<rekado_>okay, it *must* be added to “modules”, just not to “imported-modules”, as you wrote.

<rekado_>with that change I get the same derivations on both sides.

<rekado_>I understand why it’s not okay to add it to imported-modules, but I don’t understand why it has to be added to “modules”.

<rekado_>the packages build fine without adding (ice-9 popen) to “modules”, but the derivations differ. Doesn’t this mean that we *cannot* take (ice-9 *) for granted on the build side?

<AMDmi3>hi, guix web site is broken again. https://www.gnu.org/software/guix/packages/M/page/2/ -> ok, https://www.gnu.org/software/guix/packages/M/page/3/ -> 404

<civodul>rekado_: i'm not even sure it must be in #:modules since currently it's not there

<civodul>AMDmi3: thanks for the notice; the missing page should be online within a few seconds/minutes

<rekado_>civodul: yes, you’re right. I made a mistake in the previous comparison. The derivations are identical simply after removing (ice-9 popen) from the imported modules.

<civodul>cool

<yang__>Does GUIX have the MIPS port for Lemote Yeeloong?

<efraim>adding ibus to efl increases the closure from 616.7 MB to 958.8 MB

<civodul>hello yang__

<yang__>hi

<civodul>yang__: it does, though we no longer provide pre-built binaries ("substitutes")

<jonsger[m]>looks like hydra doesn't have substitutes for 0.14 anymore...

<rekado_>jonsger[m]: does berlin.guixsd.org still have them?

<jonsger[m]>rekado_: how do I test it?

<rekado_> [the guix command] --substitute-urls="https://berlin.guixsd.org https://mirror.hydra.gnu.org" [other args]

<civodul>jonsger[m]: could you give an example of a missing substitute?

<jonsger[m]>hello, but there seems to be an other problem...

<jonsger[m]>I test the opensuse package of guix which does almost everything but authorizing the keys is still missing

<jonsger[m]>so everything is alright. no missing substitutes :)

<civodul>on berlin or hydra?

<chewzerita>Finishing up packaging r-tidyverse again, going better this time: 1 commit per package

<rekado_>chewzerita: thanks!

<jonsger[m]>civodul: I don't know. I enabled both ...

<civodul>jonsger[m]: can you try running the same 'guix' command with just --substitute-urls=https://mirror.hydra.gnu.org ?

<jonsger[m]>did also work

<AMDmi3>civodul: thanks! these failures are quite frequent lately, could the site generation process be made more reliable?

<civodul>AMDmi3: yeah, this is being negotiated with the FSF sysadmins

***lostcoffee is now known as atw

<AMDmi3>civodul: great, thank you again

<jlicht>hi guix!

<mbakke>Sup jlicht :)

<jlicht>enjoying my Monday mbakke :-)

<mbakke>I wonder if Guix can somehow detect when the NSS compatibility layer is used and fail gracefully, instead of giving these "the guixbuilder group does not exist" messages.

<jlicht>What is "icu" and would we want to use the "system" variant of this when building packages? (Specifically, Nodejs bundles an icu dependency, but can be built a `with-intl` flag to point to a systemwide installation)

<bavier`>jlicht: we generally prefer using system packages where possible

<mbakke>jlicht: You'll find ICU in (gnu packages icu4c). It stands for Internationalization Components for Unicode IIRC.

<thorwil>is there a way to chroot into a guix sd installtion and have a fully functional shell?

<jlicht>thanks bavier`, mbakke :-). I am finally making some time to properly delete all bundled cruft from nodejs source packages and this was one of the things that I missed earlier. (Already from 30M to 12M!)

<mbakke>Wow, nice! :)

<mbakke>thorwil: You can try to `chroot /mnt/guixsd /var/guix/profiles/system/profile/bin/bash`.

<mbakke>You may need to bind-mount /var/guix/profiles/system/profile to /run/current-system for things to work.

<chewzerita>Just submitted the patches to add r-tidyverse!

<thorwil>mbakke: `chroot /mnt/guixsd /var/guix/profiles/system/profile/bin/bash` does lead to a shell with no commands available. i can't figure out how to that bind-mount

<thorwil>due to fun like: mount: mount point run/current-system is a symbolic link to nowhere

<mbakke>thorwil: Try to `mount -o bind /mnt/guixsd/var/guix/profiles/system/profile /mnt/guixsd/run/current-system`. Then `chroot /mnt/guixsd /run/current-system/profile/bin/bash` and `source /etc/profile`.

<mbakke>I have never tried chrooting into a GuixSD, but it would be good to have instructions in the manual.

<civodul>mbakke: detecting a faulty nsswitch.conf is hard because this is all within libc

<mbakke>Oh wait, /run/current-system is a symlink to the store.

<civodul>anyone familiar with Heroku: https://devcenter.heroku.com/articles/buildpack-api#buildpack-api ?

<civodul>someone at work is suggesting creating a "buildpack"

<civodul>and i'm not sure what that means :-)

<thorwil>mbakke: yes, "is a symbolic link to nowhere" again

<mbakke>thorwil: You may get away without bind mounting, and instead just `chroot /mnt/guixsd /run/current-system/profile/bin/bash`, and then sourcing `/etc/profile`.

<thorwil>mbakke: "mount point /media/ssd-alt-system/run/current-system/profile/bin/bash does not exist"

<thorwil>resolving that symlink one level doesn't suffice

<thorwil>sudo mount /media/ssd-alt-system /media/ssd-alt-system/gnu/store/afhf38fwp0clqiv6mv672xmdjp7raici-profile/bin/bash => mount: mount point /media/ssd-alt-system/gnu/store/afhf38fwp0clqiv6mv672xmdjp7raici-profile/bin/bash is a symbolic link to nowhere

<mbakke>thorwil: What do you get if you try to `chroot /mnt/guixsd /run/current-system/profile/bin/bash` ?

<thorwil>mbakke: a bash that knows no commands

<jonsger[m]>civodul: we did buildpacks at work for cloudfoundry. I'm not really sure about the detail but it contains binaries. You could then put your app (ruby based for example) somehow in it and it runs :P

<thorwil>i thought the second path for chroot should be from the point of view of the outer system, too!?

<mbakke>thorwil: Try `source /etc/profile`.

<thorwil>ah right

<mbakke>thorwil: The second path is relative to the chroot :)

<civodul>jonsger[m]: i see :-) i hear it's also what's behind GitLab CI, and we have that at work

<mbakke>Note, for this chroot to actually be usable, you probably also need to bind /dev, /proc, and /sys inside the chroot.

<thorwil>mbakke: note that i did bind proc sys and dev beforehand. i just did a "guix package -s wayland" which worked fine

<thorwil>lol

<mbakke>thorwil: Great :)

<thorwil>there's a "guile: warning: failed to install locale", though, which i think didn't happen in the "real thing"

<thorwil>what would be a good, quick test for potential issues here?

<mbakke>thorwil: You could try to run `guix-daemon`, and installing something to a profile.

<mbakke>Would you be willing to post a roundup about chrooting into a GuixSD system on help-guix@gnu.org, or even better add instructions to the manual? :)

<thorwil>mbakke: yes to the first. head to full to attempt the later. thank you!

<mbakke>thorwil: Thank *you* for being so brave ;)

<mbakke>civodul: Is it possible to cancel a Hydra evaluation? The Meson fixes will invalidate most substitutes, and there are still 1300 builds in the queue.

<mbakke>I'll update bluez, mesa and friends as well, since they "only" add ~300 more rebuilds.

<thorwil>mbakke: `su` to a user, `guix` not found. another `source /etc/profile`. than `guix package -i emacs-bash-completion` failed with "guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused"

<mbakke>thorwil: You'll probably need to start the daemon manually first.

<thorwil>mbakke: oh well: https://bpaste.net/raw/08cb922aac0b

<mbakke>thorwil: Hmm! As a dirty (and dangerous) workaround, you could try to run the daemon with --disable-chroot.

<thorwil>mbakke: could this have to do with `herd start cow-store /mnt` or rather the lack of it?

<mbakke>thorwil: Good question, I'm not very knowledgeable in this area. Perhaps civodul has some insight :)

<civodul>uh, i didn't follow the whole story though :-)

<civodul>if you chrooted in a previously-installed GuixSD, then i probably can't really help

<civodul>i've never tried it

<bavier`>thorwil: I've been (roughly) following https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org the last few days

<bavier`>which discusses running a guix image within proot

<mbakke>civodul: Do you know how to cancel the queued staging builds on Hydra?

<civodul>mbakke: you have to go to the eval and click "cancel pending builds" under "actions" or something

<civodul>currently hydra.gnu.org is damn slow thno

<civodul>*though

<civodul>there's an eval of 'master' running

<mbakke>civodul: Great, thanks.

<civodul>i'll check again later, but do ping me if necessary

<civodul>BTW did you check whether berlin picks things up more quickly?

<mbakke>civodul: The master eval will probably timeout unless you stopped the queue runners.

<mbakke>I haven't checked berlin in a while.

<civodul>i did stop the queue runner

<mbakke>Oh, I see the queue is stopped.

<rekado_>I’m using “guix challenge --substitute-urls=http://my-server:3000 python-xlrd” to compare the local build of python-xlrd with the remote build on my-server. That server runs “guix-publish” and listens on port 3000.

<rekado_>yet I always get this message: guix challenge: warning: could not challenge '/gnu/store/79k768y58gsny1znqpvh11yw12vgnvmw-python-xlrd-1.0.0': no substitutes

<rekado_>I checked on the remote: that store item does exist.

<rekado_>I also have a local build.

<rekado_>I removed the substitute cache already, but it looks like guix doesn’t even try to check for substitutes there.

<rekado_>I find that a little strange.

<civodul>did you try to wget that narinfo?

<civodul>wget -O - http://you-server/79k768y58gsny1znqpvh11yw12vgnvmw.narinfo

<rekado_>it does exist and it does return info about the substitute.

<rekado_>the URL it tells me about also does exist.

<civodul>ok

<civodul>you can also "rm -rf ~/.cache/guix/substitute"

<rekado_>yeah, that did it.

<rekado_>thanks!

<civodul>cache invalidation is hard :-)

<mbakke>civodul: the master evaluation timed out, can you try restarting it?

<mbakke>(I'm on a tiny computer without credentials available)

<davexunit>I tried to update guix daemon on my hodge-podge ubuntu machine and now it insists that guix-builder isn't a group even though it most definitely is.

<davexunit>good times.

<davexunit>running (getgrnam "guix-builder") in a guile repl works fine

<efraim>Install nscd, its magic

<efraim>davexunit: ^^

<davexunit>wat

<davexunit>"error: corrupt input while restoring archive from socket"

<davexunit>well, that's progress I guess

<davexunit>thanks for the tip efraim

<efraim>its some name service daemon that was broken out of glibc and installing it seems to fix it

<davexunit>gotta go afk now. thanks again for the tip.

<efraim>:)

<efraim>oh i forgot all about libepoxy