IRC channel logs

<nikita>hm. was it only janneke, or who else I could talk to/email about source bootstrapable details if I'm trying to understand if or how to apply it for a different OS and lib outside of guix? last time I looked at this was years ago.

<patrickt>nikita: Might be worthwhile directing this question to IRC #bootstrappable or the mailing-list: https://bootstrappable.org/who.html

<nikita>thanks!

<patrickt>Anytime, cheers!

<ekaitz>hey people! how do I set an environment variable from my config.scm?

<ekaitz>oh oh... session-environment-service-type seems to do the job

<VesselWave>Hello! Does anybody know how to set gtk dark mode on guix system? I tried ~/.config/gtk-{3,4}.0/settings.ini `gtk-application-prefer-dark-theme=1 gtk-theme-name = "Adwaita-dark"` and `gsettings set org.gnome.desktop.interface {color-scheme prefer-dark,gtk-theme 'Adwaita-dark'}`

<VesselWave>Testing in keepassxc

<tedium>Is there a way to configure layout and resolution for a multi-monitor setup in a guix system config? I haven't found anything searching around. Gnome keeps getting reset to the default layout after power cycling.

<two[m]>keepassxc is qt5

<two[m]>so you need to set qt theme, not gnome

<two[m]>if you want gnome keepass, the package is secrets

<VesselWave>two[m]: Thank you! But how to set qt5 theme?

<two[m]>sorry i don't know

<two[m]>i use gnome and i only use qt apps like krita which do their own themes

<two[m]>also i use debian and it might be different there

<two[m]>but the package name for gnome's keepass frontend is the same

<VesselWave>Ok, thanks

<two[m]>qt should have some file in .config

<two[m]>ok

<VesselWave>Hello, Firefox on on other distros switches sites to dark mode if they support it. Icecat on guix system doesn't do it even with GTK_THEME=Adwaita:dark . Does some one have a solution?

<singpolyma>Is it maybe just due to IceCat being older than that feature?

<mekeor[m]>tedium: do you use xorg? maybe you can write a xorg config inside your guix system config

<tedium>mekeor[m] I am, I'll try looking into that, thanks

<Michal_Atlas[m]>Hello, any ideas why an LVM mapped device wouldn't show up in /dev/mapper at boot time? Shepherd fails with No such file or directory on one of the related volumes to the one I need, but when I checked the actual directory it has nothing in it except control.

<TheSkylarverncc[>why doesn't icecat have a hardware acceleration option?

<jpoiret>Michal_Atlas[m]: is it needed for.

<jpoiret> For boot* sorry

<sneek>wb efraim :)

<efraim>sneek: botsnack

<sneek>:)

<lissobone>Houston, we've got a problem.

<lissobone>Every time I reconfigure my system (the config is just the default one with one extra user added for my sister) and run it with the newer 6.2 linux-libre kernel, it hangs early while booting.

<lissobone>I can, of course, just use the old config, but this is a little bit embarassing. I don't know what's the problem, but it only occurs when I boot with the newest kernel. Right now I'm using the older 6.0 one.

<lissobone>I've been looking through the documentation looking for any mentions of using specific kernel versions. The (kernel) parameter of the (operating-system) appears to only accept 'linux-libre' and 'gnumach' without any version numbers.

<lissobone>When I reconfigure the system without rebooting, everything works fine with my mate session getting replaced with xfce just as I specified.

<lissobone>What could it be?

<jlicht>lissobone: it doesn't work if you specify (e.g.) `(kernel linux-libre-lts)'?

<lissobone>Hmm, is that in the documentation? Let me double check (just for clarity).

<lissobone>I will try that.

<jlicht>I'm just guessing, but how did you try to specify the kernel version before that?

