IRC channel logs
2024-05-06.log
back to list of logs
<Tadhgmister>oh boy, can confirm there is a bug in glibc-headers-mesboot that stops it from being able to be cross compiled, I think everything else in commencement is correct in terms of input references but I'll probably be building packages for days before I know if that is the only thing stopping me from compiling my system image the way it is intended <KE0VVT>efraim: Ready to test more things to get audio working. <atka>does guix work with just /boot /gnu and tmpfs root these days? <atka>yes, but has anything happened in ~2 years <rekado>I'm sorry, I still can't build Guix. I still run into this error: "Error: Could not set character size" <rekado>this means I can't build doc/images/service-graph.png <rekado>I'm using the latest Guix from today, ran "make distclean", ./bootstrap, ./configure --..., and make -j <rekado>to unblock my work I do "touch doc/images/service-graph.png" and compile the rest of Guix, but I think there might be something wrong <rekado>ACTION replaces the python-team branch with a rebased variant <jpoiret>civodul: any suggestion for how we could package the new commits on the 2.39 release branch of glibc? <jpoiret>just squash all commits into one patch and use that? <jpoiret>ah, we don't build glibc-final with autotools so any changes to the build system won't apply đ <jpoiret>although we do have them available đ¤ <civodul>jpoiret: one or several patches, yes, preferably with âCVE-XXXâ in their name so âguix lintâ recognizes them <civodul>but maybe letâs push the âcleaned upâ branch first, so we can build consensus around it? <jpoiret>there are quite a lot of commits on the branch now <jpoiret>sure, just wanted to avoid people trying to build stuff before a new world rebuild because of glibc <peanuts>"oss-security - The GNU C Library security advisories update for 2024-04-17: <civodul>thatâs a single CVE (so a single patch) <jpoiret>there's also CVE-2024-33599 to CVE-2024-33602 <civodul>sarg: thanks! one of the committers will take a look âhopefully soonâ <civodul>if not, feel free to ping people here after some time has passed <jpoiret>and there are a lot of fixes that seem important <civodul>thatâs always the case with software :-) <civodul>i think we should limit ourselves to fixing vulnerabilities <civodul>upstream tags releases, we should use them <jpoiret>I'm not saying we should update it as often as they do but when we can we probably should. Some performance regressions get fixed on 2.39 for example, I don't think we should ignore that. <jpoiret>I'll push the cleaned-up branch this afternoon, without the pkgconf series <festerdam>How would I make a package definition for a package for some language/framework that does not have a "global scope" for packages? Like, what if a python script could only import modules that are in the same directory as the script? (Python obviously works with system modules, but we are just having this thought experiment where it can only import local modules, for the sake of giving an example) The <festerdam>language/frameworkd which I want to make package definitions for, is only able to load addons if they are stored in the addons directories of each project using it. When installing such a package the thing I think Guix would need to do, is build the package, put it in the gnu store and create a symlink in the addons directory of the cwd or given path that points to that addon in the store. Does Guix <festerdam>support installing a package to multiple user-provided locations or would the user need to manually make the symlinks whereever needed? <festerdam>(more specifically I'm trying to make package definitions for Godot addons) <festerdam>(Godot installs addons on a poject-by-project basis, rather than to some global scope) <rekado>festerdam: perhaps you could patch the host package to respect a search path? <festerdam>rekado: You mean I should send such a patch to the official repository? I think they already had a discussion on implementing such a feature, but it seems the consensus is that they will not implement a global search path for addons that may be project dependencies (which is what I'm interested in) and that such addons should be part of the project, because they don't want to break projects by people <festerdam>I think something I could do is simply write a wrapper around Guix, that installs the package, but also creates the symlink where needed. But I'm wondering if Guix already has some built-in features for use-cases like this. <graywolf>Interesting, when I do guix system init, *what* versin of system is installed? From my current channels? Or some special "pinned" version (1.4.0?)? <civodul>graywolf: it uses the very âguixâ command youâre using; however, what ends up in /run/current-system/profile/bin/guix is the âguixâ package (which is older) <civodul>likewise for the guix-daemon service <graywolf>I see... Hm, right, so if I want to have a single system definition for both the init and reconfigure, I need to add nss-certs conditionally on whether they are alredy present in %base-packages <graywolf>Because without nss-certs, guix pull fails for me after init, but with them, reconfigure complains about multiple nss-certs being present <jakef>are there any python-team members about? <PotentialUser-86>Hello GUIX. I ordered a FIDO2-Key recently. Is it possible to use it under GUIX? <jonsger>PotentialUser-86: depends. I'm using a Nitrokey 3A NFC key, which works on Guix System. It only requires an udev rule... <mgd>has anyone had luck running Guix on a T480? it's chugging along fine on my X220 but very slow, even with substitutes setup <taeltydes>suprisingly there is mention here of nesting user-account under users here, yet now in the user-accounts docs. <taeltydes>I haven't installed on my t480s yet, but I'm pretty sure the wifi firmware is non-free. you'll probably want to ask over at non-guix. <mgd>I'm happy with doing that, I'm just wondering if I'll see better performance when running Guix compared to an i7 X220 <taeltydes>or you could look into upgrading the wifi card. <PotentialUser-86>I have a really bad connection. But Thank you for the pointer to the cookbook. I was not aware of it. <taeltydes>@mgd i thought the substitutes bottleneck was my terrible home wifi, so installed on a gigabit vps at vpsfree.cz. i think the savannah servers are on the slower side. <mgd>taeltydes: that's interesting. I always thought it was my laptop <taeltydes>im going to schedule nightly pulls in a container or something & use it like a cache with guix publish. <mgd>taeltydes: so it's a feature, not a bug :) <civodul>itâs preventing several things from happening (hpc.guix.info/browse canât get package info, i canât upgrade the aarch64 build machines, etc.) <taeltydes>any chance anyone has any links to docs / configs for understanding integrating system containers with pinning? the cookbook docs seem to be a bit limited here. what i'm really hoping to achieve is service isolation. <taeltydes>i understand I can make use of inferiors &or time-machine, but I can't seem to find many examples of integrating containers in a declarative way. <civodul>ieure: hi! it depends on how youâre running âguix publishâ on that machine <civodul>if youâre running it with â--cacheâ, then it will first âcookâ (compress etc.) the thing you need before it returns 200 <ieure>civodul, I do have `guix publish' running on it, but my understanding is that Cuirass has its own substitute server -- is that wrong? <ieure>civodul, Also not clear to me how cache or not would affect whether the substitutes are available -- are you saying that the cache takes so long the weather command times out and it's erroneously considered unavailable? <civodul>ieure: itâs not that it takes too long, itâs that âguix publishâ returns 404 while itâs âbakingâ the archive, and only after does it return 200 <civodul>also, âcuirass remote-serverâ runs a âguix publishâ server, but itâs for use by âcuirass remote-workerâ instances <ieure>Hmm. I don't have any remote workers, just building on the one machine. When Cuirass builds something, it doesn't show up in `guix publish' -- only if I manually build on the system, instead of in Cuirass. <eikcaz>Alright, It's been over a year since a patch was submitted to update Synapse (matrix homeserver). In total, 3 working patch sets have been sent over this time. However, a fresh guix pull still shows an old/broken Synapse version. What is the bottleneck here? Does Guix just need more reviewers? <ieure>eikcaz, In a nutshell, yes. Patches don't get automatically merged, they get manually reviewed and applied. <wakyct>there is a weekly(?) patch review session to help new reviewers on board <wakyct>but I think that is independent of merging? <trnry>Could you elaborate on that session a little bit? If more reviewers are needed, I'd be interested in helping out <wakyct>there is a page on the wiki, one sec <rekado>ci.guix.gnu.org is *far* behind with substitutes. <rekado>it's not good that it took us more than 5 hours to recognize this <rekado>committers really need to at least build the package locally. This would have shown that 3800 packages would have to be built first. <ngz>rekado: I don't re-build already reviewed packages. <rekado>hmm. Did this one show up as built successfully by bordeaux? <rekado>ACTION cancels the pending master builds <rekado>ngz: perhaps bordeaux could show us how many packages had to be rebuilt? I realize that it's probably not a good idea to demand of reviewers to rebuild every patch, so if we can find a systemic solution I think we'd all be happier. <rekado>(personally, I do build almost all patches before pushing them, but I also mostly review fairly small-scale stuff.) <ngz>I think it does. I stopped at the green light without checking numbers in the tables, mainly because the package is "Middleware to access a smart card using PC/SC", i.e., I didn't expect it to be a backbone package. <rekado>so, what do we do about these two upgrades? New branch or the reworked core-updates-new? <ngz>I still don't get how core-updates is handled these days. But core-updates-new sounds like an appropriate place. <rekado>there were recent emails, though, that explain the current state and plans <graywolf>Today I learned that I can use extra-special-file with a string, and it just symlinks to the string. Not sure if that knowledge is useful. <graywolf>On OpenBSD I guess I could use it to manage /etc/malloc.conf :D <Tadhgmister>is there a way to do `--without-tests` when calling `guix system image`? <Tadhgmister>libaio has a test that is failing for me but it exists on the substitute servers so I assume that test isn't critical <cmiller>Could someone explain why it is required to enter 2 times the password for decrypting the HDD? Isn't LUKS basically an encrypted container which contains the actual OS? <Tadhgmister>because the linux kernel and init-ram-fs are stored in the guix store in the encrypted partition so grub needs to decrypt so it can load the kernel, it doesn't pass those secrets to linux and then linux tries to decrypt the drive again <nikolar>I think it's possible for grub to pass on the secret but I'm not sure of specifics <apteryx>yay, got falcosecurity-libs to build cleanly, with its test suite <jpoiret>nikolar, cmiller: usually, the idea is to pass an additional initrd that contains the private key <nikolar>Ah yeah I'm doing something similar for my use case <nikolar>But it's not a basic luks+grub setup so I thought there was a different way <rekado>curiously, there has been no new evaluation of the master branch <Tadhgmister>makes sense it'd be the same, linux needs a key file and the only place it could get it from is the initrd <Tadhgmister>so grub wouldn't actually be passing any secrets in that case <Tadhgmister>nikolar: do you have a setup with an encryption key that gets put in the initrd? I'd love to learn how to do that and have been wanting a way to meaningfully contribute to the documentation <nikolar>Oh no, I'm not running guix as my distro heh <mccd>Hey, with my recent guix pull, I can no longer reconfigure my home config <mccd>gnome-online-accounts-3.48.1, thunar-4.18.10, webkitgtk-for-gtk3-2.42.5 fail <mccd>I'm a bit surprised also that my system isn't using any substitutes for these <mccd>seems to be building from scratch <mccd>any clue how to best deal with dependency build failures? <cmiller>nikolar, jpoiret, Tadhgmister: Ah makes sense. Kinda new to encrypting the drive and testing things out how that would work. I also don't know how I would prepare the drive to work with encryption. In the past I simply used parted and created the partitions. <cmiller>mccd: Sometimes the CI has not catched up and if you guix pull and someone has pushed commits a coupe of minutes ago, there will be no substitutes and things are going to be build locally. Though I can't help with the broken packages, don't know why that is. <mccd>cmiller: It's the builds failing when being built manually so probably having the substitutes should solve it. <mccd>I'll try to guix pull and see if they're in place <Tadhgmister>mccd: do check `guix pull --news` usually it is nothing but sometimes you will notice something like `deprecated package Y finally removed, use X instead` <Tadhgmister>if there is an update to gnome stuff that has happened since last time you pulled it may affect you <rekado>mccd: there was a commit that caused lots of rebuilds <rekado>if you're on a version of Guix before the revert (but after the bad commit has been introduced) you'll end up building almost everything from source. <Tadhgmister>I think I found the spot to do keyfile decryption, the function `open-luks-device` in `gnu/system/mapped-devices.scm` has a `#:key` which is not being called from the `device-mapping-command` in `linux-initrd.scm` <Tadhgmister>I'm not sure how to write the code to still be readable in the general case but I would imagine if you just pass a file like object with the key there the magic of gexps would put it in the initrd for you <Tadhgmister>it would however mean your key file gets copied to the guix store although I guess since this whole problems begins with having the initrd encrypted in the guix store so maybe that isn't the worst thing? <jpoiret>Tadhgmister: I think some code was merged to that effect though. You should try searching on issues.guix.gnu.org <graywolf>Tadhgmister: notice that the example linked above uses luks-device-mapping-with-options <Tadhgmister>oh.... wow I'm silly. I just saw you link to the whole section I didn't scroll far enough to see the example <PotentialUser-53>Pretty new to guix still. Today I didn't pay attention to my battery life. When my laptop died, I charged and now get the following error: unsupported manifest format. I recently also swiched to another profile. What does the error mean exactly? <Tadhgmister>PotentialUser-53: what command is throwing that error? <cmiller>PotentialUser-53: there is a file in ~/.guix-home called manifest which is probably now empty (0 bytes). This can be fixed by switch the generation "guix package roll-back" <cmiller>guix system reconfigure <system.scm> works without sudo? <cmiller>PotentialUser-53: guix package --roll-back is the correct command <cmiller>PotentialUser-53: do you may use BTRFS as filesystem? <cmiller>PotentialUser-53: fileSYSTEM not fileFORMAT, but I assume this means you are not using it. I had the exact same issue as you (power went off in my house) and the profile was broken. <efraim>Kolev: I'm still on vacation until next week <efraim>no worries. I've been enjoying the time off and some low-key fixing broken packages on aarch64 <Tadhgmister>ok so if you select to encrypt your root partition in the graphical installer you end up having to type your password twice on boot, and the way to fix this is documented as an example in the `extra-initrd` option of the bootloader config. <Tadhgmister>a full tutorial to fix that would be to generate the keyfile and set it as a unlocking mechanism for the partition, then all the stuff already in the example, maybe with added note that the original .bin file can be deleted as the path specified to `#:key-file` is relative to the initrd filesystem <ieure>Oh, there's a fix? lol. I've just been typing it twice, like a chump. <Tadhgmister>same, I actually tried to get it based on a friends recommendation but didn't understand the `cpio` part - and wouldn't have - until just recently when I've been trying to setup guix on my turris omnia router <taeltydes>i've noticed there's a bunch of mobile/sxmo things packaged for guix. anyone here running on mobile? <Tadhgmister>I know my friend tried with a pinephone, I think it worked reasonably with a keyboard attachment but they ended up switching to a variant of alpine to use it more like a phone than a portable terminal <taeltydes>i'm using sxmo at the moment with postmarket, but updating seems to be a bit of a gamble. will the modem stop working or the audio. all fun & games. <taeltydes>i have nixos-mobile on the pinephone. the boot generations are ideal but it's a bit on the slow side. will get around to flashing to nixos on the op6 sometime this week & use guix for home. <taeltydes>I guess it's not really compatible with all the proprietry blobs to prop the whole thing up. matter of time for sure. <taeltydes>in all honesty, I would like to build a risk-v blackberry like device, ala beepy, but something that could be used as a daily. <lispmacs[work]>hi, when I use the latest libre-linux kernel, version 6.8.8., on my ol' OptiPlex 9020, I get an error about CPU0 being hung and I can't finish the boot up. I'm running okay now from 5.15.157, but I suppose I should sumbit a bug report to the linux kernel project. But I'm not sure really even where to start as far as getting information on what happened, to share with the bug report. How do kernel programmers/maintai <cmiller>I don't think that Linux will be any help since it is Linux Lire and not plain Linux. <lispmacs[work]>I suppose I could report it to Guix but seems like the sort of thing they aren't going to want to deal with... just an upstream problem