IRC channel logs
2024-01-08.log
back to list of logs
<fnat>I asked this before, but just double-checking my understanding, in a Guix checkout the keyring branch can be updated (git pulled) with no need for verification, right? Then one can go back to the primary branch and check that with `guix git authenticate COMMIT KEY'. <fnat>As the keys in the keyring are "pinned" by the fingerprints which are part of the primary branch, in a "bootstrappable" way, i.e. each commit guarantees for the one after it - in some sense <xisop>Greetings. Is it possible to run a command immediately upon entering a guix shell --container? <xisop>Or, I could also settle for sourcing a file in the shell <lh>I am installing fonts with guix home and they seem to be in the store but not in the profile? <lh>there’s no /share/fonts <lh>fonts-dir-file in guix/profiles.scm is a little over my head at this point, but I don’t see how that could happen <lh>nvm, forgot to include the variable with the font packages in my top level home env <podiki>fnat: not sure what you mean; but I think you are describing the basic idea that guix authenticate checks that each commit is signed by a valid key, and keys are in the keyring branch; new keys must be added there with a signed commit from a previously authorized key <ieure>xisop, Does the convention in the manual work? The example given is `guix shell python python-numpy -- python3', which runs python3 inside the shell. I'd assume that works with -C as well; have you tried that? <villageidiot>Hey fellas, is there a service for adding PAM rules or what's the best way to do that? <podiki>packages that have pam rules can be added to your system config I think? i forget the details for that but did it before <podiki>oh i was thinking of polkit rules for the second comment <villageidiot>podiki: Thanks I need to look at the source for pam-limits-service-type. <villageidiot>I am trying to modify the PAM rules for authenticating sudo <podiki>look in gnu/services/base I believe for all the pam service stuff <lh>I am using guix on a foreign distro and fontconfig from guix seems to ignore /etc/fonts, preferring /etc/fonts from within the store path? <hapster>tsmish: If you don't mind, I have some questions regarding this. First off, when you say "having checkout copied into directory", do you mean you cloned the git repo to a local folder, or was this the result of the `guix shell -CD` command you mentioned before? <cnx>hello guix, how would a self-bootstrapped compiler be maintained in long term? <cnx>supposed there's version A that can be built via another compiler, then B from A, etc. until latest version <cnx>would the entire chain be kept forever? <efraim>cnx: pretty much, unless there was a way to shorten the bootstrap chain <sneek>Welcome back efraim, you have 1 message! <sneek>efraim, podiki says: thanks. yeah seems we are a bit stuck and the longer we wait just piles up more builds to catch up on :( maybe i'll merge in master one more time, send a note to guix-devel, and merge mesa-updates <efraim>sneek: later tell podiki Sounds like our best option. we're at least a week away from building rust for aarch64 on berlin for mesa-updates <dcunit3d>Kabouik: i just encountered the same problem, thanks. i think `guix graph -L $muh_load_path --type=reverse-bag | dot ...` will show the problem <dcunit3d>hmmm nvm it doesn't. i've outlined a few go packages in my channel on disk... that's probably it <apoorv569>All this does get added to .zshrc but for some reason some keybinds work other don't <apoorv569>when before using home-zsh-service-type all of them worked <apoorv569>Like `bindkey '^H' backward-kill-word` should delete by work when I do CTRL+Backspace but its not doing that any migalmoreno <apoorv569>oops.. sorry pinged by mistake, my irc client auto completed that.. I meant to say all <dcunit3d>Kabouik: i'm still running into this, but for go-github-com-gorilla-mux. the reverse-bag with -L $loadpath only shows, 3 dependencies (go-maunium-net-go-mautrix, miniflux and trezord). in my present branch for -L $loadpath, i don't reference go-build-system or any go branches at all. <dcunit3d>ah it's happening in an external channel <fnat>podiki: Thanks. For clarity, my question is about whether anything needs to be done after `git checkout keyring && git pull origin keyring' to ensure the authenticity of the commits received, *on that branch*. My understanding is that, no, one can simply go back to master and run the guix git authenticate command from there. <jonsger>does anyone has experience with OVH "Eco Dedicated Server" and running Guix System on them? <mothacehe>efraim: didn't you get a gnupg cross compilation failure when trying to cross-compile fwupd/libsmbios? I sent a patch to get around that one <efraim>I'm not sure I let it run that long. I kept on failing on libsmbios first <mothacehe>strange, I had the gnupg failure before the libsmbios failure <efraim>mothacehe: I'm getting errors during configure with your patch <mothacehe>PotentialUser-32: Morning! Is your Cuirass server configured in remote-server/worker mode? <PotentialUser-32>mothacehe: Good question. I used the default config. Let me check the config. <mothacehe>PotentialUser-32: the default config (not using remote-server/worker and send directly builds to the daemon) is not much tested anymore, i wouldn't be surprised if it was broken <PotentialUser-32>mothacehe: Is there a work around, because I really want to evaluate cuirass as our CI system <mothacehe>we should probably update it so that remote-server/worker method becomes the default <PotentialUser-32>mothacehe: While you are present. I have another question. I have to add the default guix channel first before I can add my own channel, right? <PotentialUser-32>mothacehe: Ok. So then for every new commit in the guix channel it will build something, even if there is no change in my own channel? <mothacehe>you can use your own guix channel that would be a fork of the official one <PotentialUser-32>mothacehe: Can I limit the packages that will be build? I saw a dropdown in the web interface, but I kept it "ALL" for now. I probably only need some core packages and a few others <mothacehe>that way you won't have continuous rebuilds when new commits are added to the official guix channel <mothacehe>yes you can provide a manifest of packages that you want to build <PotentialUser-32>mothacehe: OK. Just wanted to be sure. I wonder what specs (cores and diskspace) are needed for that. At work I probably can arrange better specs but at home for testing, I might run out of disk space quickly. Is there an automatic cleanup from time to time? <PotentialUser-32>mothacehe: I will then try to come up with (mostly shameless copy) a remote config. Thank you again for your help. Great community. <PotentialUser-32>mothacehe: If someone can fix the local build, it would be nice as well ;) <vixus>when hacking on a package already in the guix repository, is this the correct set of steps: "./bootstrap; ./configure --localstatedir=/var; make; ./pre-inst-env guix build -K <pkg>"? <efraim> guix shell -D guix -- sh -c './bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc && make' <efraim>make again as needed, ./pre-inst-env guix to work from the checkout <efraim>you shouldn't need to run bootstrap or configure that often <graywolf>It looks like our curl is fairly limited (no http3, no ldap, no websockets). Is that intentional? <graywolf>Can I just send a patch turning that on or should I make new curl-full package? <efraim>I'd start with curl-full, curl has too many dependencies to just start adding things <graywolf>efraim: --list-dependent -> 8553... I see <jonsger>graywolf: guix refresh --list-dependent curl -> Building the following 8542 packages would ensure 21320 dependent packages are rebuilt <jonsger>so a curl-full or curl-minimal maybe makes sense <graywolf>uff I overlooked it since I needed to scroll few windows up <Kabouik>The IT department thinks my machine has showed suspicious data transfers to tor. The tor package is not installed on my machine. Is there anything else that could be mistakenly be flagged as tor traffic if not looking in details? Can Telegram for instance be flagged as tor? <Kabouik>I would be surprised if some executable binary had ended up on the machine and used tor under a different process name (can't find any tor match with ps), especially in Guix which is not exactly working as the usual Linux machine <futurile>Kabouik: install one of the network monitoring tools on (preferably a different) machine and set it to look for traffic to tor? <futurile>yeah there's a bunch of them - if on your host I would start with nethogs - jnettop/iftop - then beyond that you'll have to research for one that can monitor a specific port <Kabouik>Thank you. I'll ask them which port they found suspicious, and when the transfers occured, before I know I think it'll be hard to investigate anything <graywolf>If I would manage to create circular import between package modules, will it burn loudly or just misbehave in subtle ways? <Altadil>Hi Guix. If there is a new upstream version for one of the packages in a pending patch series, I should I apply it ? Should I send another patch for the update ? Or rather resend the whole series, with the updated package (maybe it’s easier to apply that way) ? <futurile>Altadil: I think you should send the whole series with a re-roll; explaining that one pachage changed <efraim>mothacehe: that one worked for me <mothacehe>good, thanks for testing! Now the goal of Simon's patchset was to prevent the build of libsmbios on non x86_64 systems. An issue seems to be that "supported-system" doesn't care about cross-compilation. guix will happily try to cross-build for aarch64 libsmbios even though supported-systems is set to "x84_64-linux" <mothacehe>we should turn supported-systems into supported-platforms i guess <tjout>I asked this question at the mailing list but got no answer unfortunately. Hope it is ok, to ask here again. <tjout>I am migrating my server over to Guix but there is one problem I can not overcome: Guix right now does not support grabbing a keyfile from removable media upon boot like crypttab does. So I wrote a little Bash script that does dd the keyfile from the free space at the end of a specific thumb drive, run cryptsetup with that file. <tjout>But how do I tell Guix to execute this script before trying to mount the then-mapped devices? <efraim>I was anyway thinking we should change the glibc-dynamic-linker function to take a platform instead of a system <efraim>tjout: you'd have to make running the bash script a dependency of mounting the drives/file-systems <graywolf>tjout: You could probably modify patch in 65002 to do your bidding. <tjout>graywolf: I found that patch but Guix is my first contact to Scheme so I do not even understand half of it - sorry :( <tjout>efraim: That is what I was thinking. Do you have any link to a resource where I can learn about how to do this? <tjout>I tried converting my backup script to Guile but could not even get the imports right. Guess all the years using other languages broke my brain a little <efraim>tjout: I'm not sure. I haven't setup anything like that <podiki>ACTION merges mesa-updates and maybe will stop hovering over cuirass all day <dariqq>hi, is it possible to replace a guix-package and subsequently all packages that depend on that with my own variant? <dariqq>futurile: i think my use-case is a bit more complicated. The pacakge i want to replace is used as input for some of the packages used by the default services. And specifying a --with-input/applying a transform for all of them is a bit ugly <futurile>dariqq: see the manual - you can do this using a manifest and those capabilities - haven't written that post yet - but the 'programming interface' part of the manual does cover it <dariqq>futurile: you mean the package-input-rewriting function? This would work but i'd want to apply this to my whole operating-system declaration instead of every package and then also all packages that the services depend on which is kind of a pain <jonsger>podiki: kudoz for merging mesa-updates. Out-of-curiosity from which version got mesa updated? <podiki>jonsger: latest release actually! 23.3.2. So we're up to date for a few weeks for once :) <sneek>Welcome back podiki, you have 1 message! <sneek>podiki, efraim says: Sounds like our best option. we're at least a week away from building rust for aarch64 on berlin for mesa-updates <efraim>I'll keep berlin building to rust while it's doing whatever else it's building <podiki>jonsger: previously we were at 23.2.1 maybe? Turns out an ill fated release upstream as it was delayed and didn't get updates <podiki>efraim: thanks! I hope the next time I do mesa it isn't also with some x lib that rebuilds the world <efraim>I'm testing out using the bundled curl for the rust bootstrap, since we only use it to build the next stage <podiki>(xorgproto this time if I remember, causing python and then rust and everything else) <podiki>That will help too, with curl frequently needing security updates it seems <jackhill>issues seems to be down for me (gateway timeout) <rekado>was also down for me, so I kicked it <rekado>is it on purpose that our aarch64 default kernel doesn’t have nfsd? <rekado>(is it a common configuration choice to disable nfsd?) <dariqq>anyone got an idea why my guix is insisting on symlinking the acl store file in /usr/local/guix/acl and just copying it to /etc/guix/acl? <graywolf>What should I do regarding this lint error: label 'zstd' does not match package name 'zstd:lib' ? <efraim>rekado: for linux-libre or for linux-libre-arm64-generic? <efraim>dunno, probably upstream never added it. we should probably take the .config from arm64-generic and merge it into linux-libre so that kernel actually works <theesm>rekado: CONFIG_NFSD is currently set to 'm' in all kernel configs, would 'y' be the better default? <vagrantc>the arm64-generic kernel is kind of an ~all-features-enabled enabled kernel, but in general better to just enable things as modules <vagrantc>makes it easier to use, but definitely silly to have drivers loaded for things that could not possibly be running on the same hardware <metsomedog>any tips on how to deal with different CPU arches in package definitions? <rekado>theesm: oh, so I should be able to load the module? It says there is no such module. <theesm>rekado: Yup, it *should* theoretically be build (https://paste.debian.net/1303465/); tried enabling it on my system (well, i'm not on ARM but x86_64, but the config's similar in those regards) and that worked as well <theesm>if i got that right, linux-libre-arm64-generic is essentially the standard linux-libre arm config + the extra option defined in the package; so it should be present as well (as none of the extra-options affect the realms of nfs as far as I can tell) <theesm>(default arm config meaning whatever is defined in gnu/packages/aux-files/linux-libre/*-arm64.conf for the respective kernel versions) <rekado>hmm, /proc/config.gz tells me that “# CONFIG_NFSD is not set” <rekado>gotta check how I got this config <podiki>rekado: just watch if you pull from master, I merged mesa-updates and substitutes are behind on some architectures (maybe bordeaux is doing okay? i'm not sure) <civodul>podiki: 👍 on the ‘mesa-updates’ merge! <ulfvonbelow>anyone tried packaging ruff? It's some python linter in rust that a bunch of packages seem to depend on these days... as is standard fare for python projects, the only documentation on how to build it is 'pip install ruff'. <civodul>ulfvonbelow: i think i naively tried at one point and then gave up when i realized this wasn’t going to be an easy journey <podiki>civodul: thanks! i hope the next time i update mesa and friends i can avoid a complete world rebuild <civodul>but i’ve seen it mentioned a few times recently so maybe there’s hope <civodul>podiki: well, lots of things depend on mesa & co. anyway <ulfvonbelow>how's rust's non-x86 story these days, anyway? Would a workaround / shim in the dependents actually end up being more portable? <civodul>“guix weather rust -s aarch64-linux” is positive <podiki>...well not right now if someone pulls, rust is behind on aarch64 (but should build eventually)