<lissobone>Ofc I did, using the regular @ (whaterer it's called) syntax.

<lissobone>It doesn't seem to accept such specifications.

<lissobone>Hold on, I will place a block in tetris (I'm in Emacs).

<lissobone>Done.

<lissobone>Reconfiguring (attempting)...

<jlicht>lissobone: specifications like that won't work. You need to use whatever is in place of XXX in the `(define-public XXX (package...))'

<lissobone>LOL! It works (at least it's thinking!)!

<lissobone>It's checking for substitues.

<lissobone>It's downloading.

<lissobone>Thank you for assistance, mighty wizard.

<lissobone>I think I like the non-graphical TTY, thanks to Emacs.

<jlicht>lol, happy to help

<lissobone>Hope it doesn't hang next time.

<lissobone>I've got, like, 5 old configs in the grub menu.

<lissobone>It has finished. Time to reload.

<lissobone>Yay, thanks! I am in my XFCE4 session now.

<jlicht>lissobone: \o/

<Guest14>i installed guix on my 16gb usb stick and if i run guix system init /mnt/guix/system.scm /mnt it says that /mnt requires 6gib but only 600mib is available

<Guest14>with installed i mean the guix iso installer

<lilyp>did you start the cow-store?

<Guest14>ah, no I did not. I guess with that it is going to work?

<lilyp>yes, it should

<Guest14>thanks

<jpoiret>ssh root@127.0.0.1 -p 5555 "This is the GNU Hurd. Welcome." finally!

<jonsger>:)

<lissobone>"This is the GNU system. Welcome".

<Michal_Atlas[m]><jpoiret> "Michal_Atlas: is it needed for." <- Mhm, it is, and it seems to be dependent on the type of volume. I had a cached one which had this problem and then I gave up and just used a regular one and that one works. I'm not sure if this is a bug, or my error somewhere.

<jpoiret>Michal_Atlas[m]: did you add it to the (mapped-devices ...) field of your operating-system configuration?

<Michal_Atlas[m]>Yes, tried both the one volume I was booting from and all the volumes I'm the groups as targets

<jpoiret>is your LVM across multiple disks?

<Michal_Atlas[m]>Yes

<jpoiret>that might be the problem. maybe it takes some time for the lvm mappers to come online because they're spread among multiple disks

<jpoiret>do they also use luks?

<Guest4>I have a user in my system config and the user is created but it doesn't have any bash files. If I login I can't even create files in my own home dir

<Guest4>I installed with guix init

<jpoiret>janneke: i need some input with the bootstrap process, I'm trying to get native i586-pc-gnu compilation working now

<jpoiret>i see the %bootstrap-inputs include the linux headers (and only them) for i586/x86_64, but it seems they're not used by %bootstrap-inputs+toolchain in commencement

<janneke>jpoiret: eh, that's only for i686-LINUX, x86_64?

<jpoiret>yes

<janneke>for the hurd, its glibc, gcc, binutils etc

<jpoiret>sorry, that's what I meant, I don't really see why there's this special case here that includes the linux-headers when the variable ends up not being used for i686-linux

<jpoiret>this is a question about the i686-linux case for now

<jpoiret>I'm trying to see how the kernel headers end up being available

<jpoiret>native i586-pc-gnu compilation doesn't work right know because from what I can see we're missing the hurd headers

<janneke>jpoiret: you're right; hysterical raisins

<janneke>guess i didn't clean-out that bit

<janneke>the previous, (reduced binary seed) bootstrap, still used it and had the coreutils bit in there,

<jpoiret>that's what I was thinking, but just making sure

<jpoiret>are kernel headers required when using glibc in general?

<janneke>and yeah, looks like hurd headers are missing

<janneke>yeah, i guess so

<janneke>btw...

<janneke>"<jpoiret> ssh root@127.0.0.1 -p 5555 "This is the GNU Hurd. Welcome."

<janneke>\o/ !!! well done

<jpoiret>because it looks like the %bootstrap-inputs+toolchain ends up without kernel-headers for i686-linux if I can properly read the definition of (%boot-mesboot6-inputs)

<jpoiret>thanks :)

<janneke>jpoiret: you may want to have a peek at a guix 1.0 branch, the bootstrap is much more uniform and simpler there

<jpoiret>janneke: oh, if I read this correctly, the kernel headers are copied into the bootstrap glibc

<jpoiret>well, glibc-mesboot I mean

<jpoiret>so, yeah, I guess I'll have to add the hurd headers somewhere

<jpoiret>I wonder where they disappeared in this story, because native compilation used to work before

<janneke>jpoiret: ah, that could be

<jpoiret>seems that glibc including some (but not all) hurd headers is kind of weird

<janneke>jpoiret: did you send/push your hurd fixes/recipe somewhere already?

<jpoiret>they should not be including any headers under hurd/ I believe, since hurd-headers should contain the exact same. eh

<jpoiret>janneke: no, not yet, I also wanted to get the native compilation working as well. But I guess I can start with that now

<jpoiret>I would also like to switch to netdde instead of the in-kernel linux driver

<jpoiret>it seems that Debian has been doing that for a long time now

<janneke>jpoiret: there's kernel-headers-boot0

<jpoiret>right, but it looks like all of the boot0 tools need the kernel-headers

<jpoiret>so I don't think we have a choice apart from adding them to the bootstrap (as it was before I think)

<janneke>jpoiret: guess they come in via %bootstrap-glibc

<janneke>as part of https://ftp.gnu.org/gnu/guix/bootstrap/i586-gnu/20200326/glibc-stripped-2.31-i586-pc-gnu.tar.xz

<janneke>come in or should come in

<jpoiret>but hurd/hurd_types.h is missing from there

<jpoiret>so I was wondering how it was working before, and I was thinking that the hurd headers were also added to the bootstrap at some point. Or just that the problem never manifested because coreutils was not in boot0 at the time (right?)

<jpoiret>it's just coreutils that's failing to build

<janneke>hmm

<janneke>jpoiret: in version-1.1.0, there was no coreutils-boot0, only coreutils-final

<jpoiret>was it added earlier than the recent core-updates cycle? because if so, my hunch would be wrong

<janneke>i believe earlier, but i'm not sure when native builds broke

<janneke>the hurd blog post was april 2020

<janneke>ah, but native builds broke only after recent core-updates merge...hmm

<janneke>ah, but it might not have been used on i586-pc-gnu initially, the *dependency* on coreutils-boot0 might be newer

<janneke>jpoiret: yeah, that dependency was created last October

<janneke>56759d30d9a817a9c9221c9468a4c4a59c9a4713

<janneke>gnu: Switch to GCC 11.

<janneke>afaics

<jpoiret>oh! That's probably why then

<jpoiret>can't we use the bootstrap coreutils for that?

<janneke>possibly, but not on x86-linux; they don't exist there anymore

<janneke>and i'm not sure if/how we can specialise for build target in origin

<jpoiret>you can't unfortunately

<jpoiret>unless you make the whole package a procedure

<janneke>yeah, so this is a problem

<janneke>wait, can't we use delete-file-recursively instead?

<jpoiret>to delete what?

<jpoiret>we do need the hurd headers in there. I'll just add a bootstrap input with the headers.

<janneke>that was wrt the commit i referenced that introduced the coreutils-boot0 dependency in snippet:

<janneke> ;; XXX: The GCC test suite contains files with non-ASCII file

<janneke> ;; names, which cannot be repacked by BOOTSTRAP-ORIGIN. Nor

<janneke> ;; can it be deleted from Guile, so resort to this evil hack.

<janneke> #$(origin-snippet (package-source gcc))

<janneke> (system* #$(file-append coreutils-boot0 "/bin/rm") "-rf"

<janneke> "gcc/testsuite/go.test/test/fixedbugs/issue27836.dir"))))))

