IRC channel logs
back to list of logs
<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?" <evilsetg[m]>ffrrnn: You can also use `loginctl poweroff` to shutdown. <mvnx>I've been using `sudo herd power-off shepherd` hah <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]>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 <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 <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>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... <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 <mirai>I think 'herd doc <service>' <mirai>mvnx: report this bug to the ML <mirai>so its unrelated to whatever you're changing <mvnx>mirai: Ok awesome. Thanks. <mirai>but nonetheless it should be investigated :) <ae_chep>Can I make exclude certain files from "unpack" ? <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 <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>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) <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! <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>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 <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>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>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) <efraim>libgc-8.2.2 FTBFS on core-updates on powerpc-linux <efraim>civodul: there's still an upcoming problem with libjpeg-turbo on core-updates on a couple of architectures <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 <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 <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 :) <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 <uniavix>To translate all strings in a .c file using a .po file but on the .c file itself. <bjc>mirai: thanks! dunno how i missed that commit <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>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 <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 <uniavix>unmatched-paren: yes, similar to patching. <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 <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. <unmatched-paren>uniavix: extracting strings is much easier than putting strings back it <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>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 <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? <etienne_>but I don't seem to have autoreconf installed <etienne_>Ah.. looks like I can guix install autoconf :) <etienne_>(sigh) but it doesn't seem to have autopoint. <etienne_>Do I need to specify --pure or ad-hoc packages? <unmatched-paren>guix environment was deprecated because its interface was considered a bit weird <unmatched-paren>remember to use the /devel version; it has information on the latest commit <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? <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/? <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>" <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_>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>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) <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>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_>/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) <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 <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 <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! <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. :) <jpoiret>sneek, later tell etienne_: Not sure pulling will help, did you build using guix-provided dependencies or using debian's? <jpoiret>mvnx: there was a bug that led to a build error in the repo in the past few days <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'