IRC channel logs


back to list of logs

<civodul>polkit pulling (guix build syscalls) is a real bummer
<civodul>it means we can't easily change that module any longer
<civodul>(due to the rebuilds it would entail)
<nckx>apteryx: Did you ever solve your IceCat timezone mystery?
<nckx>gcarlos: Very old, but familiar:
<nckx>ACTION → 😴💤
<gcarlos>nckx: it seems that setting TZ worked, but why?
<arjan>I can recommend testdriving emacs 29.1 using guix pull --branch=emacs-team
<Hmmf>Hello guys. Is it possible/sensible to copy derivations from a guix instance to another one?
<Hmmf>I mean, from the store.
<psyclimb>Hi! I'm playing around with editing package definitions and i'm getting an error i don't understand, "cannot install non-package object: #<unspecified>". I've copied the package definition for freedoom, as a test, to its own .scm file and i'm trying to install it with guix package --install-from-file=my-freedoom.scm. This worked in the same fashion with the my-hello.scm example. What have i missed here?
<mirai>psyclimb: your file ends with a (define-public …) sexp
<mirai>define-public doesn't return whatever you've just defined
<mirai>if you end your file with the variable you've just defined then it should work
<psyclimb>d'oh! of course... thanks!
<Hmmf>Okay let me rephrase. I am worried about the availability of some sources I am using. How can I ensure reproducibility wrt to that problem? Do you guys have a workflow to tackle that issue?
<arjan>Hmmf: checkout out
<Hmmf>ha that's a reassuring answer indeed. But I was thinking about rolling out my own (maybe personal) source repo. I was curious if some people tried that route.
<Hmmf>I mean, the ultimate answer to that is probably some sort of network of trust but I am not sure that exists yet (well, there is
<apteryx>nckx: it's an upstream issue; see #59368
<apteryx>upstream is
<apteryx>workaround is:
<gcarlos>apteryx: thx, it's a issue I was having :)
<kkcd>Elogind is still putting my computer to sleep ;-; the horrors of systemd
<apteryx>kkcd: still? in what scenario? what did you try?
<kkcd>apteryx: i tried some stuff from the mailing list to no avail (regarding gdm-settings, etc), and then i just started killing elogind, but i think that makes sshd unable to log me in, lmfao
<kkcd>maybe i'll try killing JUST gdm/xorg-server...
<kkcd>and by killing, i mean herd stopping
<apteryx>to nix knowledgeable folks: are Nix setup hooks loosely equivalent to Guix build phases?
<apteryx>kkcd: did you try to set the auto-suspend? option to #f for your gdm-configuration?
<apteryx>GDM has the default behavior of suspending when nobody is *physically* connected
<apteryx>setting the above to #f disables that
<iyzsong>i think nix setup hooks mix both build-system, phases and search-paths
<mirai>kkcd: I think I know the solution for this but am about to hit the sack, can you PM me an email address? I'll send a snippet when I'm up again
<apteryx>ACTION is trying to reverse engineer their
<apteryx>if I get the grunt of it, seems I could add a phase called 'fix-qt-paths' that implements their and
<kkcd>mirai: thank ye
<kkcd>apteryx: where does that option go on guix? i think that was my problem--finding where the file should be
<apteryx>kkcd: something like:
<apteryx>err, I meant to write "the brunt of it" ^^'
<apteryx>funny what English as a second language makes us write
<RavenJoad>apteryx: It depends on the hooks. There are pre<Phase>Hook and post<Phase>Hook "defined" for most of the major phases, but they are optional. Unless you mean the setup hooks that are custom shell scripts?
<iyzsong>apteryx: that remind me some old hacks for qmake (eg: in my commit 8075b623786f1), do we still need those for cmake based QT?
<apteryx>cmake should work, but qmake is still a supported tool
<apteryx>so we must keep it I think
<kkcd>apteryx: I'm seeing in my current config that I have a (modify-services %desktop-services) already, with a single expression below that; can (modify-services) take multiple directives?
<kkcd>Is it fair to call it a directive?
<apteryx>kkcd: it's a Scheme macro, I think. And yes!
<kkcd>Man, that's just nice. The idea that it's all "central" like that is insane to me, because previous attempts on that in linux were so futile.
<kkcd>what's the xdmcp bit there?
<apteryx>RavenJoad: thanks
<apteryx>I use xdmcp with xvnc (it drops me to the login manager screen)
<kkcd>oh ho ho...
<kkcd>That might be the ticket; I'll come back to that later
<RavenJoad>apteryx: If you want to compare what qt does with something simpler, there is something I have done, GNU Octave packages.
<RavenJoad>I know your pain. Guix's method of adding separate phases to do things (which are named too!) is much simpler in my mind, especially when reading it later.
<lilyp>does anyone have a good idea as to why shepherd would busy loop?
<ulfvonbelow>is "busy loop" here a euphemism for "get stuck in an infinite loop and lock the cpu at 100%"?
<ulfvonbelow>or do we mean actually just spin-lock waiting for a context switch?
<ulfvonbelow>if the latter, note that fibers uses spin locks internally to implement operations
<ulfvonbelow>if the former, note that fibers gets stuck in an uninterruptible infinite loop if the initial thunk of 'run-fibers' throws an exception
<lilyp>that's a bad state to be in, no?
<ulfvonbelow>well, at least it's a cold infinite loop (stuck in epoll) instead of a hot infinite loop
<ulfvonbelow>but yeah, not great
<Gooberpatrol66>is there a way to pass nix packages to a guix shell environment?
<apteryx>but you can use nix on top of guix system
<apteryx>in 227 packages added, we'll overtake Fedora 36, according to
<apteryx>in terms of sheer size
<adanska>hey guys, anyone getting failed builds for psautohint on the current commit? running 'guix build psautohint' gives this output: It appears to be failing on a test, but I dont know enough about the package to know what it means or how to fix it. the guix ci website also shows build failiures btw.
<adanska>its preventing me from doing a system reconf
<adanska>does anyone have any ideas on how to approach this?
<ulfvonbelow>could always try to 'guix pull --commit=...' to an earlier commit, or 'guix pull --switch-generation' to an earlier generation
<ulfvonbelow>you could also try to figure out what's using psautohint, and try to make your system config not depend on it
<adanska>im in no hurry to reconf, just want to let people know and hopefully troubleshoot this :)
<adanska>looking at the test itself, my guess is that the 'DATA_DIR' const has been set to something wrong
<adanska>not sure what has changed, will have to see the ci server and check when it last built successfully
<adanska>i see the job has restarted on ci
<adanska>its so cool watching the workers all work on the build distributed haha
<adanska>ACTION is perplexed
<adanska>why has the build succeeded now? theres been no new commits, and when i run guix build psautohint, it applies some grafts and now it works
<adanska>what changed? odd
<adanska>surely the derivation was the same both times? arent grafts part of a derivation? why did ci succeeding mean that i was able to build it?
<adanska>hmmmm... i still have a lot to learn about guix it seems
<adanska>btw whats the difference between bordeaux and ci substitute servers?
<jpoiret>adanska: they're totally independent and they don't run the same CI software
<jpoiret>you can check it builds locally still by doing `guix build --check ...`
<hako>And --no-grafts ;)
<jpoiret>grafts are something you add afterwards: there's a derivation without the graft, that is substitutable, but grafts are marked as not substitutable because it's trivial I/O to graft
<adanska>ahhh... i see
<adanska>im still a little confused as to why a build can fail like that with substitutes, and then succeed half an hour later
<jpoiret>even with isolation, some builds depend on the host machine: sometimes you don't have enough RAM, your kernel is too different, etc...
<jpoiret>it'd be good to know why still
<jpoiret>does it build locally now?
<hako>jpoiret: Thanks for the explanation!
<adanska>yeah, it builds fine now. building with grafts and --no-grafts works
<adanska>which makes it all the more interesting
<jpoiret>hako: FTR, I was explaining what grafts were, your comment to add `--no-grafts` is really important
<jpoiret>with --no-grafts guix will not try to rebuild the original thing to graft
<jpoiret>without *
<jpoiret>so you really want --no-grafts --check if you want to check that it still builds loaclly
<adanska>sorry yeah i added --check as well, all green.
<jpoiret>now that's really weird
<adanska>so my question is how the status of the substitute server made the local build fail.
<adanska>yeah right!
<hako>I just tried to build it locally, and it fails...
<ulfvonbelow>may be dependent on system load, caching, etc
<ulfvonbelow>the joys of nondeterminism...
<adanska>does it fail on the same 'test_hashmap_old_version' test hako?
<adanska>is that with --check --no-grafts?
<hako>Yeah, it is.
<adanska>ACTION is quite! perplexed
<adanska>nondeterminisim joys
<adanska>the only thing determinate in nondeterminism is a lack of happiness
<jpoiret>you can use --rounds to specify how many times you want to build the package
<adanska>ill give it 3 rounds but i think whatever the problem was is fixed on my machine
<adanska>what commit are you on hako? current?
<adanska>i take it back. i jinxed it
<adanska>it failed again
<adanska>what is with this test? there has to be some sort of nondeterministic element to it..
<jpoiret>i'm giving it the --rounds=5 treatment
<jpoiret>is the test passing on successful builds or is it skipped?
<adanska>good question
<jpoiret>well it's passing for me
<adanska>passing on successful builds, btw.
<adanska>failed on the third go. definitely a flaky test
<jpoiret>given the nature of the test, that's very weird
<adanska>mm. do you have any ideas on what might be happening? i might check out the src and try to investigate deeper
<jpoiret>not at all
<adanska>the alternative is just to skip the test on guix, but squashing nondeterminism bugs i feel are pretty important for the project
<ulfvonbelow>are there tests running in parallel?
<adanska>you might be onto something
<adanska>pystest can run tests in parallel, seems like its enables
<adanska>looks like pytest-xdist just spawns n worker processes and runs tests in parallel. this is probably the source of the non-determinism. my first thought was that there was some sort of data race, but each worker gets their own copy of data, so it must be a certain sequence gets the test data into a bad state somehow...
<adanska>at least thats my first impression
<adanska>thanks ulfvonbelow for the suggestion! this smells like the right line of inquisition
<PotentialUser-55>I install guix on top of Ubuntu 22.04 with $(apt intall guix) but it return "guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory" when I type command $(guix install hello)
<next4th>PotentialUser-55: maybe the service need to be started by 'systemctl start guix-daemon'
<PotentialUser-55>I found that the activity of guix-daemon is failed after I start service
<PotentialUser-55> 八  15 17:40:58 nmr05 systemd[1]: guix-daemon.service: Start request repeated too quickly.
<PotentialUser-55> 八  15 17:40:58 nmr05 systemd[1]: guix-daemon.service: Failed with result 'exit-code'.
<PotentialUser-55> 八  15 17:40:58 nmr05 systemd[1]: Failed to start Build daemon for GNU Guix.
<PotentialUser-55>Above is the message of systemd
<next4th>okay, then 'journalctl -u guix-daemon' will give some log
<PotentialUser-55>I get this "Failed at step EXEC spawning /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: No such file or directory"
<PotentialUser-55>I don't have /var/guix directory, is it normal?
<next4th>PotentialUser-55: maybe apt uninstall and reinstal guix again or install using the guix tarball manual, i have no idea why that's missing..
<nckx>It's extracted as part of the binary tarball. Do you still have the full output of the installation script?
<nckx>ACTION read over the apt.
<nckx>PotentialUser-55: Does /gnu exist?
<PotentialUser-55>reinstall still not work both /var/guix and /gnu not exist
<nckx>The Ubuntu package is based on the Debian package maintained by vagrantc (not currently here), but not by the Guix project.
<nckx>The installation method we support is at .
<PotentialUser-55>I tried install via installation script, the daemon work but get another error "/gnu/store/5kj8lyybjrdl7xd0fx9g9vzkz8sklqsy-guix-1.4.0/libexec/guix/guile: error while loading shared libraries: cannot open shared object file: No such file or directory"
<nckx>Oh boy.
<jpoiret>guile loading libgl? 🤨
<nckx>PotentialUser-55: Could you try ‘LD_DEBUG=libs guix’? It'll produce a lot of text, and I don't know what I'm looking for, but it goes without saying that guix does not link to bloody OpenGL.
<jpoiret>then you can paste it to
<nckx>But litharge is hungry ☹
<PotentialUser-55>oops, sorry, I haven't log out and back to complete the installation (mentions in output of installation script), now it works
<nckx>Great success.
<jpoiret>success, but still very weird
<PotentialUser-55>Is log out and back after installation for setting environmental variables?
<next4th>we also had report that bash want to dlopen libQt5Core, a strange world...
<nckx>PotentialUser-55: Yes.
<nckx>I don't know how/when the Debian package creates /var/guix, that's obviously a different issue. I expected a post-install hook but at a glance there's no mention of /var/guix there 🤷
<PotentialUser-55>Why could not just add "export" for setting environmental varibles in installation script?
<nckx>That's not how environment variables work. You can't exfiltrate them from a script.
<jpoiret_on_erc>exports only apply to the current bash session, you can't affect the environment of a parent process.
<nckx>Sent from my Emacs® using ERC.
<jpoiret_on_erc>I just want to try this out and reduce my reliance on web apps that I just can't build myself
<jpoiret_on_erc>my personal server doesn't run on guix yet for that reason
<nckx>What did you use before?
<jpoiret_on_erc>the lounge
<nckx>Oh neat. Haven't tried.
<ulfvonbelow>erc is pretty nice, the only annoying thing is when you're in a bunch of rooms and there's a disconnect, followed by a reconnect, and suddenly you have chat buffers popping up all over your work
<jpoiret_on_erc>yeah, it's pretty nice tbh. You just need a whole web browser to render something that was invented before HTML
<xd1le>the modern world
<nckx>ERC couldn't handle my 150 joined rooms of ZNC scrollback last time I tried it. Neither could circe, so it seems hard to write performant Emacs IRC clients.
<nckx>That said, I'm obviously not sane.
<jpoiret_on_erc>tbh, because we have logs i'm less interested in bouncers
<jpoiret_on_erc>also, IRCv3 with message history™
<Noisytoot>Libera doesn't support that
<jpoiret_on_erc>i'm already living in 2025 and they've added it
<jpoiret_on_erc>or: i'm trying to convince myself i don't need channel history
<gabber`>hello y'all!
<gabber`>i'd love to get some input on how i could speed up the process of getting my patch #61869 merged. i now see that i forgot to prefix the issue with a [PATCH]. if there is anything i can change please let me know!
<nckx>The [PATCH] probably wouldn't make a difference. If people do filter, they're more likely to filter on guix-patches@, which you used.
<nckx>I don't have any input. You didn't do anything ‘wrong’.
<nckx>You could have resolved the new conflicts with d1edb263 and used it as an excuse to guilt people into reviewing, but I can't promise it would help.
<gabber`>and by shaming you mean CC'ing the other reviewer directly?
<nckx>I'm not sure where ‘shaming’ and ‘other’ came from.
<nckx>Who's the other reviewer?
<ulfvonbelow>some would say 'guilt' and 'shame' are highly related concepts
<nckx>Perhaps, but not synonymous.
<gabber`>yeah, sorry.jlkjlkjlkhh
<nckx>Guilt is more intrinsic than shame. But also, more importantly, I didn't mean it so seriously 😛
<gabber`>yes i meant "guilt" and by other i meant Andrew who reviewed d1edb263
<nckx>gabber`: What do you mean by ‘the dnsmasq manual’? I'm looking at ‘man dnsmasq’ and it differs (favourably) from your source. For example, the docs for domain-needed are better, and it cites RFC6303 rather than RFC1918.
<gabber`>i guess i meant `dnsmasq --help`
<gabber`>unfortunately i can't see the man pages for dnsmasq with $(guix shell dnsmasq -- man dnsmasq)
<gabber`>where did i mention "the dnsmasq manual"?
<nckx>You need to include ‘man-db’ in the shell to set search paths.
<nckx>gabber`: In the commit message.
<nckx>The man page also says that --local is a synonym for --server, which the existing service already had (very unfortunately misnamed ‘addresses’, sigh, why do people do that).
<nckx>Is that true or inaccurate in practice?
<gabber`>i'll check
<gabber`>and adjust the commit message
<nckx>No need.
<gabber`>? I'll rebase the patch anyways -- so i might as well get stuff in order (:
<nckx>Sorry that I was unclear. I already have.
<nckx>My ‘could have’ was a bit too subtle ☹
<gabber`>huh. great!
<mirai>how much memory does it take to build this rust thing
<efraim>about 10 GB for rust-bootstrap, less for the rest
<apteryx>quick poll; do you prefer the naming '--target-version' or '--to-version' as a new 'guix refresh' option that globally set the version the packages listed via the CLI or a manifest should be updated to?
<efraim>I like target-version better
<mirai>efraim: that explains my OOMs
<mirai>building with cores=1 is such a slog :(
<nckx>I prefer something not ‘target’, but that's because I've been seeing ‘target’ a lot lately in the XCC context. I have a mild preference for not mixing meanings in options to the same tool.
<apteryx>Qt 6.5.2 is looking good
<nckx>Analogous to --update.
<apteryx>efraim: thanks for the vote and congrats for the rust-team branch merge
<jpoiret>apteryx: haven't looked, but did you switch to ninja for qt 6.5?
<efraim>apteryx: thanks. now I have to decide how much time to take off before applying the new rust patches and sending it through again
<apteryx>jpoiret: nope. I only do so when it provides real value.
<jpoiret>i remember having some test linking huge object files and leading to an OOM
<apteryx>did ninja help in that regard?
<jpoiret>apteryx: well 6.5 didn't build with Makefiles when I tried to update it, and Ninja's the only supported upstream generator
<apteryx>it built fine here
<jpoiret>eh, weird then.
<apteryx>there's this warning that it's not the official backend, but eh.
<apteryx>ninja is mostly helpful for incremental builds, not from scratch ones
<apteryx>so it had only a minute or so of an advantage when building qtbase on a ryzen 3900x machine
<apteryx>for qtdeclarative though, I don't know the reasons, but it leads to a much shorter build (halved or such), so it's used there.
<apteryx>efraim: --target-version it is! pushed as 2884abb3df
<efraim>I get the impression that the ninja builds are more recently updated so tend to build faster
<apteryx>what do you mean by "are more recently updated"?
<apteryx>do you mean that CMake is better optimized at producing ninja build files?
<apteryx>(compared to Make) ?
<apteryx>nckx: oh! just saw your take to the poll. Hm. I see '--update' and '--target-version' as independent, so I'm unsure it'd be good to tie both together
<efraim>possibly. then again I have no data backing it up
<nckx>apteryx: Oh, OK, I missed a use case without --update then.
<nckx>To check whether a given version has been released?
<apteryx>you're right that it'd probably never be used, but I think it indeed could be used to 'probe' if the target version exists?
<nckx>Oh, if it's pushed already then there's scant chance of changing your mind now 😉
<apteryx>scratch that
<apteryx>when we specify --target-version it doesn't crawl the pages
<apteryx>it just rewrites the URL
<apteryx>so it could have been --update-version as well
<nckx>I dunno, it just feels more like a ‘force’ or ‘set’ than a ‘target’, which (to me) implies something slightly less forcible. It's hard to explain, and it's not a hard fact.
<apteryx>ah, I see.
<apteryx>indeed it's not very malleable right now; in the future it'd be nice to be able to --target-version=5 and then it'd crawl the URLs or git history and try to find the latest 5.x.x version
<old>hey I recently got a : ts1-stixgeneral-italic with latex
<apteryx>currently it takes the argument and runs with it
<old>I do have the package texlive-stix2-otf installed in my profile
<old>I know there was some breaking change recently for latex and I'm not sure what to do here
<nckx>apteryx: Oh, OK, if treating it like a constraint/pattern is planned my dislike goes away completel. Well played.
<old>anybody from the TeX team?
<apteryx>there's a single person in the tex team, which is rekado, and they won't be around before 2 more weeks
<civodul>i'd count ngz as chief TeXpert, too!
<old>I think the best ting I can do is to compile my tex file in a Guix time-machine
<old>that ought to do it
<peterpolidoro>how can I set an environment variable that does not already exist when calling "guix shell"? For example if I want to set some new environment variable to the current working directory
<peterpolidoro>do I set it first, then preserve it?
<nckx>FOO=bar command?
<nckx>(So, not a Guix-specific feature.)
<nckx>civodul: ‘sudo herd restart nginx’ hangs on this server (‘sudo herd start nginx’ says it's already running; a lie. There's no PID file). Anything useful to look at before I reboot?
<efraim>I have no idea about nginx and herd, which version of shepherd is that machine running?
<nckx>peterpolidoro: If I parse your second line correctly the second time: ‘yes’.
<apteryx>civodul: I failed to answer that bit of your email: the most value I see in --target-version is in things like: ./pre-inst-env guix refresh -u -m etc/teams/qt/qt5-manifest.scm --target-version=5.15.10
<apteryx>a manifest returns a list of packages, not of refresh 'specs', so lacked any means to specify the target version
<peterpolidoro>FOO=bar; guix shell -E "^FOO"
<nckx>That only works if FOO is an environment variable (i.e. has been exported before).
<nckx>It's safer not to rely on that & to omit the ;.
<apteryx>civodul: do you foresee any performance degradation for 'guix time-machine' by adding a call to update-cached-checkout at the start of each invocation?
<apteryx>that's used to check if the commit provided doesn't go beyond the advertized "oldest commit"
<apteryx>(and produce a useful error message otherwise)
<civodul>apteryx: probably; what matters most in time-machine is the cache-hit path: it shouldn't touch Git checkouts at all, let alone talking to the build daemon
<mirai>If I install guix in a foreign distro, will it act only as another package manager or does it also change grub & etc.
<peterpolidoro>Thanks @nckx!
<efraim>I sometimes do "guix shell foo -- sh -c 'FOO=bar; baz'"
<gabber`>mirai: only as another package manager
<efraim>guix shell -D guix -- sh -c './bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc' is the one I run most often
<nckx>mirai: Just don't run ‘guix system reconfigure’ 😉
<efraim>mirai: I've heard there can be some issues with graphical programs and environment variables, but otherwise it should work just fine
<nckx>ACTION reboots the hung Shepherd server.
<apteryx>civodul: oof. I'll have to measure.
<nckx>…through the control panel, because ‘reboot’ hangs too.
<sneek>nckx: Greetings!!
<apteryx>civodul: fyi, I was asking in the context of
<apteryx>(w.r.t. guix time-machine)
<xelxebar>Recently, the progress bar length calculation has been screwy for me, causing updates to just write a whole new line.
<xelxebar>I'm in a CJK locale, so the text before the progress bar is using double-width chars.
<xelxebar>My guess is the character counting alg. to account for width is simply counting glyphs and forgetting about double-width ones.
<nckx>GNUtoo: I have your libressl patch staged, but it took longer than expected to rebuild all dependents and it breaks opensmtpd. Did you notice that?
<nckx>xelxebar: Almost certainly, but odd that it's only a recent regression.
<efraim>xelxebar: is your terminal "wide enough" to display it properly?
<xelxebar>Yes, terminal is wide enough. Progress bars display fine when there's no CJK text on the line.
<old>is is possible to have a guix home container that use a previous generation?
<old>I would like to start a shell in a home profile from a previous generation without switching the current generation
<old>I guess I could use guix-shell and use the profile associated with the home generation?
<xelxebar>nckx: Unfortunately, I don't recall how long the issue has been around. Probably a few months? Likely just part of the progress bar updates that rolled out a bit ago.
<Reed0>Is there an idiomatic way to set arbitrary environment variables in a manifest.scm file (to be used in guix shell...). I see the Search Paths portion of the manual ( Is "Search Paths" the standard way to set all environment variables (not just ones that point to paths/files)?
<apteryx>Reed0: no! setenv calls will not persist in cached environments
<nckx>xelxebar: Oh, since the advent of the ‘high-res’ progress bars? That makes more sense.
<efraim>there's a bunch of llvm related test failures in gtk for riscv64 :/
<efraim>that's not going to be fun to debug
<nckx>apteryx: But search paths will? Still, it is a hack, and ‘setting arbitrary environment variables’ isn't a goal of manifests, Reed0.
<efraim>Reed0: in theory if you add (setenv "FOO" "bar") before your list of packages in a manifest it _should_ show up when using guix-shell, but I haven't tested it recently
<Reed0>efraim: I see. I'll give that a try. apteryx: Are you saying that doing it this way will only work on a fresh environment, but not one that is cached?
<apteryx>Reed0: if doing it via Guile's setenv, yes
<apteryx>I've not tried using search-path specifications in a manifest, or adding them to a dummy package. I guess that could be a work around.
<apteryx>I'm occasionally hitting hangs when using guix time-machine
<apteryx>the progress wheel is spinning while retrieving substitutes, but top/nethogs suggests nothing is actually happening
<ulfvonbelow>does 'guix shell' set the environment by sourcing the profile's etc/profile or by directly evaluating the search path specifications itself?
<apteryx>search path specification
<ulfvonbelow>ah, so trying to do something cheeky like include a profile as a manifest entry for your profile would presumably not work
<jetomit>in package definitions, what is the difference between #$(this-package-input "foo") and just #$foo? the latter seems to work just as well
<ulfvonbelow>might interact differently with inheritance, depending on whether "the package being defined" referred to in a thunked field refers to the newly-created package or the old one
<nckx>jetomit: Just #$foo breaks package transformations. Avoid it.
<nckx>It's also semantically not what you mean as author.
<nckx>That said, where possible, search-input-file and friends are even ‘better’.
<mirai>within a build-machine record type, which of the sides does 'user' refer to? Is it 'user' from the machine initiating the SSH connection or is it the account on the remote side?
<mirai>the manual isn't too clear here
<ulfvonbelow>remote side
<ulfvonbelow>the offload process runs as root IIRC
<nckx>Yeah, there's no sudo functionality in the offloader.
<jetomit>ulfvonbelow, nckx: makes sense, thanks!
<mirai>"The user account to use when connecting to the remote machine over SSH." gives the impression that 'user' means on the client side
<ulfvonbelow>speaking of offloading, I do kind of wish that it were possible in machines.scm to include "the local machine" as an option, instead of effectively disabling local builds whenever a remote machine is specified
<nckx>I seem to remember that including (and configurating) localhost used to work, but that might have been a fever dream.
<ulfvonbelow>heh, that would be a neat trick
<nckx>mirai: Not how I read it, but a patch making it more explicit would be nice O:-)
<mirai>Does "guix archive --generate-key" have any relation with private-key field?
<ulfvonbelow>but the issue mostly arises when I have some big world rebuild happening on the offload server and I'm also trying to modify some packages and test whether they build locally
<nckx>mirai: No.
<nckx>The former is a Guix (/etc/guix/acl) key, the latter an SSH key.
<mirai>nckx: …and one more thing to the (recursive) laundry list :)
<nckx>Yaks all the way down.
<mirai>I don't think my computer is the only thing that needs a RAM upgrade
<nckx>ulfvonbelow: That sounds like --no-offload should work, though.
<mirai>at this rate I'm going to need one as well
<nckx>When you typed that, I was just writing down my to-do stack for the evening as it was overflowing my squishy cache.
<jab>hello guix people!
<jab>so I am getting an issue when I try to start dino:
<jab>Couldn't open cannot open shared object file: No such file or directory
<jab>my computer I think only support OpenGLv1...
<jab>is that error message saying that my computer is too old?
<nckx>Does this happen in a --pure shell (ignoring missing icons), and is this a Guix System?
<jab>nckx it is guix system
<jab>let me try "guix shell --pure dino"
<nckx>It works in both cases for me here, FWIW.
<jab>It's a thinkpad T400
<nckx>This is an IvyBridge laptop. (X230T)
<nckx>Don't ask me with OpenGLs it supports. It games all the good stuff.
<nckx>I just find the error message a bit weird, although someone returning -ENOENT for missing hardware support isn't unprecedented.
<jab>nckx weird...the error goes away when I do "guix shell --pure dino".
<jab>what!? That seems pretty odd.
<jab>startup time seems a bit slow, but it works.
<sughosha>Hi, could anyone review and push this patch?
<nckx>jab: Anything in ‘env’ that looks suspcious/relevant? You could try (manually) ‘bisecting’ it if all else fails.
<jab>nckx how would one go about bisecting this?
<jab>oh man, dino is running really slowly. this is weird..
<nckx>I meant literally editing the output of ‘env’ and sourcing it in the pure environment, or something else blunt. If you have no other leads.
<nckx>Since my env is 80 lines long and I'd wager yours is longer.
<jab>ok. thanks.
<jab>I'll have to give that a try.
<mirai>huh, why is the SSH public-key required in the master node while offloading?
<mirai>guix offload: error: failed to load SSH private key from …
<mirai>crap, I've pasted the wrong line
<mirai>[GSSH ERROR] The file does not exist or permission denied: "/etc/…"
<nckx>What's redacted?
<mirai>just the name of the key
<mirai>better to put a paste instead
<nckx>I think so, because I don't need any /etc/ssh/*.pub to offload here.
<nckx>Is this ‘guix offload test’?
<mirai> <>
<mirai>If I put the .pub in the same directory as the private-key then it works O.o
<efraim>jab, nckx: I got the same issue with tuba on aarch64
<efraim>haven't tried with --pure
<jab>efraim: let me install tuba and see if that works
<nckx>mirai: Oh, OK, you mean the private-key entry (I have that pointing to $HOME). That's apparently a requirement.
<jab>efraim, nckx I just installed toba. and I am getting some issues...I cannot install tuba...
<jab>sorry, I cannot run tuba. I can install it.
<jab>but "guix shell --pure tuba" works.
<efraim>The overlap I see between tuba and dino are gtk@4
<nckx>Works here, so I have a magic env (possibly because it excludes GNOMEs).
<efraim>I'm sure there's more but that's the first one I see
<efraim>ACTION is on sway
<nckx>ACTION too.
<nckx>But on x86_64.
<PotentialUser-60>What is the minimum requirement for guix?
<jab>I am on sway too.
<jab>I wonder if gtk4 is trying to use GLv2 ...
<PotentialUser-60>I mean what is the minimum requirement for guix to be installed in a laptop? Like memory and storage?
<efraim>guix shell gtk:bin -- gtk4-demo gave me the same error
<jab>efraim, nckx "guix shell gtk:bin -- gtk4-demo" gave me the same error about can't open libGLEVv2
<nckx>That works here too.
<nckx>If the ‘Fishbowl’ benchmark is very slow, it might be hardware-related.
<nckx>PotentialUser-60: Like with any software, there's no way to say, but I'd vaguely say 20 GiB of free space on / and 2-4G of RAM?
<mirai>is it “normal” for something to fail to build when offloaded but otherwise not?
<nckx>Ah, there's a ‘GSK Render’ view in the ‘Inspector’ (top hamburger menu).
<nckx>Here it says ‘GL’.
<nckx>EGL 1.5.
<jab>efraim: tuba doesn't work for me on startup. It is asking for a "login" key and it recommends to install seahorse or kwallet...
<civodul>apteryx: oh indeed; i've just commented on re performance
<nckx>jab: That's ‘working’.
<nckx>How is that not working.
<jab>sorry "not working" -> I am having trouble using it.
<nckx>Right, but working in the sense of loading libraries etc.
<jab>I don't know much about gnome-keyring...
<jab>yes that works for me.
<efraim>jab: I got the same error with --pure, I wouldn't worry about it for now until we figure out what isn't loading the library
<nckx>I'd take a peek at that ‘Inspector’ view if you think it's hardware-related.
<nckx>mirai: Sometimes.
<nckx>But offloading vs. directly building on the remote should not make a difference.
<efraim>nckx: where did you find gsk render?
<nckx>gtk4-demo → ☰ → Inspector → Global
<nckx>There's more GL stuff if you scroll down.
<efraim>I never waited long enough for inspector to open
<nckx>I thought it was broken at first.
<efraim>using GL, GLX 1.4
<philip>I am getting a mysterious error when I try to run e.g. `guix archive --export coreutils > tmp.nar` or any higher-level command: "guix archive: error: corrupt input while restoring archive from #<closed: file 7f67d61f7e70>"
<efraim>guix shell gtk:bin -- sh -c 'GDK_BACKEND=x11 gtk4-demo' worked for me
<efraim>jab: ^^
<nckx>philip: I'd start with checking your store for corruption, ‘sudo guix gc --verify=contents,repair’.
<efraim>or with restarting guix-daemon
<nckx>efraim: Oh? Explain.
<efraim>nckx: it looks like "the wayland backend" isn't linked properly with
<efraim>unless you meant the corrupt archive
<efraim>I've seen that before on shared machines and restarting the guix-daemon has taken care of it
<nckx>I meant your suggestion that there's a known/familiar daemon bug.
<nckx>Oh noes.
<efraim>I hadn't checked the systemd logs more than 'its not working the way its supposed to' and found that restarting it worked
<nckx>efraim: Re: the other thing, then I wonder (but not enough to investigate) why the ‘Wayland’ back-end works for me.
<mirai>what are these \\b within a substitute* pattern? (e.g. (("\\bjade\\b") "openjade"))
<nckx>Word boundary.
<nckx>Technically, the imaginary empty space surrounding each word.
<nckx>I recommend ‘info grep’ for a quick primer on regular expressions.
<efraim>no opengl with the broadway backend
<mirai>nckx: thanks!
<nckx>It's handy in Guix substitutions because not only do you not have to care about the surrounding context (or it changing in a later release), but you don't need to add surrounding spaces to the replacement, or capture each part.
<ngz>old: What is your issue with TeX Live?
<nckx>It's pretty DWIM for a regexp.
<mirai>I often forget the regex specialities
<jab>efraim: guix shell gtk:bin -- sh -c 'GDK_BACKEND=x11 gtk4-demo' worked for me.
<nckx>jab: Are you also using Sway?
<jab>nckx yes.
<jab>last guix system reconfigure was yesterday.
<nckx>Mine was 2 August. Is this a new phenomenom?
<nckx>Yes, I should upgrade, but being unable to upgrade from Linux 6.1 means I keep forgetting.
<efraim>when was the mesa update? anecdotally I think its from then
<nckx>ACTION pulls && reconfigures, that should provide definitive proof.
<jab>it has been a somewhat recent update. I have been using OpenBSD to open dino for about a week (or maybe 2), because guix system could not open dino.
<nckx>Well that's certainly a very big coinkydink.
<jab>should I open a bug report for this? Or are we still investigating?
<mirai>is there some list of packages whose build is "non-deterministic"?
<jab>mirai: I believe that guile is one such package...
<efraim>mesa-21.1.3 was july 29th
<efraim>so about 2 weeks
<mirai>whilst looking at what debian does for docbook-utils I've noticed this <>
<jab>mirai: I know that number exists somewhere. I believe ludo had a blog post where he talked about reproducible builds and gave a stat on how many were reproducible for guix...
<efraim>of course if that is what made the difference
<nckx>I'm on + local patches.
<nckx>None of which touched Mesa.
<jab>mirai: that has a picture of the packages that are not reproducible...
<nckx>I used to have a link to the Guix Data Service package reproducibility survey, but it's gone.
<nckx>The A record, no less.
<philip>No store corruption, but I looked at the log for guix-daemon.service and saw this underlying message: Aug 15 12:36:06 bastet guix-daemon[70997]: guix-daemon: nix/libutil/ virtual nix::BufferedSink::~BufferedSink(): Assertion `!bufPos' failed.
<philip>Restarting the daemon sadly didn't help
<nckx>That's in a destructor, so hm.
<nckx>No other relevant-looking log lines?
<philip>No, just a bunch of "accepted connection" lines
<efraim>are you running guix-publish too?
<philip>efraim: I was. I tried stopping it, but that didn't help. (What I really want to run is `guix deploy`.)
<apteryx>ugh, spurious failures again on berlin:
<apteryx>"cannot build missing derivation"
<apteryx>any idea of what could be causing these? it's a real pain point of the CI
<apteryx>cbaines: any idea what "exception" means on ?
<apteryx>will the branch be built anyway, or is something wrong with it?
<philip>It looks like it might have been a missing GUIX_LOCPATH. I'd been using an alternate guix-daemon to work around Switching back to /usr/bin/guix-daemon seems to be working.
<denys>hello. if a program installed from guix, for example GNU Hello, uses gettext, how do I pass it a custom locale directory at runtime? the LOCPATH environment variable doesn't seem to work, and I don't see how GUIX_LOCPATH relates to it if it does
<nckx>Are you saying GUIX_LOCPATH doesn't work?
<nckx>Guix (glibc-based) applications don't honour LOCPATH.
<denys>it does work, but I don't understand how to get it to pick up my directory with .mo files. it points to lib/locales/some.digits instead of share/locales, from what i saw earlier today
<apteryx>civodul: reading your suggestion to move the validation of guix time-machine ref only when the channel hasn't been cached yet; it's good!
<apteryx>one gotcha I've hit is that update-cached-checkout (which I'd still use in a 'validate-channels' proc) only wants a fully specified commit and not a short refspec such as a v1.0.0 tag
<nckx>denys: I'm not at a computer right now, but did you read the manual section on GUIX_LOCPATH yet?
<nckx>Basically, it's versioned, but should otherwise work the same.
<PotentialUser-45>Is there any file manager from gnu ?
<denys>nckx: the manual shows how to point it at where guix is installed (more specifically, to glibc, but I'm translating an application, not the C library), but what I want to do is load a .mo file I'm working on instead of the one from the immutable guix package
<nckx>PotentialUser-45: There's mc for text terminals, and depending on whether you consider GNOME GNU, there's… whatever their file manager is called this week.
<nckx>denys: Yeah, I don't have experience with custom .mo files I'm afraid.
<apteryx>civodul: nevermind my question it seems like update-cached-checkout does accept branch or tags, when REF is specified as something like `(tag-or-commit . ,commit)
<lilyp>I don't think they have thrown out nautilus for a rust-based file manager… yet.
<nckx>So Guix applications do honour LOCPATH, GUIX_LOCPATH only takes precedence, but I can't figure out how to make LOCPATH work like you expect either.
<jpoiret>there's always dired in emacs :)
<mirai>does a wrapped-program still respect native-search-path ?
<jpoiret>wdym by that?
<nckx>Search paths modify the profile to set environment variables on load, so as long as your wrapper doesn't clobber ('=) them, yes.
<nckx>If you're not using a profile but doing something like $(guix build foo)/bin/wrapper, then no, but not due to wrapping.
<mirai>There's this line: <>
<mirai>would it be ok if instead I set (native-search-paths (list $XML_CATALOG_FILES)) ? (the $XML_CATALOG_FILES is a local patch atm)
<apteryx>did it use to be that guix time-machine --commit didn't accept tags?
<nckx>mirai: I don't see why not. If it's only for (say) xsltproc, add a comment to that effect. Maybe some day there will be a clean way to ‘propagate’ search-paths without propagating inputs.
<mirai>nckx: nay, its that docbook2manxml also makes use of it
<efraim>guix shell gtk:bin -- sh -c 'GSK_RENDERER=cairo gtk4-demo' worked for me also
<mirai>db2x_xsltproc also does but I think this is just a wrapper around xsltproc
<nckx>As long as it's not merely used by some input.
<mirai>well, libxslt also has it set in native-search-paths (again, local patch)
<mirai>I might have misread your last message
<nckx>The ‘merely’ was instrumental :)
<gnucode>efraim: when I am near my computer next I will try that too.
<efraim>I checked the soures and documentation more, cairo is the fallback renderer
<efraim>it was much faster for me than opengl on x11
<apteryx>civodul: v2 sent for the guix time-machine validation
<apteryx>jami is full of artifacts for me using the nouveau driver on old nvidia; anyone else?
<efraim>also it may have been a fluke that it worked before, gtk4 says minimum opengl is 3.2 and I have 3.1
<denys>nckx: thanks! LOCPATH indeed doesn't do what I thought it did. there's no issue with guix. I got confused by what the libc manual says about LOCPATH and share/locale. gettext uses share/locale but doesn't touch LOCPATH at all
<civodul>mirai: hi! i'm (finally) looking at; i think i'm going to apply it all except for absolute file names for PAM modules
<mirai_>civodul: Hi, I'm not too familiar with PAM but I see that it has some tests in place, if they're working fine I think I've no objection to raise.
<civodul>mirai_: awesome, thanks!
<apteryx>refresh + committer is awesome
<apteryx>I've just updated Qt 5 to latest in like 1 min (assuming everything builds)
<efraim>does the kde branch also have qt updates?
<apteryx>civodul: I think you meant lechner
<apteryx>(for #63383)
<apteryx>efraim: no
<apteryx>(as far as I can see)
<apteryx>I used: git log --first-parent origin/kde-updates --oneline
<civodul>bah, "Blocked because of DoS Attack" :-/
<civodul>the good thing is that it ensures i don't do too much review work
<civodul>because that's typically when i fetch loads of substitutes
<apteryx>did it block you from downloading substitutes?
<apteryx>via 'guix substitute' ?
<civodul>it's a firewall issue
<civodul>that presumably all of us are experiencing
<apteryx>that one reads as "gnu: stalonetray: Update to 0.8.5."
<civodul>jpoiret: hey! could you apply when time permits?
<civodul>apteryx: ah sorry :-)
<apteryx>so it's not just a Tor thing?
<civodul>so i guess that for example at work, when everyone's back from vacation, we won't be able to get anything from ci.guix
<civodul>because it's all NAT'd
<apteryx>I like the wireguard idea
<nckx>Thanks. I think we should maintain a second build farm to complement bayfront.
<nckx>I'll draft a proper proposal once I finish the other things 😉
<civodul>nckx: you mean a second second build farm? :-)
<nckx>I didn't, but explain yourself at once.
<civodul>well, we already have two build farms
<civodul>you're proposing to have a 3rd one or do i misunderstand?
<nckx>Hence ‘maintain’ in the sense of ‘keep’.
<civodul>ok, got it
<nckx>No, just not to give up on berlin because it's slipping into the dark beyond.
<civodul>right, and i agree!