IRC channel logs
2023-08-15.log
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? <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? <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 <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? <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 gnu.org). <apteryx>nckx: it's an upstream issue; see #59368 <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 qtbase-setup-hook.sh <apteryx>if I get the grunt of it, seems I could add a phase called 'fix-qt-paths' that implements their fix-qt-builtins-paths.sh and fix-qt-module-paths.sh <kkcd>apteryx: where does that option go on guix? i think that was my problem--finding where the file should be <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 <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? <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>I use xdmcp with xvnc (it drops me to the login manager screen) <kkcd>That might be the ticket; I'll come back to that later <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 <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 <adanska>hey guys, anyone getting failed builds for psautohint on the current commit? running 'guix build psautohint' gives this output: https://paste.debian.net/1288973/. 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>its so cool watching the workers all work on the build distributed haha <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>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 ...` <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>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... <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>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. <adanska>so my question is how the status of the substitute server made the local build fail. <hako>I just tried to build it locally, and it fails... <adanska>does it fail on the same 'test_hashmap_old_version' test hako? <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>what is with this test? there has to be some sort of nondeterministic element to it.. <hako>642ae73ec0c38ee4758ad9d39f16232c8945c6b6 <jpoiret>i'm giving it the --rounds=5 treatment <jpoiret>is the test passing on successful builds or is it skipped? <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 <adanska>the alternative is just to skip the test on guix, but squashing nondeterminism bugs i feel are pretty important for the project <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>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. <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" <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? <nckx>The Ubuntu package is based on the Debian package maintained by vagrantc (not currently here), but not by the Guix project. <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: libGL.so.1: cannot open shared object file: No such file or directory" <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 paste.debian.net <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 <PotentialUser-55>Is log out and back after installation for setting environmental variables? <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 <nckx>What did you use before? <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 <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. <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. <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`>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 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 ☹ <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? <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>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 <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>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>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>when we specify --target-version it doesn't crawl the pages <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>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 <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 <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 <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. <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. <nckx>…through the control panel, because ‘reboot’ hangs too. <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. <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? <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 <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. <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>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 :) <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>so I am getting an issue when I try to start dino: <jab>Couldn't open libGLESv2.so.2: libGLESv2.so.2: 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. <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>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/….key.pub" <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>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 <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 <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>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). <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... <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>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. <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 <nckx>philip: I'd start with checking your store for corruption, ‘sudo guix gc --verify=contents,repair’. <efraim>nckx: it looks like "the wayland backend" isn't linked properly with libGLESv2.so.2 <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. <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>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 <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>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... <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>None of which touched Mesa. <nckx>I used to have a link to the Guix Data Service package reproducibility survey, but it's gone. <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/serialise.cc:15: 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>any idea of what could be causing these? it's a real pain point of the CI <apteryx>will the branch be built anyway, or is something wrong with it? <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. <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. <mirai>does a wrapped-program still respect native-search-path ? <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>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 <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. <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>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? <civodul>that presumably all of us are experiencing <apteryx>that one reads as "gnu: stalonetray: Update to 0.8.5." <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 <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’. <nckx>No, just not to give up on berlin because it's slipping into the dark beyond.