IRC channel logs


back to list of logs

<attila_lendvai>ACTION will investigate further tomorrow... o/
<kaelyn>hi #guix!
<TheSkylarverncc[>hi kaelyn!
<bjc>does guile have a pretty printer?
<dcunit3d>in the phoronix comments.. this guy doesn't get it: "Have you ever talked to a package maintainer whether they prefer maintaining 2 init scripts for their packages instead of just 1?"
<dcunit3d>shepherd fits in several different niches that systemd doesn't really see anymore. or its user's can't anyways.
<dcunit3d>i assume that you could script the creation of INI file-based artifacts
<dcunit3d>but it just seems different. i never really imagined that i'd want two package managers on a single system, which was likely more natural in the earlier days of linux.
<dcunit3d>it's really not worth trying to explain the merits of originality to people
<dcunit3d>and the more immutability/reproducibility start taking off, the tighter users/admins are going to want their feedback loops to be.
<dcunit3d>i haven't quite gotten the hang of the scheme repl workflow in emacs yet, but clojure projects were very quick to iterate on
<apteryx>do we have an atomic-write procedure in Guix?
<apteryx>that uses a temp file, then mv or something
<TheSkylarverncc[>does mesa no longer package i915 driver?
<Gooberpatrol66>dcunit3d: pretty sure a systemd unit importer could be written
<apteryx>uh? builder for `/gnu/store/dxjhlyx1lnr0pjqs2z4wssjar20fgin0-grub.cfg.drv' failed due to signal 11 (Segmentation fault)
<apteryx>[1754959.048188] traps: guile[30343] general protection fault ip:7ffff7947500 sp:7fffffffe5f0 error:0 in[7ffff7947000+167000]
<apteryx>jpoiret: by the way, you can simply use 'origin/master' (without the trailing '..') with git send-email for the same effect.
<lilyp>apteryx: re atomic write, substitute* is actually built on top of with-atomic-file-replacement
<sneek>Yey! muradm is back :)
<muradm>hi guix
<sneek>muradm, you have 2 messages!
<sneek>muradm, apteryx says: re pam support for cups, sounds good, thansk for troubleshooting it
<sneek>muradm, apteryx says: I've reviewed the suggested change; I think it needs some more work, to allow for regular PAM auth instead of bypassing it (IIUC)
<muradm>sneek: later tell apteryx, suggested change is correctly functional PAM configuration without any kind of cheating.
<sneek>Will do.
<muradm>ACTION back to work 
<efraim>sneek: botsnack
<civodul>Hello Guix!
<gabber>(how) can i rename a bug in debbugs?
<civodul>gabber: hi! you can "retitle" it
<civodul>if you use Emacs, you can do that in debbugs.el by hitting C on the bug
<civodul>otherwise you have to send a message with the right command, but i don't remember what that is
<civodul>ah, this:
<gabber>i am using emacs! though not the regular key-bindings. would you mind checking which function pressing the "C" key actually invokes?
<civodul>yw :-)
<cbaines>bayfront seems to be in a bit of a state this morning
<cbaines>lots of update-guix-... mcron jobs sitting around
<cbaines>and a load of guix substitute --query processes furiously doing I/O
<cbaines>looking at strace, the cache entries they're looking at relate to
<cbaines>that cache directory is 641.3 MiB in size...
<cbaines>I'm going to do some cache cleaning myself
<cbaines>I wonder if all these guix substitute processes are busy cleaning the cache, but aren't really coping with it's size
<cbaines>cache directories deleted, and that seems to have unblocked things :)
<civodul>cbaines: you mean /var/guix/substitute/ ?
<cbaines>in this case, the caching is probably not very useful, since for derivation substitutes from, the overhead of the caching is quite high I think
<civodul>then data.guix could return a shorter TTL for these?
<civodul>in Cache-Control
<civodul>that way the entries will be evicted more quickly
<platoxia>How do I configure guix system to use a stick to the latest 6.1 kernel series?
<cbaines>civodul, I guess that might work, but it seems like a bit of a hack since it's not like these responses are expected to change, especially for
<cbaines>maybe we need more weather appropriate colours on
<cbaines>like yellow for 80%+ and grey rather than red
<jpoiret>platoxia: you can use linux-libre-lts as the kernel
<jpoiret>or just linux-libre-6.1
<civodul>cbaines: do we have 32-bit colors? :-)
<chomwitt>i have gpg-agent running but is not listed by $ sudo herd status. How do i stop it ?
<jpoiret>95% substitute availability for x86_64? that means we have less than 5% of packages failing to build, right?
<civodul>sounds fishy :-)
<civodul>chomwitt: are you using home-gpg-agent-service-type? (on Guix Home)
<cbaines>civodul, I don't really know web stuff, but we have lots of color's at least :) are you suggesting some kind of smooth gradient?
<evilsetg[m]>chomwitt: You could try `gpgconf --kill gpg-agent`
<civodul>cbaines: i'm saying we should be able to find several intermediate colors between "red" and "green" :-)
<civodul>(which is also not great for accessibility)
<chomwitt>civodul, no!. i will add it in my /etc/config.scm
<chomwitt>evilsetg[m], that worked. but i guess i should add the service civodul hinted because my gpg setup is broken
<cbaines>jpoiret, note that outputs (which is what those numbers/percentages are looking at) don't directly map to packages
<janneke>oh, we have 83% for i686 already, but no installer yet?
<cbaines>here's a list of the 1100 missing outputs for a recent revision
<platoxia>jpoiret: thanks I'll give that a try
<cbaines>and here's a list of the 99 outputs that are available from, but not
<evilsetg[m]>chomwitt: Just a headsup, the home-gpg-agent-service-type only defines a shepherd service if you enable ssh support. I was wondering why I had no shepherd gpg service despite adding it to my config a couple days ago.
<chomwitt>evilsetg[m], thanks for the tip! noted . i am working on my gpg setup now
<evilsetg[m]>I ended up modifying the home-gpg-agent-service-type to including a gpg-agent shepherd service anyway ( It's a bit clumsy though.
<chomwitt> home-gpg-agent-service-type is not documented in
<evilsetg[m]>It is in the devel version of the docs
<chomwitt>i see
<jpoiret>is there any nice guile-based shell I can use? I'm getting a bit tired of zsh
<janneke>jpoiret: well, we have Gash, but to qualify as nice it prolly needs some work ;)
<civodul>jpoiret: there's Gash, but i'm not sure if it qualifies as "nice"
<civodul>heh :-)
<jpoiret>I was about to write the same thing :)
<civodul>i mean it *is* nice because it's in Guile
<civodul>but maybe you had other niceties in mind
<jpoiret>autocompletion is a must. I'll probably try eshell, although I don't like emacs being blocking
<civodul>otherwise just use the REPL and be done with it
<civodul>instead of "ls", you just have to type: ,pp (scandir ".")
<janneke>and it could have been *super nice* if samplet hadn't decided to focus near 100% on bootstrapping (for which i'm very grateful)
<civodul>and another 100% on archival, too!
<evilsetg[m]>eshell is kind of what I would like of a lips shell. I do find the shell model of emacs not
<evilsetg[m]>as comfortable
<civodul>ACTION uses shell-mode
<evilsetg[m]>*lisp shell
<jpoiret>seamless buffer-env integration would be a must but I just keep running into issues with it
<jpoiret>I haven't really taken the time to work it out properly for eshell and auctex
<efraim>civodul: is it feasable to swap out bournish for gash?
<jpoiret>civodul: how do you deal with buffers that get too big?
<jpoiret>I was using shell mode for a while but found the speed of an actual terminal to be much faster
<civodul>jpoiret: i resort to xterm if i'm going to have like the build log of gcc scroll by...
<civodul>efraim: it should be possible
<civodul>we should check how it affects initrd size
<efraim>bug#63521, request to merge tex-team into master
<civodul>efraim: neat; could you and maybe cbaines reply?
<civodul>since you may have better insight as to whether now's a good time
<efraim>It Looks Good To Me™
<efraim>I like, but it doesn't have tex-team
<cbaines>there's some information here
<cbaines>substitute availability isn't terrible, but hasn't even started building tex-team yet
<cbaines>there's still a way to go until the build farms have caught up with master as well
<jpoiret>how do I read that page? The substitute availability is high but there are a couple thousand packages that have unknown status
<jpoiret>ah, it's because bordeaux is where all of that is checked, got it
<cbaines>yeah, knows about substitutes, but not the builds
<efraim>ugh, looking through the build log for librsvg, we have 6 copies of rust-env-logger
<efraim>i've been trying to update some of the older crates to decrease the crate explosion while building packages
<jpoiret>how do you all rebase your branches without causing massive rebuilds? I have a separate worktree I rebase in, but I would love to know if there's a simpler alternative
<efraim>I have 4 worktrees atm, master, keyring, rust-team and wip-aarch64-bootstrap
<janneke>ACTION has a worktree per branch and suffers builds
<janneke>iwbn if there was a handy/cheap alternative to: make ...breakage...make clean
<janneke>*make clean-go; make all
<janneke>iow, if only the broken-abi .go's could be identified and removed
<jpoiret>ah, for this it's usually easy to minimize breakage by just grepping for the broken thing in .go files and removing only them
<jpoiret>I've never had to make clean-go using that technique
<jpoiret>maybe the solution is just to never have any branches and just maintain sets of patches? :/
<janneke>ah nice, i gave up trying to do that and do something else for 15min
<jpoiret>my go to is `grep -Rl 'whateverbroke' --include '*.go' . | xargs rm`
<janneke>ACTION has wip-hurd, wip-riscv, wip-bootstrap-gcc4, wip-home, wip-arm-bootstrap, wip-aarch64-bootstrap
<janneke>jpoiret: nice, thank; i'll try that
<janneke>ACTION anticipates to move attention over to
<jpoiret>I'll just create a script that rebases all local branches on top of their upstream in the specific worktree
<civodul>janneke: uh, postponed!
<civodul>kinda weird no? :-)
<janneke>civodul: yeah, cliffhanger!
<civodul>ha ha, hard to believe
<janneke>yes weird, no?
<civodul>never seen that before :-)
<civodul>speaking over there was the GOOPS person themself!
<janneke>wow, more of a hacker than an organiser i guess ;)
<janneke>ACTION casually looks away
<jpoiret>i'm starting to agree with the pushback against the git config option to sign commits by default
<jpoiret>it would make rebases much faster if I didn't have to sign all the time (esp. because I have my key on a smartcard, and I need to interact with it when I want to use it)
<bjc>can't we just do a check in the pre-push hook or something instead?
<jpoiret>this has been the case for a long time now
<jpoiret>that would also help me automatically rebase all my local branches without having to interact with it
<bjc>so why is doing it on commit necessary?
<bjc>i get that it makes life marginally easier for committers, at least some of the time, but for everyone else it's a real pain
<jpoiret>well, if you have an agent and a key already, and you don't need to interact with gpg when you sign, then it seems like an easy thing to enable
<jpoiret>but yeah, I guess we didn't consider all the different setups in which it could be annoying
<jpoiret>also, project-wide client-side hooks to enforce policy is apparently bad practice
<bjc>where'd you read that?
<jpoiret>but server-side is apparently not an option because it's the savannah server and you'd need guix to authenticate on there
<jpoiret>the note at
<bjc>ah, thanks
<bjc>it can still be done similarly to how the current config is installed by copying the hooks in a ‘make’ step
<jpoiret>yes but I would wager it's bad practice for the same reason
<jpoiret>ie. individual users can't add their own hooks
<bjc>it's no worse than the current setup: it relies on make to install the rule, which can be ignored locally
<bjc>ah, i see
<jpoiret>maybe we could instead have a one-time setup that is described in the manual
<jpoiret>the downside being that when best-practices are updated, users might not notice and update their own configuration
<bjc>thinking about this from a slightly different standpoint: i think it's overreach to modify someone's git config from within a project
<bjc>that should be completely under user control. it's not even a little owned by any project
<bjc>it's inappropriate for guix to reach outside its directory to modify files
<jpoiret>right, but there's the incentive to enforce a project policy
<jpoiret>for example the pre-push hook to check that all commits pass `make authenticate`
<jpoiret>it would be a disaster if someone were to push a non-authenticating commit
<bjc>yeah, i get that. i don't know a good solution other than bugging savannah admins
<jpoiret>I'm still trying to find if it's good practice to `git am --signoff` directly, or wait until the very end to sign-off and sign the commit before pushing, after you've tested them
<bjc>it's pretty poor manners for ‘make’ to go messing with stuff in my home directory
<jpoiret>it doesn't though, it's only `git config --local`
<bjc>oh, ok. i missed that detail
<jpoiret>civodul: any reason we use Signed-off-by: when pushing someone else's commit?
<jpoiret>I would be all for Reviewed-by: or Tested-by: but Signed-off-by: doesn't seem exactly appropriate
<efraim>I wonder if there's another git hook that would work for signing the commits
<efraim>jpoiret: I think because that's the default with 'git commit -s'
<jpoiret>efraim: wdym by another git hook?
<efraim>there's also the --trailer flag apparently, which could be use for Helped-by or Sponsored-by
<jpoiret>yes, that's what I was looking at
<jpoiret>but only -s is available for `git am`, and people might be relying on it
<janneke>there is Co-authared-by: ...
<efraim>there's already a pre-push git hook in etc/guix in the repo, perhaps another one would work for making sure to sign stuff
<efraim>I suppose we could have all committers run 'git config --local commit.gpgsign=true' in the repo
<jpoiret>efraim: the current one is good enough for this, it runs make authenticate
<jpoiret>my use-case is that I only want to sign commits once i've tested them and am preparing to push
<jpoiret>because otherwise 1) I don't really want my signature on a commit I haven't approved yet 2) I need to interact with my yubikey to sign commits
<efraim>apparently 'commit.gpgSign' isn't a valid key
<efraim>jpoiret: I see, that's a good point
<jpoiret>so what I would do would be to run a rebase with `--gpg-sign=` and `--signoff`, except it would make sense to me to use something other than signoff, but there's no `--trailer` for rebase
<jpoiret>one nice thing is that `b4` can extract trailers in replies in threads and combine them into the mbox. This means that someone can reply with `Reviewed-by: ...` and that would automatically be added to all patches by b4
<jpoiret>but this requires b4 which only a couple of people are using :)
<efraim>rekado: can ztoolkit use librsvg-for-system?
<rekado>efraim: I just noticed that, too. It probably should.
<rekado>I was going to upgrade zrythm, but its tests segfault :(
<attila_lendvai>if i want to check a change i made to the bluetooth-service, then can i simply `./pre-inst-env guix reconfigure` to test it on my machine? (it's enabling debug log to fix a bt disconnect issue, so a VM is no good)
<jpoiret>attila_lendvai: yes
<jpoiret>but you need to fit sudo in there, most likely with `sudo -E ./pre-inst-env guix system ...`
<ngz>Hello Guix!
<ngz>sneek later ask rekado WDYT about getting rid of (version (number->string %tex-revision)) and use, e.g., "2021.3" everywhere? We could have a global list storing associations between texlive releases and SVN revision numbers. `texlive-origin' would be able to generate the correct URL from the version of the package, allowing for piecewise updates (see, e.g., texlive-bidi).
<sneek>Will do.
<attila_lendvai>jpoiret, thanks! it makes sense. it's just that Guix never ceases to amaze me... :)
<juano>Naruto Uzumaki, Governor Samuel Garcia Sepulveda, Edna Skilton, and her negroidal husband Jean Pierre Manikariza have a hot foursome! Naruto traveled back to the Monterrey area to reunite with Samuel Garcia and see about opening another location of his ramen restaurant in McAllen, Texas!
<apteryx>lilyp: so 'with-atomic-file-replacement' it is, from (guix build utils). Thanks!
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, muradm says: suggested change is correctly functional PAM configuration without any kind of cheating.
<jpoiret>so apparently greetd starts sessions by first reading a combination of /etc/profile and ~/.profile without documenting it
<jpoiret>I was wondering how my profiles were getting activated, but it looks like greetd doesn't care and does it all by itself
<cbaines>anyone around to guix deploy to hydra-guix-129 ?
<cbaines>I think given I haven't got access to the machine, I can't guix deploy myself
<apteryx>is the hurdvm service supposed to work?
<civodul>apteryx: it's broken since the core-updates merge
<civodul>(fails to boot)
<apteryx>secret service: invalid handshake #<eof>
<apteryx>I think I'll be able to use WireGuard, finally. It kept loosing track of my listening machine, but makes it usable with my dynamic IP
<civodul>but people here have been looking into it over the last few days
<apteryx>civodul: OK! thanks for the link
<cbaines>apteryx, are you able to guix deploy to hydra-guix-129? I think I need someone who already has access to do it before I can.
<apteryx>the wireguard series also include a fix for keep-alives that seems it'd help the build machines behind NAT connecting to berlin. Hopefully they'll stop vanishing :-)
<janneke>apteryx, civodul: hurdvm should work with this patch, though:
<janneke>not sure why jpoiret hasn't push to master yet?
<civodul>janneke: oooh, nice! \o/
<jpoiret>I was waiting for some more comments, also didn't want to push a sole patch (as that's not good for CI)
<janneke>that's what got me working on rumpkernel
<janneke>jpoiret: right, makes sense
<apteryx>cbaines: looking into it
<jpoiret>Although i've been struggling to get some other patches to review to go along with this one
<janneke>iwbn if we got the hurd with rumpdisk to boot ;)
<civodul>apteryx: re WireGuard, my gut reaction is that "this is not our job"; IOW, this should be fixed upstream
<apteryx>I discussed that before, they are not interested in adding that to wireguard itself. They already have some script:
<apteryx>I think on the basis that wireguard is intentionally as lean as possible
<janneke>whut? font-abattis-cantarell-0.303-0.e049149.drv pulls in wxwidgets?
<janneke>man, that's just wrong
<apteryx>in a world where GTK pulls Qt, why not?
<jpoiret>when you apply patches, do you all apply with --signoff and sign them directly?
<attila_lendvai>another idea wrt substitute availability: maybe we could add consecutive tags that are the basis of the build farm, so that if i want to have full coverage i can just rewind a tag or two. context: i want to test a service change, but i can't because several packages are being built locally, and i don't know which commit to rewind to. this is not the first time.
<apteryx>jpoiret: I do
<jpoiret>I do find that weird to signoff and gpg sign them *before* testing and making sure it all works
<nutcase[m]>hi Guix! What is missing in my guix shell --container when it doesn't handle German Umlauts properly (e.g. Ü)
<attila_lendvai>nutcase[m], try adding glibc-locales
<nutcase[m]>attila_lendvai: I already tried that without success, I also tried preserving $LANG
<jpoiret>nutcase[m]: you're missing glibc-locales, and setting GUIX_LOCPATH inside the container
<nutcase[m]>jpoiret: What sould be the value of GUIX_LOCPATH?
<apteryx>janneke: which dependency pulls wxwidgets in?
<jpoiret>I think $GUIX_ENVIRONMENT/share/locale
<efraim>guix graph --path font-abattis-cantarell wxwidgets
<janneke>apteryx: that's psautohint
<janneke>ACTION slowly walks down the rabbit hole
<apteryx>I think psautohint required the full fonttools
<apteryx>but you could try fonttools-minimal to reassest that
<apteryx>if it requires the full fonttools, then perhaps we can have a python-scipy-minimal package that propagates as little as possible
<nutcase[m]>attila_lendvai: jpoiret here is an example that show different behaviour with 'pwd' and with 'ls' I don't understand that.
<apteryx>but why do we need a font in the first place
<jpoiret>nutcase[m]: you didn't set GUIX_LOCPATH, right?
<jpoiret>you need to set it inside the contianer
<apteryx>isn't our policy to let users choose?
<apteryx>I think perhaps only GNOME has a somewhat "firm" expectation of having that font?
<attila_lendvai>nutcase[m], the pwd example works for me, but the ls one prints escaped codes
<attila_lendvai>this in the container didn't help: export GUIX_LOCPATH=$GUIX_ENVIRONMENT/share/locale
<attila_lendvai>nutcase[m], jpoiret: here's what's needed: guix shell --container coreutils glibc glibc-locales, and then inside the container: export LANG=en_US.utf8
<jpoiret>adding glibc would add the environment variable GUIX_LOCPATH to the container
<attila_lendvai>i.e. without adding glibc ls prints escaped codes
<apteryx>civodul: do you remember if /var/cache/guix/publish/ is self contained (no hard links to outside there?)
<apteryx>on berlin
<attila_lendvai>jpoiret, yes, and setting LANG to a proper value is also needed
<nutcase[m]>attila_lendvai: right, in my normal shell (on a guix system) the output of ls looks fine
<civodul>apteryx: yes, it's self-contained
<civodul>beware: the mtime (IIRC) is taken into account for cache eviction
<civodul>janneke: it used to be that font-abattis-cantarell would pull OpenJDK and Rust
<civodul>(and wxwidgets, i suppose)
<janneke>civodul: oh, so i'm kind-of whining after the fact, even
<civodul>maybe there are still good reasons to whin?
<janneke>ACTION just installed guix on their x60 in preparation of hurd experiments, and guix home reconfigure failed...
<janneke>wxwidgets doesn't build on i686
<janneke>and i had this font in my home profile
<apteryx>civodul: OK, thanks. How about /var/cache/guix/publish/zstd. Would putting this on its own file system and syncing it whole be a functional to serve substitutes from somewhere else (e.g. a mirror)
<civodul>apteryx: not possible; things under /var/guix/publish are interconnected
<civodul>namely, *.narinfo files are hard-linked
<civodul>it's again a trick to keep track of usage times for LRU
<civodul>then the other option is the nar-herder, which uses a completely different architecture
<civodul>that's probably the way to go if you want to move things around
<apteryx>OK, that's a bit annoying for mirroring right; it forces everyone to carry as many compression schemes as there are in use on berlin?
<civodul>no, because the "URL" field in narinfo is now unsigned, so one can strip them
<civodul>we don't have any tooling for that, but it's doable
<civodul>(nar-herder could do that i suppose)
<cbaines>yeah, although when using the nar-herder for a reverse caching proxy style mirror, I'm not sure there's any reason to offer less compressions
<apteryx>I think the simplest option for the future is to offer a single compression type on berlin (zstd). Then mirroring becomes a matter of running rsync and the capacity is capped to something a bit more reasonable (3.8 TiB currently)
<apteryx>storage requirements, I meant
<civodul>we could use rsync, we just need to pass the right options to preserve hard links and mtime
<civodul>actually that's already set up, isn't it?
<attila_lendvai>ACTION has rewided/rebased his changes a couple more days, which resulted in *more* local rebuilds...
<apteryx>there's an rsync-service-running, exposed only to the builders behind WireGuard it seems
<civodul>there's a "substitutes" rsync module in berlin.scm
<civodul>we could/should make it public
<apteryx>my point is that 8 TiB + of data is a bit of a large set for cheap mirrors
<apteryx>cutting this as much as we can would open up mirroring to a much wider audience
<civodul>i see
<civodul>i guess the first step would be to open it at all :-)
<civodul>making the rsync module available publicly, with a documented procedure on how to set up a mirror
<civodul>that was the goal with the .cn mirror some years ago
<apteryx>we can do that
<civodul>i think we should decouple the question of what we keep from the question of how people can set up mirrors with reasonable requirements
<apteryx>people will already be able to choose how long of a backlog they keep via rsync
<apteryx>the more problematic thing is the use of hard links that couple the compressed nars together for mirroring
<apteryx>I also see little value in having that even on berlin
<civodul>yeah, that means people will have to pass the right option to rsync, *and* run 'guix publish' on their side
<cbaines>how would this approach handle requests for nars/narinfos that the mirror doesn't have (but the source does)?
<civodul>i guess users could --substitute-urls='MIRROR SOURCE'
<cbaines>(especially in the case where you're intentionally not substituting everything)
<civodul>could we/should we use nar-herder for mirroring purposes?
<apteryx>civodul: is 'guix publish' a requirement or could a web server be used instead, e.g. nginx?
<civodul>apteryx: it's a requirement because of the special file layout + cache eviction handling
<civodul>which isn't great
<cbaines>the nar-herder is designed to enable running mirrors, both for redundancy and high availability
<apteryx>civodul: mirrors do not need to bother with cache eviction, no?
<civodul>cbaines: can it be configured to fetch stuff from a given server?
<cbaines>civodul, yeah, although it expects that substitutes server to be using the nar-herder too
<civodul>apteryx: people running the mirror will want to free space at some point
<cbaines>most of what the nar-herder is doing is keeping an SQLite database of the narinfos in sync
<civodul>cbaines: can we have a bridge, with the substitute protocol connecting both?
<cbaines>but it also can mirror the nars if you want to
<apteryx>civodul: they can have their own retention policy (prune nars older than 180 days e.g.)
<civodul>apteryx: one would usually want least-recently-used (LRU) rather than "oldest"
<apteryx>I see this as a guix-daemon particular design :-) It's useful to maximize available for old clients, but if you only care about offering the latest 6 months, 'find -mtime +180 --delete' does it
<cbaines>civodul, some kind of adapter between guix publish and the nar-herder might be possible
<civodul>that'd be sweet
<civodul>i could give a hand if there's interest
<cbaines>I'm also happy to try and make that possible if there's demand
<cbaines>although you can already use the nar-herder to mirror, which has more substitutes than
<rekado>ACTION rebases wip-postfix again
<apteryx>6 years in the making
<janneke>rekado: thanks -- ancient memories of trying to work towards mailman support...
<civodul>cbaines: yes, that's right!
<civodul>we could document it and publicize it already
<cbaines>yeah, maybe some docs are needed
<cbaines>there's even mirrors that exist, like I run although it's barely used
<civodul>cbaines: could we use the same code when generating narinfos?
<civodul>for instance has "System:"
<cbaines>civodul, should be possible, although first it would be good to move narinfo-string and related bits from the publish.scm script to (guix narinfo)
<cbaines>then the build coordinator can switch to using that rather than it's internal copy
<cbaines>although the System: bit does actually make a difference with the nar-herder, since it means that the metrics for narinfo/nar reqeusts can be broken down by system
<cbaines>you can see this for the narherder_server_requests_total metric for example:
<civodul>ah, i see
<civodul>it's a bit expensive to compute, that's why we removed it from 'guix publish'
<civodul>and it's "non-normative" too, so it doesn't have to be signed
<civodul>but yeah you're right, we should move narinfo-string first
<evilsetg[m]>Hello, I am still plagued by the libpthread error (similar as in As in the linked issue the problem for me is with 5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33.
<evilsetg[m]>Now I have upgraded a couple times and still, when I try to run icedove or libreoffice I get the error `symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE`.
<evilsetg[m]>I ran guix gc -R on icedove and did not even find glibc-2.33 in it's closure (only 2.35) so where could this dependency even come from?
<apteryx>evilsetg[m]: make sure all of your profiles (system, user, home) have been migrated to a recent guix so they all use the same glibc
<civodul>also, make sure the LD_LIBRARY_PATH environment variable is unset
<apteryx>rekado: I'll have to reboot berlin in a bit (perhaps 1 hour)
<apteryx>I'm relocating /var/cache/guix/publish to its own distinct Btrfs subvolume
<civodul>apteryx: you sure you want to do that?
<civodul>mtime/atime, hard links, etc. there's potential for breakage
<apteryx>civodul: yes! :-) worst case we'd have to keep a longer backlog, but mtimes and atimes should be preserved with 'cp -a'
<apteryx>and hard links are self-contained under /var/cache/guix/publish, right?
<civodul>apteryx: right, "cp -a" should work
<apteryx>it's preparation work for 1. a full backup of berlin nars to node 129 and 2. opening up a public rsync daemon serving said backup from node 129
<cow_2001>anyone knows what're the minimal `guix shell` packages one needs for an org-mode development environment where one could `make doc` successfully?
<rekado>I just got this error: failed to compile 'gnu/machine/digital-ocean.scm'
<sneek>Welcome back rekado, you have 1 message!
<sneek>rekado, ngz says: WDYT about getting rid of (version (number->string %tex-revision)) and use, e.g., "2021.3" everywhere? We could have a global list storing associations between texlive releases and SVN revision numbers. `texlive-origin' would be able to generate the correct URL from the version of the package, allowing for piecewise updates (see, e.g., texlive-bidi).
<rekado>ngz: I have no strong opinions on how to deal with the texlive version string. I thought it would be good to update everything together, so that we can be sure that it works as intended.
<ngz>rekado: Of course, texlive-bidi is an exception. But "2021.3" is nicer than "59745", and it makes it possible to write an updater, AFAIU.
<rekado>IIRC we only used the SVN revision because that was easier to work with
<rekado>if that’s no longer the case I’m all for changing it
<jpoiret>couldn't texlive be considered rolling-release?
<ngz>jpoiret: I don't see it as rolling-release. Its more or less a yearly bundle of packages, isn't it?
<jpoiret>well, you can also follow the latest svn revision right?
<jpoiret>but yeah, both work
<jpoiret>people using tlmgr can use the latest and greatest all the time, right?
<ngz>I haven't used tlmgr for years. You are probably right.
<bjc>apteryx: re: erroring out in ‘modify-services’:
<bjc>nothing makes me feel dumber than wrangling macros =/
<ngz>jpoiret: Also it may be a bit costly for the infrastructure to update Texlive every now and then.
<apteryx>civodul, rekado /var/cache/guix/publish is now served from the new subvolume
<apteryx>findmnt /var/cache/guix/publish -> /var/cache/guix/publish /dev/sde2[/@publish]
<apteryx>I'll now reboot just to make sure everything is well defined in the config
<apteryx>copying a zillion kernel modules at boot...
<apteryx>it's back up
<evilsetg[m]>I am trying to understand at what point a store item is alive. Would `for i in $(guix gc --list-roots);do guix gc -R $(readlink $i);done | sort -u > closure.list` show me every single alive item if run by root?
<evilsetg[m]>Ah okay there is guix gc --list-live for that. That gives me a different list though. 😵‍💫
<apteryx>re berlin; anonip is having problems (they appear stopped)
<apteryx>shepherd[1]: '/var/run/anonip/http.access.log' is not a FIFO; bailing out
<apteryx>fixed with the usual dance: rm -f /var/run/anonip/* && herd restart nginx
<apteryx>oh, already reported as :-)
<apteryx>it'd be cool if mcron had a switch to avoid running the same job concurrently
<jpoiret>janneke: can I add a "Reviewed-by:" for you on the Hurd patch?
<oriansj>apteryx: so, the same functionality available in the systemd cron?
<janneke>jpoiret: sure
<bjc>jpoiret: #63501 has ‘hurd-vm-service-type’ working for me 🎉
<bjc>i wonder how hard it'd be to get hurd running on my offload host for building purposes
<bjc>i assume i'd have to run the guix daemon in the hurd itself, otherwise it'll just cross compile?
<janneke>bjc: the hurd will prolly not run on iron yet, we need rumpkernel/rumpdisk and netdde (and possibly more)
<janneke>bjc: you can run chilhurds and offload to those
<bjc>yeah, i'd put it in a vm
<janneke>that's what we do in berlin
<janneke>ACTION did that on their laptop too
<bjc>my understanding is that “childhurd” refers to a hurd running in the hurd? i don't understand how it's being applied in the guix context, where it seems to be linux running the hurd somehow (vm?)
<janneke>note that on current master the native build is broken
<bjc>how'd you bootstrap the vm? debian hurd? or can guix do that now?
<janneke>bjc: oh, it's another name for hurdvm
<bjc>ah, i'd only heard it in reference to swapping out the hurd servers in user-space to create a hurd-within-a-hurd
<janneke>ah no, sorry; just hurd in a vm
<bjc>the problem i have is that my offload host can't run guix natively, so i'm using it as a foreign distro, so i don't think i can run ‘hurd-vm-service-type’ on it
<janneke>i create and run a hurd vm like described here:
<bjc>which leaves me with bootstrapping hurd some other way, then trying to get guix on it. but maybe i can just copy the hd image?
<bjc>great. i'll have a read through that. thanks
<janneke>(it's about rumpkernel, unrelated, but i shared my recipe)
<bjc>i'm extremely rusty with the hurd. it's been probably 20 years since i seriously looked at it last. i dunno what rump* is =)
<janneke>ACTION is lucky enough to run a guix server on digital ocean
<janneke>bjc: yeah, i can imagine
<janneke>there have been some efforts recently to bring up-to-date driver support (nic, disc) support to the hurd
<bjc>heh. the wikipedia page for “rump kernel” refers to the hurd
<janneke>those are netdde (serveral flavors iirc) and rumpkernel/rumpdisk
<chomwitt>Reading about home enviroment dev doc says: "Make sure the operating system has elogind, systemd, or a similar mechanism to create the XDG run-time directory" . What is the similar mechanism ? I ask because why would you need systemd when you have shepherd and secondly i dont want a login manager in my current setup.
<bjc>we have elogind by default to manage sessions, so you won't need to worry
<bjc>i don't know why it references systemd. maybe for foreign distro users
<chomwitt>ok bjc
<janneke>if it doesn't it should clearly state something like: if you're on guix system, you're good
<apteryx>oriansj: I don't know about systemd-cron, but good that it has it!
<ryuslash>Hey Guix \o
<ryuslash>What's the protocol for trying to get someone to have a look at a patch I sent that fixes an issue I'm having? It's been almost a month and I normally don't mind waiting for a response, but it's preventing me from updating Guix and I think my outdated Guix is causing some issues with the host OS now.
<janneke>ryuslash: have you cc'd the members of the team that your patch concerns?
<ryuslash>I have not
<jpoiret>ryuslash: as an example I don't generally read patches I'm not CC'd on because otherwise that'd be too many mails
<janneke>then you could to do that now, it's no guarantee but it could help
<jpoiret>janneke: you can run guix system without elogind
<ryuslash>janneke, jpoiret thanks :) I'll start with that
<jpoiret>I mean, we don't have elogind on the Hurd, right? :)
<janneke>jpoiret: true, but if you manage to do that you'll prolly know what you're doing? -- but yeah, my wording was just a bit too strong, you're right
<jpoiret>yeah, maybe a passing remark adding that the default %desktop-services contain it could clarify
<lispmacs[work]>hi, does Wojtek have an IRC account? I had a question about running Haketilo
<sam-d[m]>has anyone tried to implemet a flatpak build system for guix?
<sam-d[m]>ultimately I would like to have a guix home service that installs a defined set of flatpak packages (at specific versions). I do not really trust flatpak versioning, so I thought about building them based on the manifest files as derivations and then refer in a guix home service. That would require such a build-system. Obviously we would be duplicating flathub at this point.... Any thoughts?
<jpoiret>sam-d[m]: doable but not sure guix would accept it upstream, since it'd just mean duplication of packages in the end
<lilyp>build systems for blobs go to other channels :)
<sam-d[m]>lilyp: plenty of FOSS flatpak packages that could be included. The nonfree ones are obviously out of scope
<sam-d[m]>jpoiret: how ist that different from python/go/cran importer? Or is that because flatpak itself is a container around native packages?
<jpoiret>the latter
<sam-d[m]>that are already in guix
<simendsjo>I see nyxt 3 is released. Anyone working on an updated package? Maybe have a version I could try out?
<jpoiret>I believe nyxt upstream uses guix for its packs, so they might already be working on one?
<sam-d[m]>jpoiret: makes sense. I will think about a different approach to solve my usecase then
<simendsjo>Oh, looks like you're right! I see it in the build_scripts folder, thanks!
<anemofilia>in #guile
<anemofilia>Hey, I am new to guix and am trying to make guix comfortable for me, but there are some things I couldn't figure myself how to do
<anemofilia>I wanted, for instance, to see the shepard log after selecting guix on grub, fix grub dimensions and remove some software like NetworkManager and all the things GNOME
<unmatched-paren>evening, guix :)
<lilyp>sam-d: the purpose of importers is somewhat orthogonal to build systems; they turn packages hosted elsewhere to ones buildable using regular guix machinery
<davidl>Hi, I have a weird error, when trying to build a package from a custom channel. It works to build it using guix build -f package.scm if I end package.scm with the name of the package variable, but not when running guix build mypackage (which is inside package.scm). Im getting this:
<davidl> In guix/packages.scm:
<davidl> 2054:2 6 Exception thrown while printing backtrace:
<davidl>In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f
<davidl>Generally speaking, what is the difference in how a package is built between guix build <package> vs guix build -f <package>.scm when <package>.scm evaluates to the exact same package?
<apteryx>bjc: re modify-services, neat!
<rekado>davidl: does package.scm contain a Guile module, or is it just a file?
<apteryx>how can we emulate the Pre and Post actions with our Shepherd services at the moment? We have to add custom code to insert that in the start/stop slots?
<rekado>the zrythm segfaults are due to this check:
<rekado>gdb tells me that it’s called like this: io_mkdir (dir=dir@entry=0x2b7a5590 "/tmp/zrythm_test_logs", error=error@entry=0x0)
<rekado>I don’t know what error@entry=0x0 means
<rekado>but there sure is a NULL there
<graywolf>Hello, quick question, is with-imported-modules required also from modules from guile (ice-9 textual-ports)?
<elevenkb>Hey y'all's is there a standard way to get cc to be an alias for gcc, etc.?
<agnem>How do people manage their rfkill state with minimal desktop environments? I've tried defining a shepherd service to run `rfkill unblock` on startup, but it doesn't seem to do the trick.
<elevenkb>Eh, I just did `export CC=$(which gcc)` before running my build and it's going okay.
<gnucode>hey friends!