<jpoiret>ahhhh, yes, that could probably be done with pure guile

<jpoiret>but it's too late now, that would cause a world rebuild for all archs

<janneke>but yeah, world rebuild

<janneke>well, we'd need to start a wip-hurd branch then

<janneke>(or team-hurd, dunno the current meme)

<jpoiret>well, for hurd, I think the fix for now is to conditionally add some bootstrap hurd headers

<jpoiret>but removing the above would be quite nice as well

<janneke>yeah

<janneke>smart

<janneke>with a notice this can be reverted after the proper fix is merged

<jpoiret>yes. Although I wonder how you can expect to build programs with a libc without using kernel headers

<janneke>jpoiret: well, coreutils has

<janneke>#elif defined __GNU__

<janneke># include <hurd/hurd_types.h>

<janneke>#endif

<janneke>and i expect most other tools don't so such things

<jpoiret>ah, you might be right

<jpoiret>then, i'll only add it as an input to coreutils

<janneke>nice

<jpoiret>currently using `guix time-machine` to generate a bootstrap tarball for the headers

<jpoiret>if it just Simply Works™, then i'll be impressed by Guix once again

<janneke>yeah, why do people keep holding on to legacy package management?

<janneke>jpoiret: booting now works for me too

<jpoiret>oh damn, I forgot there was a time bomb in openssl

