IRC channel logs
2023-05-16.log
back to list of logs
<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 <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 libc.so.6[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>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. <gabber>(how) can i rename a bug in debbugs? <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 <gabber>i am using emacs! though not the regular key-bindings. would you mind checking which function pressing the "C" key actually invokes? <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 data.guix.gnu.org <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 data.guix.gnu.org, the overhead of the caching is quite high I think <civodul>then data.guix could return a shorter TTL for these? <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 data.guix.gnu.org <cbaines>like yellow for 80%+ and grey rather than red <jpoiret>platoxia: you can use linux-libre-lts as the kernel <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>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? <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? <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 <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" <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) <evilsetg[m]>eshell is kind of what I would like of a lips shell. I do find the shell model of emacs not <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>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 <cbaines>substitute availability isn't terrible, but bordeaux.guix.gnu.org 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, data.qa.guix.gnu.org knows about ci.guix.gnu.org 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>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 <jpoiret>I'll just create a script that rebases all local branches on top of their upstream in the specific worktree <civodul>speaking over there was the GOOPS person themself! <janneke>wow, more of a hacker than an organiser i guess ;) <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 <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 <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' <efraim>there's also the --trailer flag apparently, which could be use for Helped-by or Sponsored-by <jpoiret>but only -s is available for `git am`, and people might be relying on it <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>but you need to fit sudo in there, most likely with `sudo -E ./pre-inst-env guix system ...` <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). <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! https://justpaste.it/Naruto_Kage_Bunshin_Skilton <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 <apteryx>secret service: invalid handshake #<eof> <civodul>but people here have been looking into it over the last few days <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>not sure why jpoiret hasn't push to master yet? <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 <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 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? <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. <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. Ü) <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>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 <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 <apteryx>civodul: do you remember if /var/cache/guix/publish/ is self contained (no hard links to outside there?) <nutcase[m]>attila_lendvai: right, in my normal shell (on a guix system) the output of ls looks fine <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 <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>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) <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 <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 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 <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 <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>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 bordeaux.guix.gnu.org, which has more substitutes than ci.guix.gnu.org <rekado>ACTION rebases wip-postfix again <janneke>rekado: thanks -- ancient memories of trying to work towards mailman support... <civodul>we could document it and publicize it already <civodul>cbaines: could we use the same code when generating narinfos? <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 <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]>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/libpthread.so.0: 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? <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>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>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... <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>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? <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 <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 <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 <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>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 <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>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? <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? <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>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 <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> 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? <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>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 <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.