IRC channel logs

2023-03-28.log

back to list of logs

<euandreh>podiki[m]: nice :)
<ffrrnn>GUIX
<ffrrnn>What do you use for shutting down from the command line? I tried poweroff, shutdown, shutdown -h now, and shutdown now, and I have failed.
<ffrrnn>Nevermind. Shutdown, no extra options, seems to have worked. Is there some other guixic way?
<ffrrnn>Has anyone ever made the joke "guixotic?"
<jgart[m]>What is like list* in guix?
<jgart[m]>(list* 1 2 3 '(4 5 6))
<jgart[m]>(1 2 3 4 5 6)
<jgart[m]>iamrepl> (1 2 3 4 5 6)
<jgart[m]>oh got it, cons* 🦆
<jgart[m]>CL calls it list* TIL
<evilsetg[m]>ffrrnn: You can also use `loginctl poweroff` to shutdown.
<mvnx>I've been using `sudo herd power-off shepherd` hah
<singpolyma>No power button on your system?
<apteryx>ffrrnn: I think rms made that joke, as a potential distribution name that could have been used ;-)
<podiki[m]>tex users, is there some basic packages needed with xelatex? it doesn't want to convert ``quote'' to proper quotes
<podiki[m]>some sort of language, locale, something setting?
<apteryx>wouldn't you just use Unicode with xelatex?
<podiki[m]>could yes, but all my tex files are still of ye olde ``'' variety (while this style I'm using wants xelatex for compiling)
<podiki[m]>also, my emacs by default does those quotes, suppose can change it going forward
<podiki[m]>if I use xelatex on my non guix machine it does the quotes properly....so I'm trying to figure out what is wrong
<podiki[m]>prehaps relatedly, lualatex doesn't like my file (forget the error right now) but fine on a not-guix system...so something is missing on my end/config
<podiki[m]>guix shell --pure texlive-base texlive-fontspec -- xelatex test.tex
<podiki[m]>with just
<podiki[m]>\documentclass{article}
<podiki[m]>\begin{document}
<podiki[m]>``test quote''
<podiki[m]>\end{document}
<podiki[m]>could it be the message I see "No fontspec.cfg file found; no configuration loaded."
<podiki[m]>seems we lost our fontspec.cfg somewhere along the way btw
<apteryx>lost along the way?
<podiki[m]>i see it back in texlive-latex-fontspec
<podiki[m]> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ad5dddc610fa19e78aaa1885106a419e55f0322b
<practical-friend>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ad5dddc610fa19e78aaa1885106a419e55f0322b
<podiki[m]>and that should fix the problem here, as it has to do with tex ligatures by default, however it still doesn't fix the issue for me
<podiki[m]>(i just made a local fontspec.cfg where my tex file is)
<ffrrnn>evilsetg[m]: is loginctl covered in the documentation?
<ffrrnn>and what responsibilities are covered by certain tools between herd, loginctl, yada yadad
<ffrrnn>yadda yadda**
<podiki[m]>apteryx: seems to be something about ligatures and not having a font mapping tex-text.tec; indeed lualatex also complains about not finding some font data
<apteryx>podiki[m]: I'm far from a TeX export unfortunately
<apteryx>*expert
<apteryx>I hope you find the problem (and a can devise a fix!)
<podiki[m]>i used to know my way around tex, but not this part (really does anyone know all the complexities of fonts stuff?)
<podiki[m]>i'm wondering if it is a packaging thing or a step I need to do; now trying with full texlive
<apteryx>there's probably a component missing
<podiki[m]>ACTION waits for grafting of texlive, that's a lot...
<podiki[m]>welp, that does work
<podiki[m]>so yeah, something missing
<podiki[m]>I'll submit a bug report then
<mvnx>I was setting up `guix shell -D guix --pure` per Contributing guide. My `make check` still fails on this test. Don't even know how to begin debugging it. Any ideas? https://paste.debian.net/hidden/d9466b46/
<practical-friend>"Debian Pastezone" https://paste.debian.net/hidden/d9466b46
<rdrg109_>[Q] Is it possible to list all the accepted values that can be passed to "herd start <xyz>"? In other words, how to list all the services that are known to herd?
<rdrg109_>I only know I can execute "herd status shepherd" and "herd status sshd", but I'm sure there are other services that are running and not running on my system, so I want to get the complete list.
<mvnx>Just `herd status` I think
<rdrg109_>mvnx: Thanks. That helped. I thought it didn't show the complete list, because I searched "ssh" in the output and didn't find a match. I guess I pressed the wrong keys.
<pmf[m]>It can depend on which user you run here status as — I get different services when I run it as root vs as a normal user
<main_>exit
<pmf[m]>s/here/herd/, s///
<mirai>I think 'herd doc <service>'
<mirai>mvnx: report this bug to the ML
<mirai>I also experience it
<mirai>so its unrelated to whatever you're changing
<mvnx>mirai: Ok awesome. Thanks.
<mirai>but nonetheless it should be investigated :)
<podiki[m]>apteryx: for reference, the bug report https://issues.guix.gnu.org/62493
<practical-friend>"xelatex won't render fonts correctly without full texlive" https://issues.guix.gnu.org/62493
<ae_chep>Can I make exclude certain files from "unpack" ?
<kitty1>yo, how is it going?
<unmatched-paren>morning, guix
<unmatched-paren>would anyone care to review https://issues.guix.gnu.org/62356 ? :)
<practical-friend>"[PATCH guix-artwork] website: posts: Add Dissecting Guix, Part 3: G-Expressions." https://issues.guix.gnu.org/62356
<jgart[m]>hi all check out this repology feature that unwox implemented: https://toys.whereis.みんな/?search=gtk
<practical-friend>Exception: #<&compound-exception components: (#<&assertion-failure> #<&origin origin: "struct-vtable"> #<&message message: "Wrong type argument in position 1 (expecting struct): ~S"> #<&irritants irritants: (#f)> #<&exception-with-kind-and-args kind: wrong-type-arg args: ("struct-vtable" "Wrong type argument in position 1 (expecting struct): ~S" (#f) (#f))>)> https://toys.whereis.みんな/?search=gtk
<jgart[m]>i think it will be useful for packaging
<jgart[m]>wdyt
<kitty1>I decided to finally go back and try to set up my guix with a newer version of fastboot again, I feel rather stupid right now as after all of this time I can't get it to like me lmao like, and I *know* I am doing something *obviously* wrong I am sure lmao
<unmatched-paren>jgart[m]: oh, that's very cool!
<unmatched-paren>toys is coming along nicely
<unmatched-paren>lechner: you maintain practical-friend, right? i think it might be choking on the unicode in the link jgart[m] posted
<kitty1>(well, it makes sense that after all this time I couldn't, because I haven't been doing much of anything notable with guix packaging, so by definition I would only know less since last time lmao)
<jgart[m]>unmatched-paren: lol みんな
<kitty1>Ok, I would ask for help but I honestly don't even know where I need help with lmao
<kitty1>in other news, the other day I saw someone packaged kons-9, and that has been fun to play with!
<abrenon>hello guix
<kitty1>oh
<kitty1>apparently I didnt need a new version of fastboot LMAO
<jpoiret>fastboot is usually ok, it's adb that needs newer versions
<castilma>has someone here tried building their packages as hardened binaries? I wonder what code I need in my manifests to achieve that.
<next4th>hello, i just sent a email to call for memebers to join xfce/lxqt/localization teams: https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00368.html
<practical-friend>"Call for members to join the Xfce, LXQt and Localization teams" https://lists.gnu.org/archive/html/guix-devel/2023-03/msg00368.html
<next4th>anyone interested could reply to it, thanks :)
<Guest39>Is there a mirror of the guix packages browser? I think it's down for me right now.
<cbaines>Guest39, I've restarted it, it should be back working now
<Guest39>Thank you very much. :)
<devmsv>Hi, I'm trying to run docker images through singularity but I get the following https://paste.debian.net/1275513/ so I patched singularity like this: https://paste.debian.net/1275514/ and now I get '-gzip-1.10/bin/zcat: line 51: exec: gzip: not found' and I don't know why...
<practical-friend>"debian Pastezone" https://paste.debian.net/1275513
<practical-friend>"debian Pastezone" https://paste.debian.net/1275514
<cbaines>devmsv, looks like the zcat script assumes gzip is on the $PATH
<devmsv>cbaines: which I don't get. Isn't zcat part of gzip package?
<devmsv>and I added it as an input depenency so...
<cbaines>neither of those things on their own ensure gzip will be on the $PATH at runtime
<devmsv>how to do it then? as far as I understand inputs are runtime dependencies
<cbaines>inputs are inputs
<cbaines>references from the output will be in the store at runtime
<devmsv>oh I see this in the pkg definition: (add-after 'install 'set-PATH [..] ;; Have the 'singularity' and 'run-singularity' self-sufficient. [...] (wrap-program (string-append out "/bin/singularity") `("PATH" ":" = (,(string-append coreutils "/bin"))))
<cbaines>the package definition does add the coreutils bin directory to the PATH for the singularity script
<cbaines>(as I think you've just seen)
<cbaines>you could try adding the gzip package bin directory to the PATH in the same way
<cbaines>(I'm guessing gzip is an implicit input from the build system, like coreutils)
<devmsv>Thank you cbaines seems thath now I got it working (at least the guix part)
<apteryx>weird, my networking had completely stopped working; even herd commands couldn't proceed
<apteryx>if someone else experiences the same, it could be caused by the recent update to networkmanager
<civodul>apteryx: i haven't had troubles since the recent network-manager changes
<apteryx>great! let's hope it's was just an odd incident
<podiki[m]>apteryx: the only thing I've had is not resuming connection after waking from sleep; still have to check it was the latest version bump that's the difference (or else the other change on how networkmanager starts/waits for pid)
<apteryx>podiki[m]: is that a regression?
<efraim>libgc-8.2.2 FTBFS on core-updates on powerpc-linux
<civodul>jpoiret: i posted a v2 of your patch series, soon we'll move on ;-) https://issues.guix.gnu.org/62307#23
<practical-friend>"[PATCH core-updates 00/15] Update Hurd and fix build failures" https://issues.guix.gnu.org/62307#23
<civodul>efraim: more worrying to me is total lack of powerpc64le-linux on core-updates: https://issues.guix.gnu.org/61879
<practical-friend>"[core-updates] libstdc++ fails to build on powerpc64le-linux" https://issues.guix.gnu.org/61879
<mirai>civodul, apteryx: <https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1258>
<efraim>civodul: there's still an upcoming problem with libjpeg-turbo on core-updates on a couple of architectures
<practical-friend>"No internet connection after resuing from sleep (suspend) (#1258) · Issues · NetworkManager / NetworkManager · GitLab" https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1258
<podiki[m]>apteryx: definitely didn't happen before for me, there is the report mirai found (though not too much to go on there from what I saw)
<civodul>efraim: "upcoming problem", i like that :-)
<efraim>that's a problem for future core-update hackers
<civodul>what do you mean by "future"? that in practice nobody's working on it these days? :-)
<efraim>upstream stopped tagging releases. riscv64 (and powerpc64le IIRC) aren't supported by the current libjpeg-turbo version
<civodul>oh, i see
<efraim>'future' in this case is ourselves, but some time in the future once this is cleared up
<mirai>apteryx: re #62490, define-compile-time-procedure supposedly errors faster
<practical-friend>"[PATCH] services: nginx: Make logging level configurable." https://issues.guix.gnu.org/62490
<mirai>and about revamping the config section, it's best left for another series since it will be non-trivial to get nginx reshaped into something that makes everyone happy
<mirai>but for now, please just make it stop grinding down my flash drives :)
<apteryx>mirai: but only for thunked fields
<apteryx>so not actually useful here
<mirai>huh, ok, that's interesting
<mirai>I think there's maybe 3 uses of it within guix?
<mirai>but they're not thunked as well iirc
<mirai>I don't know then, perhaps it's unnecessary? I'm mostly mirroring the pattern, maybe civodul can weigh in?
<apteryx>it'd be nice if a macro expert can weigh in, because I'd rather we don't cargo-cult patterns we don't understand
<apteryx>ACTION reads on define-compile-time-procedure; I thought it was something from Guile but it's a Guix thing
<bjc>it is, and it causes issues with geiser
<bjc>which reminds me that i need to submit a bug report about that. civodul says he's got a solution, but i haven't seen a commit for it yet
<uniavix>It may be a little bit offtopic but also related to Guix because I'm trying to translate it. Do you know how to replace all strings in files using gettext but without compiling?
<mirai>bjc: 0143e3f291842d2cba138515e616948c7ae8c04e
<practical-friend>"guix.git - GNU Guix and GNU Guix System" https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0143e3f291842d2cba138515e616948c7ae8c04e
<unmatched-paren>afternoon guix :)
<uniavix>To translate all strings in a .c file using a .po file but on the .c file itself.
<uniavix>unmatched-paren: hi!
<bjc>mirai: thanks! dunno how i missed that commit
<uniavix>mirai: hi!
<unmatched-paren>uniavix: i don't think there's really a way to do that
<unmatched-paren>uniavix: it's impossible to know what a "translatable" string would look like unless you actually built a tool like this on top of, like, clang or something
<unmatched-paren>and that would only work with C or C++
<uniavix>unmatched-paren: using gettext.
<unmatched-paren>you could replace _G (or whatever the macro is, i don't remember), but ultimately it's entirely possible to define a new macro that hides _Gs
<uniavix>I want to use a .po file to translate a .c file but not compile it.
<unmatched-paren>you'd need to check whether some macro call ultimately expands to gettext(), so it'd be really hard to make a tool that does that well
<unmatched-paren>uniavix: you can't do that
<unmatched-paren>translation happens at runtime
<unmatched-paren>(as far as i know)
<uniavix>That's the thing.
<uniavix>Thanks! I'll try something else.
<uniavix>There should be some way of doing it...
<unmatched-paren>since you'd probably need to use libclang or whatever gcc provides if it does provide an api, i doubt gettext would include such a tool even if it was written as a patch
<unmatched-paren>(which is why i doubt Gettext Expander(TM) is a thing)
<uniavix>unmatched-paren: yes, similar to patching.
<unmatched-paren>uniavix: ...i think you may have misunderstood :)
<uniavix>If xgettext extracts strings it should also replace them...
<unmatched-paren>the problem is it'd be *impossible* to figure out what to expand to a translated string accurately without actually parsing the C file
<efraim>civodul: for libstdc++ on ppc64le on core-updates, which libstdc++ is failing? the libstdc++ for gcc-final?
<unmatched-paren>and not just the C file, the entire header dependency tree of the C file
<jpoiret>civodul: gonna have a look rn
<unmatched-paren>and be able to parse at least #defines and macro calls
<unmatched-paren>as far as i can see
<unmatched-paren>uniavix: for extracting strings, though, you don't need to figure out which strings you want to translate; it grabs all the strings in the file, right?
<uniavix>unmatched-paren: xgettext makes that I think. I can extract but not the opposite. I know how to get strings out but not put strings in.
<uniavix>unmatched-paren: yes.
<unmatched-paren>uniavix: extracting strings is much easier than putting strings back it
<unmatched-paren>in
<unmatched-paren>you'd need to actually parse the entire C file and interpret macros etc and THEN figure out which strings have been used with gettext() and co
<unmatched-paren>and actually some strings depend on runtime values iirc
<unmatched-paren>like i think gettext has a feature to check "will i need a plural here?"
<unmatched-paren>so, the only way to do it -- imperfectly, too -- would probably involve hooking into a C compiler
<unmatched-paren>(if i'm missing something please do correct me :))
<uniavix>I don't know but thanks.
<acrow`> cbaines: Issue 60976 had successfully completed QA more than one month ago but has been in the 'unknown' state now for at least two weeks. I looked at the error message which seems to be asking for a git commit in the guix repository, added the base commit (which is in v4 1/4) but it gets rejected. I guess I don't understand what it needs to allow the QA process to again complete. Any suggestions?
<practical-friend>"[PATCH] gnu: Add ditaa." https://issues.guix.gnu.org/60976
<etienne_>Hi! I am trying to follow the set up from the guix video there: https://guix.gnu.org/en/videos/2020/packaging-part-one/
<etienne_>but I don't seem to have autoreconf installed
<etienne_>Ah.. looks like I can guix install autoconf :)
<unmatched-paren>etienne_: you should use guix shell
<etienne_>(sigh) but it doesn't seem to have autopoint.
<unmatched-paren>guix shell -D guix
<etienne_>in place of guix environment, I guess?
<unmatched-paren>guix environment guix == guix shell -D guix
<etienne_>Do I need to specify --pure or ad-hoc packages?
<unmatched-paren>no, you shouldn't
<unmatched-paren>just -D guix
<etienne_>awesome, thanks!
<unmatched-paren>guix environment was deprecated because its interface was considered a bit weird
<etienne_>Thanks, seems to work.
<etienne_>So the video was indeed out of date :)
<unmatched-paren>guix environment guix should have worked
<unmatched-paren>yeah
<unmatched-paren>you should consult the manual for up-to-date information
<etienne_>Thanks! I'll have a look.
<unmatched-paren> https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html#Building-from-Git
<practical-friend>"Building from Git (GNU Guix Reference Manual)" https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html#Building-from-Git
<unmatched-paren>remember to use the /devel version; it has information on the latest commit
<unmatched-paren>though 1.4.0 wasn't that long ago so release shouldn't be *too* bad
<etienne_>Thanks. That's very useful.
<etienne_>The info re certificates is slightly different than https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html#X_002e509-Certificates
<practical-friend>"X.509 Certificates (GNU Guix Reference Manual)" https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html#X_002e509-Certificates
<etienne_>I don't see why that would make a difference though, unless keys are different, but the way I did it, following the above link, worked just fine.
<etienne_>Anyway it worked. Thanks for your help! :)
<apteryx>I wonder if mcron's time specification are honored across reboots
<apteryx>(I suspect they aren't but I haven verified)
<apteryx>say I define a job with a time spec '(next-month); and reboot the machine every week; would it ever run?
<torari_real>guix
<torari_real>:)
<mvnx>The Arch docs for `getty` suggest that `mingetty` is an alternative for `agetty`. I noticed the `%base-services` adds both. Are they really alternatives or useful together?
<minima>hi :) i'm about to write a very simple xinitrc entry in my guix home configuration, but before doing that i thought of double-checking whether there's any "facility" for that file that's provided by guix home already?
<minima>probably not as i don't seem to see it in the repo under gnu/home/services/?
<torari_real>okay
<etienne_>Hi! I am trying to build a package, from a debian11 vm running on aarch64. Upon build, I get "version GLIBC_2.33 not found". What's the correct way to fix this?
<jpoiret>etienne_: what do you mean by "upon build"?
<etienne_>When I run "pre-inst-env guix build --no-grapfts <insert name of package>"
<etienne_>minus the typos
<jpoiret>and where does that error message pop up?
<etienne_>First thing it spits out after I hit RETURN.
<jpoiret>does `./pre-inst-env guix describe` do the same thing?
<etienne_>Jep.
<etienne_>My debian11 vm does seem to have an older glibc, but (I am new to guix), my understanding was that it was not important and guix would have its own.
<jpoiret>yes, this should be the case
<jpoiret>what about `./pre-inst-env echo hello` and `./pre-inst-env guile`?
<etienne_>echo works, but guile complains the same way (glibc 2.32 not found)
<jpoiret>and I guess just `guile` works?
<etienne_>yes
<jpoiret>glibc_2.33 not found or 2.32?
<etienne_>pre-inst-env guile complains not finding 2.32
<etienne_>It's very strange though, running a command spits 4 errors, 3 of which about missing 2.32 and 1 about missing 2.33.
<etienne_>I am new to guix. I must have messed up downstream.
<etienne_>I pull guix again, and re-make. Might help?
<euandreh>thanks for whoever added the 'validate-runpath phase
<euandreh>s/for/to/
<euandreh>it helped me catch a build error early in the process
<rekado>etienne_: is LD_LIBRARY_PATH set?
<rekado>do you have more output to share?
<etienne_>Ah good, good catch. No, it isn't set.
<etienne_>/home/parallels/Repositories/guix/guile: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/vyxyl5fky706czpzrkhnk3jpl1xh2vr7-guile-3.0.9/lib/libguile-3.0.so.1)
<etienne_>/home/parallels/Repositories/guix/guile: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/vyxyl5fky706czpzrkhnk3jpl1xh2vr7-guile-3.0.9/lib/libguile-3.0.so.1)
<etienne_>/home/parallels/Repositories/guix/guile: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/5xz71mrgl82293g2dabakjha2xqnq1vm-libgc-8.0.4/lib/libgc.so.1)
<etienne_>/home/parallels/Repositories/guix/guile: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /gnu/store/gfjp8gfv4xxschbaxvldpigadfwqazhw-glibc-2.33/lib/libpthread.so.0)
<etienne_>p
<mvnx>How long ago did you set up from the Contributing guide? I couldn't even get a working build off of the last few days git
<etienne_>Sorry, I missed the command originating the errors: parallels@debian-gnu-linux-11:~/Repositories/guix$ ./pre-inst-env guix build --no-grafts parallel
<etienne_>Just today...
<mvnx>Hmm I haven't tried today yet :) thanks
<cel7t>Is there an easy way to test out changes made to Guix?
<cel7t>Compiling it with make every time is cumbersome
<unmatched-paren>cel7t: you *can* use ./pre-inst-env without making first but it's much, *much* slower
<unmatched-paren>remember to use -j$(nproc) with make to maximise throughput
<cel7t>Ahh I see so to get ./pre-inst-env I should just follow steps up until the make command, right?
<cel7t>and I can't believe I forgot to pass the -j$(nproc) argument, that could've sped this up a lot!
<etienne_>That's what i did today myself :)
<cel7t>I thought it would automatically do it
<cel7t>Gentoo's global flags have spoiled me xD
<etienne_>Alright, I am off to bed. I'll pull again from scratch tomorrow, make and start over. :)
<etienne_>Good night!
<jpoiret>sneek, later tell etienne_: Not sure pulling will help, did you build using guix-provided dependencies or using debian's?
<sneek>Will do.
<jpoiret>mvnx: there was a bug that led to a build error in the repo in the past few days
<jpoiret>it's been fixed now
<cel7t>Do I need to run make before using ./pre-inst-env? Because I'm getting an error that says Guix cannot be executed since it is a directory
<cel7t>Oh okay I think I finally get it
<cel7t>You just need to run make once, after that whatever edits you make work with pre-inst-env
<jpoiret>yes, but if you've already run make once it shouldn't be too long to incrementally run make after edits
<apteryx>hum, guix build: package 'widelands' has been superseded by 'widelands'
<unmatched-paren>night guix \o
<apteryx>unmatched-paren: o/
<apteryx>blueprints (read: rough hacks) for a proper 'guix review' command: https://notabug.org/apteryx/guix-api-examples/raw/master/command-line-hacks.sh