IRC channel logs


back to list of logs

<apteryx>sneek: later tell zeropoint I don't think Guix currently tries to detect pre-existing bootloaders
<apteryx>sneek: later tell jpoiret: I think I've finally fixed the cycle with pkgconf-as-pkg-config; there was two reasons for it: 1) hard-coding package pkgconf reference in trivial gexp builder of pkgconf-as-pkg-config and 2) the package-with-explicit-inputs tooling relying on packages using gnu-build-system
<sneek>Will do.
<apteryx>so I had to rewrite pkgconf-as-pkg-config to use the gnu-build-system and I provided pkgconf as an input and used search-input-file
<jpoiret>apteryx: nicely done! so is pkgconf as drop-in as they're telling us?
<sneek>Welcome back jpoiret, you have 1 message!
<sneek>jpoiret, apteryx says: I think I've finally fixed the cycle with pkgconf-as-pkg-config; there was two reasons for it: 1) hard-coding package pkgconf reference in trivial gexp builder of pkgconf-as-pkg-config and 2) the package-with-explicit-inputs tooling relying on packages using gnu-build-system
<natmeo>is there a guile implementation of fsm that I could look at?
<sham1>Finite state machines?
<natmeo>i'm kind of writing a generic one and I want to see how stupid mine is
<acidbong>hi there, hello
<acidbong>is it possible to pin channels in the system config, akin to nix's npins/niv/flakes? there's a guide for `guix describe`, but it's for user-specific operations, not system-wide
<acidbong>(unless i misunderstood it)
<zeropoint>apteryx: hmm, that's less than ideal. I may should try and understand boot loaders better...
<sneek>Welcome back zeropoint, you have 1 message!
<sneek>zeropoint, apteryx says: I don't think Guix currently tries to detect pre-existing bootloaders
<janneke>natmeo: i guess you've seen
<peanuts>"GitHub - artyom-poptsov/guile-smc: GNU Guile State Machine Compiler"
<PotentialUser-71>Hi, is there sha key for image file in the open?
<yelninei>trying to play around with a childhurd. I am getting unauthorized public key errors in guix offload test. I thought the service would authorize the vm automatically
<janneke>yelninei: that's the idea, unless maybe you created /etc/childhurd/ before by hand?
<yelninei>janneke: I did not. i'll reset all files and try again
<janneke>yelninei: ok, weird!
<natmeo>janneke: yeah, that's way overcomplicated for my purposes
<yelninei>janneke: the build-vm-activation script is is definitly run as the files created by it exist (/etc/childhurd/etc/ssh/authorized_keys.d/offloading). If I run the authorize-guest-substitutes-on-host script manually it works. But I have no idea why it is not being executed
<janneke>yelninei: looking at the code, it would only be skipped if the `offloading?' field of the childhurd config is set to #false
<yelninei>i am using the default value of hurd-vm-configuration which is #t though
<yelninei>ill look into it later again
<civodul>build-vm, childhurd…
<civodul>did i break something?
<civodul>at least both system tests pass
<janneke>dunno, my last upgrade was Jan 31 2024 12:35:58 guix 7a45f7b and all works fine (but i hav an auto-config childhurd before)
<civodul>i pushed the virtual-build-machine patch set yesterday
<civodul>it touches childhurd code to reuse it for build-vm
<peanuts>"[PATCH 0/6] Service for "virtual build machines""
<spiderbit>I created recently a package for a rofi extention (file-browser-extended) and thought I might try to contribute it for others, but it's MIT License so I assume guix don't allows that license?
<spiderbit>Or is it sorry no expert on lisences
<yelninei>janneke i think i found the issue: I also have a simple-service to authorise another substitute server via guix extension. Which will then reset the acl to %default-keys + key from other server
<spiderbit>also how do I lookup availible licenses in the license modul
<iK0u>Hi, I am trying to compile grub inside a guix container with fhs. I added "font-gnu-unifont" to the manifest but grub compile still fails saying unifont is needed.
<spiderbit>like do I replace that with mit: (license license:expat)
<iK0u>I checked the grub example in bootloaders.scm, it appears to have been resolved by defining unifont and using it as a build input, is there a difference between that unifont and the package I am using? Also Is it possible to get this to work in guix container with fhs?
<spiderbit>GPL compatible    Yes
<spiderbit>so it should be a valid contribution I think
<janneke>yelninei: good, civodul will like that :)
<civodul>yelninei: are you saying that the problem is “on your side” so to speak? :-)
<yelninei>I thought it was that. But removing the other substitute server still does not authorize the childhurds key.
<yelninei>though i have no idea why it should not work
<spiderbit>So I guess Expat is correct because this package is according to the website MIT
<spiderbit>but here Expat
<peanuts>"electron-cash 4.3.1 ? Packages ? GNU Guix"
<janneke>hmm, /me reconfigures and gets
<janneke>herd: error: exception caught while executing 'start' on service 'hurd-vm':
<janneke>Wrong type (expecting exact integer): "#(2 2130706433 11004)"
<janneke>let's see what happens after a reboot, brb
<iK0u>adding "--development grub" still doesn't make the font available
<janneke>all is well after a reboot, childhurd starts
<yelninei>janneke is your childhurd authorized?
<janneke>yelninei: yes
<janneke>but as i said, i had a childhurd before; didn't test with pristine setup
<civodul>janneke: the wrong-type-arg bit is due to the API change in secret-service.scm
<civodul>i totally overlooked that this could be a problem
<civodul>i guess one can work around it with: herd eval root "(reload-module (resolve-module '(gnu build secret-service)))"
<civodul>(instead of rebooting)
<rekado>on core-updates hurd-minimal-boot0 fails with “glibc-bootstrap-0/include/mach/mach_host.h:978:2: error: unknown type name 'kernel_boot_info_t'”
<rekado>does this sound familiar?
<janneke>civodul: nice
<yelninei>so i pulled just now (didnt even have the new changes before), removing all childhurd stuff and trying again. Will report back
<janneke>ACTION hasn't been working on the native hurd build as offloading (/guix copy) with a core-updates-built hurd-vm doesn't work
<rekado>the type is declared in include/mach/mach_types.defs, but I don’t know what that file is.
<janneke>rekado: maybe ask on #hurd
<janneke>it sounds vagely similar to my fix in gnumach-fix-i686-linux-build.patch
<sham1>How can I make the guile errors from guix more verbose. For example, I'm trying to use a variable I've exported from a custom module I have in my dotfiles (having of course set the load path properly with -L), and it still says "Unbound variable"
<janneke>but i guess that's a totally other use case, and another package too
<apteryx>jpoiret: I'll let you know soon after I've rebuilt a part of the world
<sham1>Welp, turns out that the module wasn't being compiled properly since there was an error.
<rekado>I wonder if maybe we need a more recent bootstrap glibc for the hurd.
<rekado>ACTION builds a recent glibc on master for i586-gnu to see if the generated mach headers differ
<apteryx>this-package-input is fraught with danger it seems
<janneke>ACTION looks into upgrading hurd(-headers) to v0.9.git20231217
<apteryx>civodul: fibers 0 is using 93.9g RSS on node 129 o.O
<apteryx>seems to be a child of shepherd itself
<apteryx>oh no, apologies, this is nar-herder
<apteryx>cbaines: ^
<apteryx>process 62775
<apteryx>I've added details to #66997
<peanuts>"nar-herder uses 10 GiB of resident memory, 100% CPU on hydra-guix-129"
<iK0u>This is where grub is looking for the unifont " for dir in . /usr/src /usr/share/fonts/X11/misc /usr/share/fonts/unifont /usr/share/fonts/uni /usr/share/fonts/truetype/unifont /usr/share/fonts/misc /usr/pkg/share/fonts/X11/misc /usr/local/share/fonts/gnu-unifont /usr/local/share/fonts/unifont; do"
<iK0u>Inside the container I confirmed that /usr/share/fonts/truetype/unifont exists, however it is not seeing it?
<iK0u>Could it be that the builder does not follow symlinks?
<iK0u>I am considering giving it the absolute path in the store but this seems wrong
<apteryx>rekado, efraim: ci rss feed mentions a few r broken packages, as well as vim ones. I haven't looked into them. May be just our must annoying CI bug.
<apteryx>most annoying*
<panosalevro>hi #guix, i need to use latest gnome but the glib package is quite old. is there anything i can do to help move it forward?
<apteryx>did you test the gnome-team branch?
<yelninei>i have no idea why it is not authorising the childhurd. With some print debugging the authorize-guest-substitutes-on-host file is being executed on reconfigure. And manually executing it does the right thing
<panosalevro>apteryx: i tried, but i ran into some error with another channel so it didn't work. is there any chance it's going to be merged soon?
<civodul>yelninei: so “guix offload test” fails for you?
<yelninei>civodul: yes with missing key error. checking /etc/guix/acl it is not being updated even though the script that should add the key is
<panosalevro>apteryx: we want to make this package work:
<peanuts>"zrythm/packages/zrythm.scm ? main ? Zrythm / Zrythm Guix channel ? GitLab"
<yelninei>running the script from the store with sudo ...-authorize-guest-substitutes-on-host /etc/childhurd/etc/guix works.
<yelninei>civodul: I've found something. The 'correct' acl is in acl.bak and the etc/guix/acl only has %default-substitute-keys. So i am guessing that the activation script is run before the acl-file is getting instanted which will overwrite the changes
<rekado>apteryx: thanks, I’ll take a look at the R packages later tonight
<rekado>“cannot build missing derivation” :-/
<rekado>I’m beginning to feel mildly inconvenienced by this phenomenon.
<yelninei>Somehow the order of the services inside my operating-system matters.
<yelninei>(append (list (service hurd-vm-service-type)) %desktop-services) works but not the other way around.
<iK0u>Putting the absolute store path solved the grub build, it definitely doesn't like symlinks..
<iK0u>Is it possible to make guix containers work more like the package builds with inputs and stuff? I find it quite hard to build things in a container sometimes
<janneke>hmm latest hurd release/tag needs an unrleased gnumach, so dunno
<iK0u>It would be very nice if a guix container could work as well as a chroot of a mainstream distribution, maybe some kind of template that emulates them
<apteryx>rekado: same. I should dedicate another debugging session
<apteryx>panosalevro: I haven't followed to closely, but there were few remaining packages to upgrade last I checked, so barring any serious issue found, I'd say yes!
<apteryx>rekado: building stuff from hydra-guix-129 I regularly see: substitute: could not fetch 504; I wonder if this could be related
<apteryx>(among other .narinfo returning 504)
<panosalevro>apteryx: glad to hear!
<rekado>apteryx: that’s served by guix publish, isn’t it?
<rekado>where do the tarballs for %bootstrap-glibc come from?
<rekado>for the i586-pc-gnu case they clearly must have been cross-built
<rekado>I’m trying ./pre-inst-env guix build --target=i586-pc-gnu -e '((@@ (gnu packages make-bootstrap) %glibc-bootstrap-tarball))'
<ieure>Hmmm, so, I want to stick Guix in a Docker image and use it as a build/cuirass/substitute server. I wrote up a plausible (operating-sysstem ) and ran `guix system docker-image builder.scm', but it complains that I'm missing boot-loader and file-system configs. Neither of those are relevant for Docker images.
<rekado>ieure: just fill them with some default; they don’t matter
<ieure>Are those things required by operating-system, but ignored by `guix system docker-image'?
<ieure>rekado, I sure don't love it, but alright.
<rekado>we have containerized-operating-system in system/linux-container.scm, but AFAIK it doesn’t fill the bootloader slot either.
<rekado>virtualized-operating-system from system/vm.scm does, though
<rekado>I’m trying to cross-build glibc for i586-pc-gnu on core-updates (after porting a patch to glibc 2.38), but glibc-cross-i586-pc-gnu fails because it can’t find the cross binutils for i586-pc-gnu. I wonder if cross-building glibc is currently broken on core-updates.
<rekado>ACTION adds a special case for glibc 2.38
<rekado>this works for me: (if (string=? "2.38" (package-version libc)) (string-append "/bin/" target "-objdump") (string-append target "/bin/objdump"))
<rekado>the objdump name differs
<civodul>wait, are we still carrying two libcs on core-updates?
<civodul>i thought we had (define-public glibc/hurd glibc)
<janneke>no, we have one libc
<janneke>but i've also been building hurd-vm's for a while now on core-updates
<janneke>rekado: what's the glibc patch for?
<janneke>ACTION has been having problems with hurd-vm's built on core-updates, in that offloading and guix copy don't work
<janneke>also, as i understand it, jpoiret is working on glibc-2.39 (and gnome?)
<rekado>the reason why I’m donig any of this is because “./pre-inst-env guix build --system=i586-gnu hurd” fails for me on core-updates
<rekado>it fails pretty early
<rekado>the failure in /gnu/store/ki20acqmbhzgkc23q880zryz1wk46vix-hurd-minimal-boot0-0.9.git20230520.drv suggests that the bootstrap glibc is too old. Its mach_types.h does not contain a definition of kernel_boot_info_t.
<rekado>so now I’m trying to cross-build a new bootstrap glibc for i586-pc-gnu
<rekado>i.e. building glibc 2.38 as the bootstrap glibc for hurd
<janneke>ah right, that's great
<rekado>that fails because glibc-bootstrap-system.patch doesn’t apply to glibc 2.38
<rekado>so I created a variant for glibc 2.38
<janneke>there's a glibc-cross-i586-pc-gnu there too, of course -- figured you were cross building for a vm
<rekado>the next problem is the cross build of glibc itself, which fails to find the cross objdump
<rekado>and that’s fixed with the above special case to use i586-pc-gnu-objdump instead of i586-pc-gnu/bin/objdump, which would have worked for older glibcs
<janneke>i hadn't expected so much work for the native build too...
<rekado>I just finished builiding gcc-cross-i586-pc-gnu-11.4.0
<rekado>now on to bash-static – and hopefully eventually a new glibc bootstrap tarball
<rekado>ACTION lets the machine do its thing now
<janneke>ACTION just built a new vm with hurd v0.9.git20231217 and gnumach master
<janneke>let's see if that makes any difference for offloading / guix copy
<sham1>So, for what is probably a slightly easier conundrum, I'm trying to modularise my home configuration, and in particular, I'm starting to move some of my previous dot-files onto being managed by Guix home. The thing that I'm wondering about is that on some of my machines I want to be able to choose alacritty as my terminal emulator, while on some of my less powerful systems I like to use rxvt-unicode. Is there some nice way where I could have the
<sham1>dotfiles refer to the correct terminal emulator depending on the home configuration, preferably without some odd substitute* -magic, since I haven't really gotten a hang of that yet
<erikeah>Hi, anyone here for newbie assistance?
<sham1>What's the question?
<erikeah>I'm trying to maintain a base-operating-system, which holds inside a module. Then this module will be imported to be used to inherit the specific-operating-system
<sham1>Well, that's certainly possible
<erikeah>My main problem is that I get my variable unbound (I'm using the -L flag on guix, obviusly)
<erikeah>Then I created a (define message "hello wrld") and is caught...
<sham1>I'd try to `guix repl` with the -L -flag set as appropriate, and then try to (use-module (module name here)) your base module
<erikeah>I think I'm pretty new on scheme
<sham1>That usually at least gives you a hint why the module doesn't get properly compiled by guile
<erikeah>use-module: unbound variable? Excuse my stupidity
<sham1>No no, excuse mine. It's supposed to be use-modules
<sham1>It's annoyingly a plural when used as a stand-alone declaration while in define-module, the keyword argument is singular
<erikeah>Annoying yep, still I'm finding scheme to be very based.
<erikeah>I think I got a hint!
<erikeah>operating-system: missing field initializers (file-systems) in form
<sham1>Yeah, (file-systems) requires at least one. Just add a dummy there
<sham1>You'd have to fill it with something interesting per-machine anyway
<erikeah>maybe something trying to mount /dev/null?
<sham1>Maybe, or tmpfs. It literally doesn't matter, it just needs something
<erikeah>It compiles!
<erikeah>sham1 you are in my heart from this time to the end!
<erikeah>sham1 are you core to guix or just hanging around?
<sham1>I'm a casual user
<erikeah>That say a lot about the community on here...
<erikeah>Thanks a lot for your assistance!
<sham1>I've actually been meaning to refactor my system configurations in a similar way as to how you seem to have done it. I just need to actually get it done. I've been mostly focusing on the guix home configuration instead
<erikeah>Guix is amazing...
<erikeah>Me too, I have spent most of the time on home, at this moment is still WIP, mainly because I need a patch to be applied on guix to use river as my WM
<erikeah>But buyed a laptop and I wanted to go PRO with my system files
<erikeah>Did you uploaded dotfiles anywhere, I would like to inspire from yours :)
<peanuts>"~sham1/guix-config -
<sham1>It's still a tad messy, but it works just fine. I also have a separate config at work, but that's of course not published in the repo
<sham1>It uses the repo stuff, but it's not in the repo as such
<erikeah>I like most the thing I see
<erikeah>What would be greeat for guix is the ability to choose the desktop environment from guix home
<erikeah>Do you know anyaway to approach this?
<sham1>I mean, you *can*, for example with the "xinitrc-xsession" package which just lets you use the xinitrc file as your "session"
<mange>The SSL certificate for expired eight minutes ago.
<sham1>That package would go to the system configuration. And then in the home configuration, you can output an appropriate xinitrc file
<erikeah>Yeah, that will definetely work