<janneke>crap, bunch of bunglers...

<janneke>of course, /me is also a master bungler ;)

<janneke>jpoiret: weirdly, i tried a very similar patch to your fix yesterday after your hint here on irc https://paste.debian.net/1280203/

<jpoiret>I wonder if I can get away with just adding hurd/hurd_types.h and nothing else :)

<janneke>hehe

<janneke>and it doesn't boot (just re-checked); still hanging on pager

<janneke>of course, i also reverted to guile-3.0.7

<janneke>16:28:42 janneke@drakenpad:~/src/guix/master [env]

<janneke>$ gl wip-hurd6 | head -3

<janneke>791af71297 hurd: swap translator setup/hurd symlink

<janneke>27906c33e2 WIP hurd: Revert to guile-3.0.7.

<janneke>ff2e22d1e1 gnu: system: Cater for Guix Home in PATH.

<janneke>...

<jpoiret>huh, that's weird

<janneke>so, great fix but .. dunno?

<janneke>yeah!

<jpoiret>maybe guile-3.0.9 is needed for that? We'll never kno

<janneke>ACTION checked jpoiret's fix twice, and it works

<janneke>possibly...

<jpoiret>we had some bugs in system* related to the non-Linux oses, but that was introduced in 3.0.9

<janneke>yeah, that's why i tried all kinds of things reverting to 3.0.7

<janneke>the setting of PATH surely can't make any difference...?

<janneke>oh well...

<janneke>civudul might like to see this :)

<jpoiret>i'll set up my hurd as an offload and then try to get native compilation working

<Grimpper>Quick question for some one that knows how to use the Shepherd. I'm creating this actions on a custom service and I would like to restart the service after each of the actions. Is there a way to do that?

<Grimpper>The service in question: paste.debian.net/1280205

<muradm>hi quix

<muradm>$(guix build qemu-minimal)/bin/qemu-system-x86_64

<muradm>gives

<muradm>bash: /gnu/store/x4vcmgrdqsn9f6hxjnx4kb7znv047vxp-qemu-minimal-7.2.1-doc: Is a directory

<muradm>same for non minimal as well

<jpoiret>muradm: qemu has multiple outputs and guix build returns them all

<muradm>thus can't figure out why my vm is not starting, because fails to provide output

<jpoiret>there's no good way to choose the right output with `guix build` iirc

<muradm>jpoiret: ah, guix shell qemu-minimal:doc qemu-minimal -- qemu-system-x86_64

<muradm>i see thanks

<janneke>ACTION has been using the clumsy: guix build qemu | grep -Ev '(doc|static)$'

<janneke>$(guix build qemu | grep -Ev '(doc|static)$')/bin/qemu-system-i386

<tex_milan>Hello, I need tflite-runtime, but trying pip3 install tflite-runtime gets me ERROR: Could not find a version that satisfies the requirement tflite-runtime (from versions: none). I had installed it this way with python-3.9, but now with python-3.10 it returns this error. Do you know how to install it? Or how to install python-3.9?

<tex_milan>Ok, I found there is no package for python-3.10. Is it possible to install python 3.9 or python 3.8 or 3.7 on guix?

<tedium>I'm trying to write a package, but when I run "guix package -f ./p4.scm" then try to run the program that package evaluates to, bash says command not found. Where is guix package installing that to, so I can add that to PATH, or change where its installing at to somewhere on PATH?

<tschilp>sneek: botsnack

<sneek>:)

<bumble[m]>I updated my guix system and now qutebrowser does not have sound. There was previously sound through pipewire, but now there is no sound

<bumble[m]>After updating my system qutebrowser no longer has sound. qutebrowser did provide sound through pipewire but no sound anymore

<the_tubular> https://issues.guix.gnu.org/recent

<the_tubular>Doesn't seem to load for me

<tschilp>neither for me

<Mari[m]>how do i get pipewire working?

<Mari[m]>i can't get it to launch, it just gives me rtkit errors

<civodul>cbaines: hi! i noticed this guix-build-coordinator system test failure: https://ci.guix.gnu.org/build/1364534/log/raw

<civodul>i can't see what's going on at first sight

IRC channel logs

2023-05-14.log