IRC channel logs
2024-02-11.log
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 <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 <roran>jguiiiiiiiiiiiiiiiiiiiiiiiiix <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? <natmeo>i'm kind of writing a generic one and I want to see how stupid mine is <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 <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 <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 <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 <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 <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? <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>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 <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 <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)))" <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'” <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>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 <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. <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? <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 <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 <yelninei>s/%default-substitute-keys/%default-authorized-guiy-keys <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>(among other .narinfo returning 504) <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")) <civodul>wait, are we still carrying two libcs on core-updates? <civodul>i thought we had (define-public glibc/hurd glibc) <janneke>but i've also been building hurd-vm's for a while now on core-updates <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>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 <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? <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 <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>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>sham1 you are in my heart from this time to the end! <erikeah>sham1 are you core to guix or just hanging around? <erikeah>That say a lot about the community on here... <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>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 :) <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>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 issues.guix.gnu.org 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