IRC channel logs


back to list of logs

<kbtdr>away, sleep
<lechner>sneek / botsnack
<apteryx>jgart[m]: nice to know! I haven't read it yet myself.
<jgart[m]>apteryx: This one is really good:
<dec0d3r>Hello, I am testing guix-system-vm-image-1.3.0.x86_64-linux.qcow2 with qemu. What is the password for 'root', ie. 'su --login root'? A google search reported that 'root' password should be empty, but this is not working.
<lechner>dec0d3r / Hi, not sure about Guix but in many images the root passwords are locked. what is empty is the user password but they are in the sudoers group. you can then escalate your privileges with sudo command or if you find that tiring sudo bash
<dec0d3r>thank you, 'sudo bash' gave me 'root@gnu'
<lechner>dec0d3r / yay!
<lechner>Hi, is linux-6.0.9 building for anyone? I think it's the documentation
<dec0d3r>I am trying to understand shepherd, so I can use it as an alternative to sysvinit and systemd
<lechner>me too
<lechner>although i am already using it
<dec0d3r>I cannot find any examples online on setting up shepherd as an alternative to sysvinit/systemd do I am have to dig around in the /gnu/store/*shepherd*.scm files
<apteryx>apologies, I don't know what happened
<lechner>dec0d3r / this is not useful?
<lechner>dec0d3r / or this?
<rothari>Why do I get this "error: unsupported manifest format" everytime I run a guix command?
<dec0d3r>lechner: I read the shepherd manual but could not find any example shepherd.scm files so I am trying to find how guix creates the shepherd.scm file and its contents. It seems that guix does not use /etc/shepherd.scm
<dec0d3r>lechner: I was also trying find how to start shepherd during the boot sequence
<dec0d3r>lechner: I am thinking a init shell script that is just 'exec shepherd --config=/etc/shepherd.scm'
<lechner>dec0d3r / your questions are fair game in this channel, because we are currently the most significant user of the Shepherd. As for calling it from a shell, why not use the Linux kernel option init=/path/to/shepherd ?
<dec0d3r>lechner: I did think of that but couldn't find an example, I will give it go.
<Humanoid>How does the guix tarball get build? The one that you untar to install onto a foreign distro. Is there a guix command and/or scheme file?
<lechner>Humanoid / maybe 'guix pack'?
<Humanoid>That looks like it's probably it. Thanks!
<cnx>how do i set resolv.conf in guix?
<cnx>ACTION rtfm and found static-networking-service
<zamfofex>sneek: later tell civodul: Thank you so much for your work on Guix and its next release, and also towards helping me realize my dream of one day being able to run the Hurd as my main installation! Last time I tried, besides lacking substitutes, I found that netdde wasn’t working correctly — if I could be able help check and fix that before the release, that would be wonderful for me!
<sneek>Will do.
<dcunit3d>if i need to use patchelf and LD_LIBRARY_PATH, how can i ensure that libdl, zlib and libpthread are available?
<dcunit3d>if ld-linux is in /run/current-system/profile/lib, do the other .so the same profile?
<dcunit3d>do the other *.so's need to be in the same profile? or should i extend the LD_LIBRARY_PATH to include them? if this isn't the right place to ask, can you point me in the right direction?
<zamfofex>Can’t you use ‘patchelf’ to patch the file name of ‘’ appropriately to the executable itself?
<dcunit3d>well after i patched, libz is available and now i'm encountering an issue where libfuse can't be found. however, it might be that libdl is not working correctly. i know that things like libpthread were interned(?) into glibc (which i think means the headers are inside libc and are no longer necessary, correct me if i'm wrong). i can't find many references to libdl in guix, except in the 'ell' package (on a package search) and sparsely
<dcunit3d>in the guix ./gnu/ directory
<dcunit3d>it's an appimage, so i may need to extract it and patch it all the way down. i tried that once with another app, but it was booby trapped (that binary took many steps to ensure it was run in exactly the way it was intended). i'm more likely to succeed with this one.
<zamfofex>The symbols in libpthread and libdl (among others) were moved to libc in glibc 2.24 (see: <>)
<dcunit3d>awesome, thanks! i'm just now familariizing myself with the deeper parts of that ecosystem.
<dcunit3d>it's not a huge deal for this app to function (raise3d ideamaker). I can just move on to getting a freecad environment/profile set up. but i'm doing more work with CAD and 3d printing. however unfortunate, i may be running into this more often and i'm running Guix system on my personal laptop.
<dcunit3d>thanks for the help
<zamfofex>I’m glad I was able to help in some way.
<zamfofex>Have you considered trying to use ‘guix shell -CF …’?
<dcunit3d>ok wow i didn't know about that
<unmatched-paren>morning guix!
<Lumine>Good morning #guix
<jgart[m]>good night!
<jgart[m]>or not yet, it's just over midnight
<PotentialUser-30>2 Patches for contributing are ready. Whats the receiver for the mail? In the dev manual i read: "just the cover letter to the address" but in the code they write ""
<unmatched-paren>PotentialUser-30: Oops.
<unmatched-paren>That's a mistake, sorry!
<PotentialUser-30>Whats so or (doesnt matter?)
<unmatched-paren>(I wrote that section, so I accept full responsibility :))
<PotentialUser-30>OK. So the cover to and the manual is to be corrected?
<PotentialUser-30>And as team name i'd take "mentors" ??
<unmatched-paren>well, what's the patch about?
<PotentialUser-30>Enable video for nheko messanger / and therefor the tiny little gst-plugins-good-qt thingy (you remember you helped me)
<unmatched-paren>there's not any particular team for that
<unmatched-paren>ACTION notices that their package-features proposal would be quite helpfel here
<PotentialUser-30>Dont know what you mean / what to do... ??
<unmatched-paren>PotentialUser-30: don't use etc/teams.scm here; there isn't really an appropriate team for this patchset
<PotentialUser-30>So no CC ?? - that would also be the easiest for me here :-)
<unmatched-paren>yeah, no ``--cc''
<PotentialUser-30>OK. So first the email to - waiting for the issue number and then ??
<PotentialUser-30>Do you have a cool idea for both "appropriate subject line and blurb " ??
<unmatched-paren>PotentialUser-30: subject line should usually be the commit message from the patch you think is the most "important"
<unmatched-paren>e.g. if one patch adds my-app, and the others add libraries required for my-app, you'd use the commit message ``gnu: Add my-app.'' as the subject line
<unmatched-paren>the blurb should just be somethincg like "Hi Guix, this is a patchset to add the foo package, an app for frobbing bars and bazzes."
<PotentialUser-30>OK. And the blurb is the diff? Or the patch "inline" the email ?
<unmatched-paren>No, the patches will be replies to the cover letter.
<PotentialUser-30>AAh OK !
<unmatched-paren>Once you get the issue number, of course.
<vagrantc>it's so much easier with single-patch series
<unmatched-paren>it should be easier, but debbugs doesn't recognise that patches that are replies to each other should be grouped in one issue :(
<vagrantc>i never understood the problem with submitting multiple patches as attachments in the initial bug submission
<vagrantc>or if i did, i forgot it, maybe willingly :)
<PotentialUser-30>Manual says: git send-email outgoing/0000-cover-letter.patch -a... In the help for git send-email there is no -a switch (anymore ?) So whats the -a for?
<unmatched-paren>PotentialUser-30: -a is a format-patch switch, but send-email supports all the same options as format-patch plus a few more email-specific options
<vagrantc>ACTION wanders away
<PotentialUser-30>Hmm. But in format-patch help i also dont find the -a :-(
<PotentialUser-30>Sorry: git help format-patch says:  -a, --text (Treat all files as text)
<PotentialUser-30>git format-patch -h didn't say that...
<unmatched-paren>PotentialUser-30: hmm
<unmatched-paren>it means --annotate for git send-email
<PotentialUser-30>But there's only --annotate and no -a switch. Strange. Anyway. I used the -a and we will see what happens :-)
<unmatched-paren>PotentialUser-30: Hmm. -a does work for me.
<PotentialUser-30>OK. Got my email in CC so waiting now for the issue number...
<jonsger>mirai_: do you know what exactly shepherd-requirement expect as a "symbol"
<unmatched-paren>jonsger: any service's ``provision'' symbol
<unmatched-paren>if no service provides that symbol in its provision, the service will not start
<jonsger>unmatched-paren: and how would I write (shepherd-requirement '()) with service radicale?
<jonsger>ah got it :)
<jonsger>(shepherd-requirement '(radicale)) works
<civodul>Hello Guix!
<sneek>civodul, you have 1 message!
<sneek>civodul, zamfofex says: Thank you so much for your work on Guix and its next release, and also towards helping me realize my dream of one day being able to run the Hurd as my main installation! Last time I tried, besides lacking substitutes, I found that netdde wasn’t working correctly — if I could be able help check and fix that before the release, that would be wonderful for me!
<zamfofex>sneek: botsnack
<civodul>zamfofex: yes, we need to remove dust from the Hurd bits after the release
<zamfofex>I suppose the release is now too eminent to expect for it to be doable before it. Is that right?
<civodul>yes... unless there are volunteers to do the work + review :-)
<zamfofex>I could try to investigate it, at least! At any rate, I’m glad that Hurd substitutes are finally going to come! How did you solve the issue regarding containers (and the question of what to put in them)?
<zamfofex>When you say “the Hurd bits”, do you have anything specific in mind besides netdde?
<zamfofex>And also, I remember running into various issues (some regarding glibc being outdated at the time) while creating that toy substitute server. In fact, I remember some patched were applied to glibc as a result of my findings, and still haven’t been released! How did you get around those? See: <>
<civodul>zamfofex: re substitutes, we're just back to the previous situation; the container/isoluation problem has yet to be solved
<zamfofex>civodul: I see. Is there any reason to not settle for exposing a sane (i.e. larger than ideal) set of “primitive” packages to the container at first, then work towards potentially reducing it over time? It seems like the best solution would be to have a container at all, then working on improving it.
<zamfofex>Though of course, I admit, it seems even better to have substitutes at all, then working on improving them. 🙂
<rekado>made some progress with libreoffice on i686
<rekado>this bug report is now relevant:
<rekado>tomorrow from 10am UTC+2 until the end of the day there will be a site-wide network outage due to replacement of the core switch.
<rekado>=> no substitutes from today
<civodul>hey rekado
<civodul>today or tomorrow?
<civodul>ah :-)
<rekado>this brain…
<civodul>great that you made progress on LO
<rekado>progress is sooo slow though
<civodul>yeah, that one's tricky
<rekado>oh, correction: this outage should only affect one building
<rekado>so IIUC it will not affect the outside connection of the data center
<rekado>(I’m passing on the info as I get it; in a meeting now)
<civodul>yesterday i was in a meeting all day long and the only thing i managed to do was send the release update
<civodul>(and we had a rather fruitful mini Guix workshop with colleagues of mine!)
<civodul>BTW, we missed the Nov. 23rd celebration date!
<civodul>the second celebration date :-)
<jonsger>Guix needs a birthday caretaker :)
<rekado>ACTION rebuilds libreoffice again…
<nckx>gm Guix.
<nckx>rekado: Fun isn't it? Days of fun.
<nckx>I've tried newer versions of GCC, binutils, gold, with no success so far.
<nckx>civodul: Heh. Happy GNU to all who celebrate, I guess :)
<rekado>I made good progress with a patch, but it’s impossible for me to anticipate all locations that can trigger the problem
<nckx>Just read your mail.
<nckx>Interesting, maybe. None of the ‘issues’ I faced with newer GCC mentioned ‘uno’, I think…
<nckx>Did you mess with the C++ std version at all? When I start adding basic options like that, which the build system should set, that's when I start thinking I'm off into the weeds on a bad hunch.
<mjw>second birthdays :)
<nckx>Another misencrypted mail arrives which I can't open.
<nckx>User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
<nckx>Is Gnus part of Emacs upstream?
<ardon>Hi Guix! I'm running Guix on postmarketOS with Phosh (gnome for mobile) and GTK apps installed via the package manager don't seem to read the correct GTK theme. Using gsettings to modify it only changes the GNOME skin and the theme of applications installed in the host system. Using gtk-theme-name in ~/.config/gtk-3.0/settings.ini doesn't seem to take any effect either. Any hints?
<ardon>XDG_DATA_DIRS seems to be correctly set to the ~/.guix-home directory, and gtk-icon-theme does seem to be working.
<ardon>Also, using `GTK_THEME=<theme-name> <application' makes it pick the correct theme.
<yasht>Is there a way to specify package architecture in a guix profile manifest?
<mirai>is it possible to subscribe to a debbugs issue on reply?
<nckx>yasht: Maybe there's a more concise built-in way of which I'm unaware, but:
<nckx>When in a wet paper bag: code.
<yasht>nckx: Thanks. I'll try it out now
<nckx>mirai: No. :-/ The social work-around is to ask to be CC'd on replies. Only works downthread, of course.
<mirai>I might have missed some replies then
<nckx>Another option:
<mirai>reading and the shepherd docs, I wonder: can you control when a service gets the "ready" status?
<mirai>with shepherd
<jonsger>ACTION doesn't get any mails for subscribed bugs anymore, e.g.
<mirai>without resorting to wrapping the main program in a shell script or in this particular case, tweaking nginx itself
<jonsger>maybe it's just something wrong with mirai mails... Downloading doesn't lead to the correct mbox file...
<mirai_>jonsger: about the radicale issue, nginx upstream directive allows you to tweak retries and timeouts
<rekado>I get an error when I do this: guix shell --system=i686-linux -D --rebuild-cache libreoffice
<rekado>guix shell: error: package librsvg@2.50.7 does not support i686-linux
<rekado>yet clearly we can (start to) build libreoffice for i686-linux
<mirai>jonsger: ??? you're right, debbugs is showing the previous email
<rekado>namely with librsvg@2.40.21
<mirai>jonsger: but did you get my reply in that one?
<nckx>jonsger: …OK, that's weird.
<jonsger>nope, just saw it via mumi webinterface
<mirai>so I can't just "You may also send email to to comment." then
<nckx>Why not?
<nckx>I mean, what's the alternative?
<mirai>nckx: I mean plainly do it and expect for the participants to know that they received a reply
<nckx>I seem to be missing <> as well.
<nckx>Normal: if you don't CC them, they won't get a reply unless they're subscribed to guix-patches@/bug-guix@.
<nckx>Normal: *everyone* who is subscribed should get your reply.
<nckx>I don't know if you CC'd me, but I should have a copy regardless.
<nckx>Could you PM me your e-mail address?
<jonsger>nckx: its here the mail address
<nckx>mirai: Thanks.
<nckx>As I suspected, you are whitelisted, and not otherwise blocked 🤔
<nckx>On both debbugs lists.
<nckx>I did get it: lmtp(…<1842><So8VK2HqfGMyBwAA0J78UA>: save: box=INBOX, msgid=<1d3856f6-8adb-7b1a-57c5-bb22533c202e …>, from=mirai <…>, subject=[bug#46049] [PATCH] services: nginx: Add ssl-protocols option., flags=()
<nckx>I guess it not showing up in a ‘ssl-protocols’ is a mu4e bug, not related.
<nckx>*in a … search.
<nckx>‘No matching messages found’ — bud, the whole thread is in my mailbox 😒
<nckx>jonsger: How did you ‘subscribe’ to 46049?
<jonsger>I guess by sending in the initial report
<nckx>ACTION has never not been subscribed. IC.
<nckx>I don't see anything obviously malformed about my copy of mirai's mail.
<jonsger>yeah, than its maybe just my mail provider...
<nckx>;bug=46049;mbox=yes works so I think this is a Mumi bug. The /5/raw one, I mean. So many bugs.
<nckx>mirai: To get back to your actual point (sorry), ‘reply all’ to debbugs mail should always do the right thing. Should.
<mirai>nckx: right, I'll try it on a future thread (am using Thunderbird for replies)
<rekado>ACTION tries upgrading libreoffice
<jonsger>ACTION eyes aren't really happy about green colour choice of
<nckx>jonsger: Oh. Why not?
<nckx>(A good argument for the comment!)
<nckx>It's just an improvement over the previous colours, nothing more.
<nckx>Not really meant to be pleasing.
<jonsger>I find it a bit light, the "normal" green e.g. used here is "nicer"
<nckx>Nice was not the goal.
<lechner>nckx / occasionally, I receive emails from debbugs (or from bug respondents) that include "" among the sender or recipients. Is "reply all" an appropriate action in those cases?
<jonsger>nice as in readability
<lechner>where may i find the new shade of green, please?
<nckx>lechner: Yes, that should DTRT.
<lechner>btw, if anyone needs free secondary (backup) dns, this password-free option is the coolest and most ingenious thing i have seen in networking in a while
<lechner>i think the new one is better, and the blue should be darker. here, the first two are barely distinguishable on my equipment
<lechner>jonsger / nckx / here are the colors i came up with when i needed maximum visual impact
<jonsger>lechner: that green (#00c627) is better then the #9f9 green, on my monitor with my eyes :)
<nckx>Ironically, this is one thing I'm not willing to bikeshed:
<nckx>(right is the old scheme).
<nckx>Amusingly, it's actually just as bad without the filter.
<lechner>the real issue with that graph is the arrangement of the dots, which i believe is alphabetical, and therefore imparts relatively little meaning about a contribution to buildability
<lechner>i would pick pie charts by build system
<nckx>Of course.
<nckx>You know where to send it 😉
<nckx>This was a cost-effective hack to make the dashboard usable for me *at all*. Hence why I didn't even touch the CSS part.
<lechner>i will get there eventually! here is another example of imperfect presentation, in my view, since the number of packages is not subtracted out
<nckx>All presentation is imperfect, but there's lots of room for improvement. Just in case you didn't know, we also have such global stats: but something happened to wipe the history a few days ago.
<nckx>Anyone with a penchant for gooder graphs, go nuts!
<nckx>ACTION won't even mention the raw crackpipe potential of the Guix Data Service.
<lechner>my goal was not to criticize but rather to provide alternatives and perspective in view of an aesthetic disagreement
<lechner>ACTION wonders with "aestetic" is apparently not in ispell's american dictionary
<nckx>I guess even Americans know how to spell aesthetic. Thank u, vapourwave.
<jlicht>lechner: I know of 'esthetic' in American English, which would be written aesthetic in British English.
<nckx>lechner: I know!
<nckx>I'm just not interested in the aesthetic part of the discussion.
<nckx>Choose high-contrast furple & glorp, and I'm still happy.
<lechner>i don't blame you, but i still think Guix is beautiful!
<lechner>nckx / is the guix data service similar to UDD?
<nckx>lechner: I wouldn't have gone for the full-page background myself, but my god is <> one of the downright prettiest non-cliched colour schemes I've seen in a while. Anything but blue & white is good, but this is on point.
<nckx>lechner: I can't say, first time I've heard of UDD. ‘Probably’.
<civodul>nckx: changing colors was a good idea, thanks for doing that
<nckx>Fonly Libreoffice were so easily fixed.
<nckx>Build just froze my laptop, had to reboot.
<nckx>Literally ‘froze’, so probably just OOM.
<nckx>Not literally. ‘Literally’. ⛄
<lechner>my equipment tends to get too hot instead
<rekado>damn, event the 8TB SSD gives me I/O errors on the honeycomb
<rekado>maybe something’s up with the SATA controllers after all…?
<civodul>we must be very unlucky
<lechner>you have been having a lot of disk problems lately
<rekado>no, same disk problems
<nckx>lechner: It's a model (Honeycomb) of machine that is very picky about RAM & storage, apparently.
<nckx>rekado: It doesn't actually eat the drives, right…? They still work elsewhere?
<rekado>I just dug out an old USB SATA adapter to look at the drive
<rekado>the 500GB SSD still reports as having read errors (when running the “short” test with smartctl)
<rekado>so I still feel justified in trying to get them replaced
<rekado>I have another SSD with Ubuntu installed in the honeycomb, and that one works just fine.
<rekado>(I’m using this to boot and then install Guix)
<lechner>is this a cable issue? or EM interference?
<lechner>maybe someone took the shield of the power supply
<lechner>it could also be adjacent equipment, if your case is not grounded
<rekado>nobody touched these machines but me, and nobody took off any part of the power supply :)
<rekado>but I am trying with yet another SATA cable
<lechner>i might connect some of this to the big green (or green and yellow) screw
<lechner>perhaps there is elevator or HVAC equipment on the other side of the wall
<reyman>Hi !
<reyman>I have a little packaging question
<reyman>I use (build-system cargo-build-system) for a package, but i also need some guix package installed to do the job
<reyman>how do you mix input needed for a module to build ?
<jgart[m]>What guix package do you think you need installed to do the job?
<reyman>i need (list "ninja" "gn" ) , because some crate of rust need ninja installed to do the job.
<jgart[m]>So it sounds like that is only needed to build the software but it is not a dependency of the software itself
<jgart[m]>What is this package?
<jgart[m]>Can you link it?
<jgart[m]>Is it a library or an end user rust app?
<reyman>yes, you're right, this is only to build the package.
<reyman>the package is crate `v8 v0.49.0`
<jgart[m]>You'll need to add those two to native-inputs
<reyman> #:native-inputs ((list "ninja" "gn" )) into arguments ?
<jgart[m]>(native-inputs (list ninja gn))
<reyman>but the builder say entry is not valid, so i miss something
<jgart[m]>There's no keyword argument that exists for #:native-inputs iirc
<jgart[m]>It's a record field of <package>
<reyman>ok, and i push that where ?
<jgart[m]>line 99 is wrong
<jgart[m]>What I said above in my last statement
<reyman>hum, so i need to create a package definition
<reyman>based on my define-public
<jgart[m]>not sure what you mean by "and i push that where ?"
<jgart[m]>I think you should add this (native-inputs (list ninja gn))
<jgart[m]>guix edit bat
<jgart[m]>See that bat package for an example
<reyman>ok !
<reyman>ooookkk ! thanks a lot @jgart
<jgart[m]>and this might or might not give some further clues of things you might need to do:
<jgart[m]>if you can read some nix
<reyman>i package a looooooot of crates to compile "deno", i hope this is the end of my suffering
<reyman>but i'm not sure
<jgart[m]>reyman: You might be able to suffer less if you can learn how to use etc/committer.scm
<reyman>i try to package quarto, for R/Python(message on mailling list), i progress at small step because this is the first time i package things
<jgart[m]>But that script might be buggy sometimes so be careful
<reyman>i use a lot guix import
<reyman>but there is error in dependency sometimes yes
<jgart[m]>etc/committer.scm auto commits packages in your unstaged area with the appropriate GNU style commit message that upstream expects
<jgart[m]>./pre-inst-env etc/committer.scm
<jgart[m]>One footgun about the script is that all packages have to be non-contiguous in the file
<jgart[m]>Otherwise, it will commit them together as one commit even though it is two packages
<reyman>ok lol, i cut all my packages into xxx.scm
<jgart[m]>I would also study efraim 's previous commits to see what he does
<jgart[m]>efraim: commits a lot of rust packages correctly so he would be a person's commits to look at to see how things are done
<reyman>ok, i will look on that, i create a channel for my first packaging
<jgart[m]>Would be good to have rust packaging guidelines and tips somewhere
<reyman>yes, actually i do that using brute force learning :)
<jgart[m]>testing in a channel is a good start
<reyman>things like dependency naming are not clear
<reyman>is it rust-dep-x-x-x or rust-dep-x-x depends of the level of granularity needed by crates and the things that already exist in, not easy
<jgart[m]>the pattern i've seen is that instead of rust-dep-x-x-x you just update rust-dep-x-x
<jgart[m]>I would study semver notation for packaging rust
<jgart[m]>Because the rust community uses semver religiously from what I've seen
<lechner>Hi, when do I have to use computed-file instead of plain-file, please?
<jgart[m]>And you can be flexible with versions you use if you know the semver conventions
<iska>I want to send a patch but it's really just a version bump and updated hash, can I just do it from here?
<lechner>iska / you mean, not send a patch?
<jgart[m]>lechner: study these examples:
<iska>lechner Idk, no experience
<jgart[m]>iska: probably not
<lechner>iska / i'll help you. do you have a local guix checkout?
<jgart[m]>I would just send the version bump in a patch to Guix Patches <>
<jgart[m]>as usual
<iska>I'll try
<reyman>ok @jgart[m] this is probably why i suffer due to >x.x version and <x.x version to found the good combinatory of packages
<jgart[m]>iska: Are you having trouble setting up git send-email?
<iska>I didn't know that existed
<jgart[m]>reyman: Yes, I would agree that that is why you're suffering right now
<iska>I'm a complete beginner
<jgart[m]>iska: set that up first
<jgart[m]>git send-email
<lechner>iska / i'll walk you though it, or i can send the patch on your behalf (with you as committer)
<jgart[m]>iska: I use this script to send patches:
<jgart[m]>But you can just read that one liner and copy paste it into your terminal
<jgart[m]>git send-email --to="" -1
<jgart[m]>After you commit just run the above
<unmatched-paren>iska: there's also the manual section:
<reyman>hum, now seems the CLANG is not recognized and rust buid try to download " build_script_build::clang_download"
<jgart[m]>reyman: See here for a template commit message for updating a guix package:
<reyman>strange because i have (native-inputs (list ninja gn clang-toolchain clang))
<jgart[m]>unmatched-paren: why is the --base=auto required?
<jgart[m]>or not required but recommended
<unmatched-paren>jgart[m]: not required, but it adds a little ``base-commit: ...'' to the bottom of the first message
<jgart[m]>I've never used it
<unmatched-paren>which helps the committer figure out how to rebase it
<unmatched-paren>because they know which commit it was based on
<jgart[m]>Can you share an example of a commit made like that?
<unmatched-paren>manual page notes this: The --base=auto flag automatically adds a note at the bottom of the patch of the commit it was based on, making it easier for maintainers to rebase and merge your patch.
<jgart[m]>oh got it
<jgart[m]>I might start using that now
<unmatched-paren>jgart[m]: i think you could also do ``--base=origin/master'' but i'm not sure
<lechner>that's what i do
<lechner>well, or core-updates
<jgart[m]>I'll have to update my gp script
<jgart[m]>I just type gp -1
<unmatched-paren>lechner: i might update the manual page to use that instead, so you don't need to do ``git branch -u master'' first...
<jgart[m]>or gp -150 if rust
<lechner>btw, the 'auto' did not work for me
<unmatched-paren>lechner: even after ``git branch -u master'' or no?
<unmatched-paren>auto uses the set upstream branch, i think
<jgart[m]>unmatched-paren: do you use git worktrees when packaging?
<lechner>i'm not sure
<unmatched-paren>jgart[m]: no, not yet
<unmatched-paren>lechner: i will update that
<jgart[m]>there's a thread somewhere where efraim explains why they use it
<lechner>also, i use the local branch, i.e. --base=master
<jgart[m]>raghavgururajan: also uses git worktrees regularly
<jgart[m]>it just helps when you're switching between hacking on master or core-updates without having to rebuild after switching a branch and without taking up extra space by cloning the guix checkout twice
<reyman>hum, how i could set the CLANG_BASE_PATH based on the native input installed, it seems rust don't found it and try to download the chromium version of clang ?
<iska>error: gpg failed to sign the data
<iska>gpg --clearsign does work though
<unmatched-paren>iska: that probably means pinentry failed to start
<unmatched-paren>did you configure pinentry-program?
<iska>I can use pass
<reyman>the config of dominicm work well if you need example of gnome + gpg
<reyman>i use it with gnome + gpg + yubikey and everything is fine
<oat>no file system procedure on /dev/sda1 skipping \ failed to start service 'file-system' | Do someone have face with the issue?
<jgart[m]>could GNU shepherd benefit from an app like this?
<yarl>Hello guix
<unmatched-paren>yarl: hello!
<oat>what is the difference an issue and bu?
<apteryx>rekado: looks like we have yet another disk failure on node 129
<rekado>apteryx: the 8TB disks?
<apteryx>/dev/sdd SanDisk SSD PLUS 240GB
<rekado>oh, these guys
<rekado>actual disk failure? Or did I just touch them wrong when I put in the Samsung disks?
<apteryx>[577132.628337] I/O error, dev sdd, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 2
<apteryx>[577071.231900] BTRFS warning (device sdc3): lost page write due to IO error on /dev/sdd3 (-5)
<apteryx>that's in dmesg
<apteryx>also, # btrfs device stats /
<yarl>I am attempting to write a (gnu) service, my problem is that I got a "warning: possibly unbound variable `<pmb-configuration>'" (comes from `define-record-type*`) and when I try to test the service in a system configuration, when I `guix system container ...` I got ... "error: <pmb-configuration>: unbound variable". Am I missing an use-module?
<rekado>it’s suspicious that this happens now because just yesterday I was in the data centre and plugged in the new disks
<lechner>rekado / with poor shielding, your hand near a cable may cause temporary changes in impedance
<rekado>this is not it
<rekado>we don’t have any adapters so they are oddly balanced in the oversized slots
<apteryx>rekado: it could be also that the cable got partly disconnected/failed
<rekado>yes, so I wouldn’t worry about it.
<apteryx>if you had to wrestle them around a bit
<rekado>I’m busy with reinstalling the aarch64 nodes now, but feel free to mess around with it
<iska>sent my first patch
<civodul>yarl: hi! i don't see the string "pmb-configuration" in Guix, maybe that comes from third-party code?
<rekado>(there’s no cable, just an exposed connector in a big disk slot)
<yarl>civodul: It comes from me :), i.e. (define-record-type* <pmb-configuraton> ...)
<rekado>the I/O error with the 8TB disk in the honeycomb here seems to be due to a bad SATA cable
<rekado>changed it
<lechner>rekado / is the data center anywhere near this NMR imaging or microscopy equipment?
<rekado>there’s nothing exotic about this disk failure
<rekado>ACTION goes back to fixing the machine
<yarl>civodul: I tried to follow how the nginx-service-type is declared (I picked something to follow).
<apteryx>on node 129, a 'guix gc' ends with: guix gc: error: executing SQLite statement: database disk image is malformed
<apteryx>that doesn't seem recoverable?
<yarl>reloading emacs.
<yarl>(wip, ofc)
<rekado>I get this error on aarch64 after booting Ubuntu 21 and installing Guix with the installer script: guix install: error: cloning builder process: Invalid argument
<rekado>something about user namespaces?
<yarl>Am I missing an use-module?
<civodul>rekado: is that an old kernel?
<civodul>something about namespaces, but not unprivilged user namespaces (the daemon doesn't use that)
<civodul>yarl: this module LGTM; maybe the "unbound variable" error comes from a file that *uses* this module?
<rekado>not very old: 5.4.47-00007-g8edfda9bc
<yarl>civodul: That's the system I'm trying to `(guix system container ...)` :
<rekado>guix describe says it’s commit a0178d34f582b50e9bdbb0403943129ae5b560ff
<civodul>yarl: hmm that looks good as well, i must be missing something
<yarl>civodul: for completeness :
<lechner>Hi, when dealing with gexps are conversions like (number->string ...) better done one one side vs the other?
<rekado>ACTION continues with --disable-chroot :-/
<ardon>Has anyone had any luck signing PDFs digitally in Guix?
<yarl>civodul: hmm I modified gnu/, is that it?
<civodul>yarl: no that doesn't have any effect; does your new (gnu services plm) module build fine?
<jgart[m]>civodul: What do you think of having guile core meetups? Is that something that the Guile community would be open to? Do you think wingo would have time to join in on that or other core devs?
<yarl>civodul: I cleaned-go && bootstrapped && configured && making..
<jgart[m]>The idea would be to meet to discuss development being currently done on core guile and roadmaps and to just brainstorm together on the state of guile the language and how it can be improved.
<yarl>I had a warning when making about unbound <pmb-configuration>.
<jgart[m]>The PureScript compiler devs for example get together at least once a month to review open PRs and WIP ideas for improvements:
<jgart[m]>They get together on Discord unfortunately
<civodul>yarl: i see: there's a typo ("configuration" vs. "configuraton")
<yarl>civodul: Oh!
<yarl>civodul: Thank you/sorry :(.
<civodul>heh, yw :-)
<rekado>jgart[m]: Guile things are better discussed on #guile.
<rekado>ACTION completes RMA forms…
<jgart[m]>rekado: but Guix is Guile and Guile is Guix...
<unmatched-paren>jgart[m]: Guix is Guile but not vice versa ;)
<jgart[m]>For me it is. Guix is probably the main (only?) reason I use Guile tbh ;() Guix should just be the package manager built into Guile...
<unmatched-paren>many people use guile but not guix
<nckx>Then Guile would still not be part of Guix.
<nckx>rekado: Just fmyi, have you tried anything more with LO?
<jgart[m]>unmatched-paren: i know
<jgart[m]>nckx: not sure what you mean but ok
<nckx>It's actually striking how many people are only (active) in either #guix xor #guile. It's not like there's a 90% overlap like there would be in some other projects.
<nckx>jgart[m]: You said Guile is Guix. I was responding to that.
<nckx>ACTION milkshare run, good evening everyone.
<rekado>nckx: I haven’t been successful with my other builds yet
<rekado>tried adding another hunk to the patch to fix the new linker error, but it had no effect.
<jgart[m]>In my world, Guile is a language to implement Guix and to support Guix. If you write guile-kolam it's because you're going to integrate it into mumi. If you write guile-email, it's because you're going to use it in the guix-data-service. If you write git bindings (guile-git), is because it's going to be used in the guix core. If you write a json parser (guile-json), It's because you probably want to use it in Guix... etc.
<jgart[m]>I'm only half joking
<rekado>if you want to reach people who are in a position to act on your recommendations for Guile then #guile is the right place to bring them up, not #guix
<mirai>I'd take guile as a Scheme implementation (technically it's more than that)
<rekado>the above view on guile looks rather myopic to me.
<mirai>and guix just happens to be written in Guile's flavour of Scheme
<jgart[m]>It's sarcastically myopic
<jgart[m]>I'm only joking
<jgart[m]>hard to convey that over irc
<lechner>Hi, what's the difference between non-negative-integer and maybe-non-negative-integer, please?
<mirai>the thing about modules being named with guile has to do with subtle differences between Scheme implementations
<unmatched-paren>lechner: i think "maybe-" can also be #f
<lechner>i thought all types can be #f
<jgart[m]>lechner: That might be a #guile question
<lechner>you are funny
<jgart[m]>You'll have to IDENTIFY first to talk on #guile
<jgart[m]>and the matrix bridge doesn't work unless you IDENTIFY also
<lechner>thanks, never used matrix
<mirai>lechner: its a #guix question
<lechner>that's what i though
<jgart[m]>just a footgun to be aware of since element doesn't warn about it
<mirai>the maybe- types are guix specific macros
<mirai>the manual also covers about this
<rekado>12.18.5 Complex Configurations
<lechner>btw, any chance we could stop publishing the non-devel manual?
<rekado>“i define-maybe” in an info reader
<rekado>the idea was to provide the manual corresponding to the release users would have downloaded
<rekado>might be worth moving that to a versioned location
<jgart[m]>ya but won't users do guix pull right after?
<rekado>and make the devel manual available via /latest/ (and direct to it by default)
<lechner>what's the percentage of users using a release?
<rekado>what would you do with a percentage? what’s the threshold to inform your decision?
<rekado>most people use the release to get started
<rekado>if they “guix pull” first or not is unknowable
<rekado>using the release is a good way to get substitutes for the first installation
<lechner>without being able to support the assertion, i believe that our releases are only used for new installs. the accurate manual is very useful then
<rekado>it’s abnormal that the release is so far back, though
<rekado>yes, releases are only to be used for new installations
<rekado>I agree that the release manual is a poor default, especially when the URL is not versioned
<lechner>i know that i could, and perhaps am even supposed to, run 'info' locally but the reality is that search engines prioritize the old manual even though few people---especially contributors---are using the old version
<lechner>i say just get rid of it, and tell those installing Guix for the first time to find the old manual if something does not work
<lechner>i think we already recommend to run 'guix pull' at the first opportunity.
<lechner>mirai / rekado / thanks for the maybe-* pointers. why is it valuable or necessary to prevent false values from being serialized. couldn't the test for that be on the other side?
<lechner>is it necessary to distinguish #f from the literal string "#f"?
<mirai>the idea for maybe-* types is to skip serializing them
<mirai>if absent
<lechner>what happens when I call #$(...) on a maybe-* type that is #f?
<mirai>there's a difference with a variable (or directive, it doesn't matter) being: unset, present with some value, even if boolean
<mirai>say, with an environment variable
<mirai>FOO= (foo with no value) is not the same as FOO being unset
<mirai>lechner: afaik, the maybe- types are mostly relevant for define-configuration
<lechner>mirai / that's where i am using them.
<lechner>or not, rather
<lechner>mirai / okay, so i am a bit new. i use something like (format port "~a\n" #$(accessor config)) to write out a configuration file. the value is optional, so i bracket with (let and (if inside the gexp. in that case, i do not need the maybe-* types, right?
<mirai>which usually concerns whether or not you want some directive serialized to the file
<mirai>lechner: can you centos/debian paste it
<lechner>i am a little embarrassed because it's my first time with define-configuration, but okay
<mirai>with the define-configuration and serialize procedures so far
<lechner>this is for cachefilesd
<lechner>the place arises in a line like 124
<lechner>the question arises in a place like line 124
<mirai>briefly skimming through it, the use of 'call-with-output-file' seems unnecessary since you're already using 'computed-file'
<lechner>that was going to be my next question. i took that from here
<mirai>tbh, define-configuration is best used in conjunction with the serialize-<type> procedures
<mirai>as is, you're mostly doing things manually like with define-record-type*
<lechner>mirai / can you think of an existing example, please??
<lechner>the patch i started with predated define-configuration, i believe
<mirai>hmmm... I recall that dovecot and fail2ban makes use of serialize- procs and define-configuration
<lechner>i looked at dovecot but it does something complicated with a shadow configuration called opaque-*
<mirai>you can grep through the gnu/services/ files for examples using it (the manual also explains how they're used)
<mirai>under the Complex Configuration section
<mirai>lechner: forget about the opaque*
<mirai>you're interested in the <prefix->serialize-<type>
<mirai>fail2ban might be a bit easier to digest
<mirai>but the manual also contains a good example how those procedures piece a file together
<mirai>on how*
<lechner>are you saying the lines in the cachefilesd config file should be constructed directly in the serializer?
<lechner>what if two values belong on one line?
<lechner>i need a complex type?
<lechner>i get it now! with maybe-* the line will not appear!
<mirai>unless this file also has an unorthodox structure, each serialize- procedure should build a line for the fields that get string-join'd with 'serialize-config'
<lechner>i love it
<lechner>do i have to provide the newlines?
<mirai>lechner: if they're not part of the values or of the file structure, no
<lechner>wow, i see the [Owner] example in the manual. Smashing
<lechner>mirai / what about a boolean that decides about the presence of a line, like 'nocull' here?
<mirai>define-configuration accepts multiple "forms"
<mirai>you can decide that some specific fields should use a different serializer
<mirai>even if they are of the same type
<mirai>or you can make a custom type for it
<lechner>should the example at the bottom here be separated from the text for 'configuration->documentation' immediately above it?
<lechner>the maybe-* types get rid of so many conditionals!
<rekado>I’m still trying to find the right commit to actually build the honeycomb system without having to build so many things from source
<apteryx>did you authorize bordeau as a substitutes server?
<rekado>good point
<rekado>getting Guix onto these machines is really tedious
<apteryx>because of poor substitutes coverage?
<rekado>wasted a lot of time on the microsd card image initially
<rekado>and poor substitute coverage makes things harder as well
<lechner>thank you for all your hard work
<rekado>it’s in my best interest to finish soon; space on this coffee table is limited…
<apteryx>rekado: in other news, node 29 is offline, so whenever you feel like, you could take out the smallish SSDs from it, pack it with the bigger ones, and I could reinstall cleanly atop a new RAID 10 made of the 6x 8 TiB drives
<rekado>apteryx: uhm
<rekado>isn’t that a little soon?
<rekado>I’m currently using 3 of the 8TB drives for the honeycombs
<rekado>the other 3 are in node 29
<apteryx>oh, they're already running?
<apteryx>I thought you were still in the process of having their system installed on them
<rekado>yes, installing
<rekado>but I’d have to ride to the data centre for the third time this week to swap the disks yet again and start over
<rekado>could you install onto the 3 8TB drives first and add the other three later?
<rekado>the disk array can be extended, right?
<apteryx>yes, I can do that
<rekado>and I’d rather have nod 29 available in case something happens to
<apteryx>it's very inefficient but it can be done without downtime, so it doesn't matter much
<lechner>Hi, is it possible to pass options to a serializer in the defining stanza?
<apteryx>to be clear I don't intend to do this *now* but I'll try looking at it soon
<lechner>i guess it has to return a lambda
<apteryx>in the meantime we shouldn't reboot berlin in case it gets stuck
<rekado>apteryx: would node 29 be okay if you booted it again?
<rekado>or has the disk actually come loose?
<apteryx>no, it just won't boot, I sent a message to guix-sysadmins
<apteryx>the service fails
<rekado>oh, too bad :(
<apteryx>I'm a bit surprised that went down so quickly
<apteryx>I was expecting to be able to recover from that
<rekado>the disks were all firmly seated before I left
<rekado>a bit annoying that fiddling with the slots *above* them caused failure
<rekado>BTW: I duplicated the old SSD in kreuzberg to the 8TB disk; should that disk fail it should be enough to rip out the broken one and boot it again.
<Fare>I get a very unhelpful backtrace at the very end of an aa64 build: ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<Fare>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f
<rekado>please show more of the output
<Fare>in the backtrace, is the top of stack displayed first or last?
<apteryx>rekado: are you using Btrfs with compression on these 8 TB drives?
<Fare>maybe guix is unhappy about something wrt /boot and the bootloader, but it's hard to say what.
<lechner>mirai / Hi, you wrote "being: unset, present with some value, even if boolean" How do I unset a boolean, please?
<mirai>just leave it empty?
<lechner>it has a default value
<mirai>or set it as %unset-value
<lechner>mirai / thanks!
<lechner>mirai / does something like this make sense, please?
<lechner>it's inverted
<mirai>the serializer doesn't necessarily need be a gexp
<lechner>mirai / when does it?
<mirai>I've seen them return strings as well
<mirai>not too sure about it but if they require references to items in the store
<mirai>then you will want a gexp
<mirai>and you probably don't need the newline there
<lechner>mirai / so the example at the bottom here is just for show?
<mirai>take a look at serialize-configuration in gnu/services/configuration.scm
<mirai>you do need to, yes
<lechner>but i don't need the newline?
<mirai>as it's calling string-append, not string-join as I thought
<mirai>lechner: you need the newline
<lechner>but not the gexp?
<mirai>I think you don't need it here
<Luchadoritos>Hey Guix! I started using GDM again and I have some questions. For whatever reason everything is yellow, like very bright and almost impossible to see anything. I'm using the same config on another computer and no bugs. Is there an easy way to rebuild packages without removing gdm, gc'ing, then adding gdm again?
<lechner>mirai / i need whenever the string references a variable because it could refer to something in the store. is that right?
<lechner>Luchadoritos / that sounds like a problem with your video cable
<mirai>lechner: I'd say if you had a field that accepts a package for instance
<Luchadoritos>lechner: I can get into X just fine with no miscolorations. Does my HDMI hate gnome :(
<lechner>maybe those are our new release colors
<lechner>mirai / okay, thanks!
<Luchadoritos>There are no older package versions of GDM from what I can see. Using package transformations kept on getting errors too. I'll try to gc eventually maybe. Also one more question, how do I change some theming in GDM. I want to put a picture of my cat on the background :)
<mirai>Luchadoritos: what's the graphics card you're using
<Luchadoritos>Rtx 2060 Im pretty sure
<mirai>there were some recently open issues pertaining to gdm and nouveau in the past few days
<mirai>not sure what's the current state of it but you might want to check
<Luchadoritos>Ooh I see. I double check too, it is RTX 2060. Thanks for letting me know! Thankfully it's not a massive issue, hitting enter then typing password doesn't require seeing
<kaelyn>Hi #guix, I just wanted to mention that I got an i686-linux build of libreoffice to succeed by adding two configure flags, "--enable-lto" and "--without-galleries" :)
<kaelyn>(I also sent an email to the issue
<kaelyn>No problem! I wanted to help out with the final 1.4 release blocker, and stumbled upon that solution while looking at the Arch Linux PKGBUILD to try to figure out why Guix was having trouble building it
<unmatched-paren>rekado: ^
<apteryx>I guess --without-galleries is the single one needed?
<apteryx>lto may make it non-reproducible, I fear
<apteryx>ACTION braces for a reboot-based kernel bisect session
<kaelyn>--enable-lto is what got the build past the linking error
<kaelyn>--without-galleries was to fix an unrelated error updating the icon cache when 0 themes were found
<apteryx>did you try to use lld-as-ld-wrapper before that?
<kaelyn>apteryx: I hadn't, but unmatched-paren tried that yesterday and still got the non-virtual thunk error ( as a reminder)
<apteryx>ah, it's not an out of memory condition
<apteryx>I see
<unmatched-paren>apteryx: hmm, a cursory search does seem to suggest that lto makes things non-reproducible
<unmatched-paren> > Because of an open bug in GCC, using DISTRO_FEATURES:append = " lto" or adding -flto (Link Time Optimization) to CFLAGS makes the resulting binary non-reproducible, in that it depends on the full absolute build path to recipe-sysroot-native, so installing the Yocto Project in a different directory results in a different binary.
<apteryx>might not affect us when every file name is static
<apteryx>you'd have to build it again with --no-grafts --check
<apteryx>to see
<apteryx>oh, make sure to use -K if you'd like to use diffoscope on the eventual failed result
<kaelyn>rebuilding with "--no-grafts --check -K" now. Should know the results in about 20 min
<apteryx>ACTION reboots
<kaelyn>It will almost certainly fail due to, but hopefully that will be the only difference
<nckx>kaelyn: I think LTO made my machine OOM :-/
<nckx>However, it might not have been that at all, so 🤷
<unmatched-paren>kaelyn: > I think they become deterministic with -frandom-seed=0 for example.
<unmatched-paren>maybe try adding that flag?
<unmatched-paren>> The downside is that incremential linking (ld -r) does not work.
<unmatched-paren>But the random seed is used for other things in gcc too, so you may
<unmatched-paren>have other problems too.
<kaelyn>"/pre-inst-env guix build -s i686-linux --no-grafts --check -K libreoffice" finished, and the only difference reported is the known one in the bpmn.otg zip file.
<kaelyn>nckx: I'm not sure what the peak memory usage of the build is, but I'm also running it on a system with gobs of memory
<unmatched-paren>kaelyn: could we add a phase to reset the zip's timestamps?
<unmatched-paren>of course "we" generally speaking could, as it's obviously possible :)
<kaelyn>unmatched-paren: I was already thinking of doing that next, after finding the issue about the timestamps ;)
<nckx>kaelyn: I have only 4 GiB and it's in heavy use, so it's very likely to have been a me-problem. As long as it doesn't exceed the hard i686 limit—and it clearly didn't—that's fine.
<cwebber>who wants to test Terminal Phase on Guile using Guix tooling
<cwebber>it's just the first level but
<cwebber>if you wanna volunteer lnk
<rekado>ACTION is still building the deblobbed kernel *tarball*
<vagrantc>those tarballs take a painfully long time...
<nckx>Tarball takes longer than the kernel for me.
<nckx>cwebber: Test how?
<nckx>(That might be universal, I dunno. But I was horribly surprised.)
<vagrantc>it's even worse for armhf/arm64
<vagrantc>pretty much why i stopped even trying with armhf, really
<vagrantc>as even for the fast-ish arm*, they tend to have slower single-core speed
<vagrantc>and i think it's just a huge expensive call to awk or something, if i remember correctly
<nckx>There are multiple ‘backends’ (under-engineered this is not!), I know of sed & python, but maybe awk too.
<nckx>At that point, why not.
<nckx>Or maybe perl?
<vagrantc>a.k.a. fun for everyone! :)
<vagrantc>so now i have a booting kernel for the mnt/reform that might even be acceptible for guix ... but maybe i can figure out how to base it off the "regular" linux-libre package instead of off the arm64 defconfig
<kaelyn>unmatched-paren: I've discovered there's already a phase resetting zip timestamps that has a list of extensions, and I think it just needs "otg" added :)
<pkill9>oo nice
<cwebber>$ git clone -b guile
<cwebber>$ cd terminal-phase
<cwebber>$ ./ && ./configure && make
<cwebber>$ ./pre-inst-env scripts/terminal-phase
<cwebber>if it works, lmk
<cwebber>if it doesn't, also lmk
<cwebber>guix shell
<cwebber>after the cd
<nckx>Hmm, bootstrapping goblins, but OK…
<nckx>Oh it's a fork never you mind.
<nckx>Oops: In procedure open-file: No such file or directory: "/home/cwebber/devel/terminal-phase/assets/levels/level1.txt"
<vagrantc>ACTION ponders disabling the very very nice info pages for kernel building
<nckx>ACTION just cp'd it…
<vagrantc>so many cores, and sphinxbuild can't even use half of one
<nckx>ACTION dies.
<cwebber>nckx: try pulling again and re-configure
<cwebber>and see if it works this time
<cwebber>without modifications
<cwebber>woot, hope you had fun nckx, dead or not
<cwebber>the infrastructure of the main menu, announcing the player's death, etc not in there yet
<unmatched-paren>They martyred themselves for a worthy cause.
<vagrantc>#:build-doc? #f ... maybe
<nckx>IDGI: (string-join "/tmp/terminal-phase/assets/levels" "/" "level1.txt") → In procedure string-join: Wrong type argument in position 1: "/tmp/terminal-phase/assets/levels" wat
<nckx>ACTION didn't look at the code.
<nckx>cwebber: I'm always having fun, even when I'm not.
<vagrantc>ACTION fails to not buidl the docs, and goes back to waiting
<cwebber>wait huh
<nckx>I don't think I have weird state, but LMK if you want me to nuke the whole thing.
<cwebber>hold on
<cwebber>I'm confused, what's wrong with a string for string-join
<vagrantc>- (version>=? version "5.10"))
<vagrantc>+ (version>=? version "99.10"))
<vagrantc>never hurt anyone.
<nckx>That was my reaction.
<cwebber>it works here
<nckx>I'll nuke it just in case…
<nckx>Still happens.
<cwebber>that... *is* bizarre
<nckx>I'm waiting for the ob—oh.
<cwebber>okay git pull and re-configure ;)
<nckx>ACTION shoots. \o/
<civodul>vagrantc: do the Info pages take too long to build?
<civodul>ah yes, all sequential and Python and all that
<nckx>cwebber: Thanks for that sneek peek :)
<civodul>ACTION will have to try terminal-phase too!
<vagrantc>civodul: long enough to annoy me while just wanting to get a kernel booting, at least :)
<nckx>cwebber: Wow, I didn't notice that at all, either…
<nckx>I feel slightly less worse that ‘even’ you missed it.
<vagrantc>civodul: if it could be made a make job/thread built alongside all the other stuff, it would probably be fine.
<nckx>#:use-module (guix build fibers)
<cwebber>I miss lots of things ;)
<cwebber>ooh guix is using fibers for realsies now?
<nckx>Noo! Is was joke.
<lechner>Hi, when dealing with store items in a Gexp, is it better to use '(string-append ...)' on the host or '#$(file-append ...)' on the target, please?
<unmatched-paren>lechner: file-append
<nckx>I *did* use ‘&’ in a Nix build once, but I've paid my debt to society for that crime by now, I think.
<lechner>unmatched-paren / thanks!
<lechner>unmatched-paren / did i use the words 'host' and 'target' correctly?
<vagrantc>guix weather --system=aarch64-linux linux@6.0 ... ~"Sure, we have that ..." ... guix build --system=aarch64-linux linux@6.0 ... ~"downloading a bazillion substitutes ... and then some more, and some more ..."
<vagrantc>i don't know i will ever get used to this.
<nckx>vagrantc: Hmm? And what is the cause?
<unmatched-paren>lechner: those words are generally used for talking about cross-compilation
<vagrantc>clearly this isn't downloading from the substitute server that guix weather is on good terms with
<unmatched-paren>we say "build side" and... uh, something else. i can't remember what, sorry :(
<nckx>lechner: Guix terms would be ‘build side’ and ‘host side’.
<lechner>nckx / that's it. thank you!
<nckx>‘Host’ being ‘the user's Guix command’, basically.
<lechner>Hi, for PID files is it better to use the Shepherd or a daemon's own facility?
<vagrantc>there is no way to use host and target correctly, it's like X11 terminology for client/server.
<unmatched-paren>i actually find the x11 client/server terminology makes sense
<nckx>vagrantc: Agreed. Everything I've ever written that used the terms ended up confusing *even me* at some point deep in the code, and I'd written it.
<vagrantc>so downloading my linux-libre@6.0 ... did eventually download the substitute ... but why did it download the entire toolchain as if it was going to build it again? i guess i've never done any --system=aarch64-linux on this machine before?
<nckx>The usual cop-out is ‘…grafts, man…’ but it's also usually right.
<vagrantc>unmatched-paren: it's not impossible to make sense of it, but it's easy to get backwards.
<unmatched-paren>is it...?
<unmatched-paren>okay :)
<vagrantc>unmatched-paren: when doing thin-clients connecting to a server, and the thin-client is running the server and the server is running the clients? no confusion possible.
<unmatched-paren>what's a thin-client?
<florhizome[m]>Still waiting for someone to respond to my nemo/power-profiles-daemon and two more desktop services mails :(
<vagrantc>unmatched-paren: is my most familiarity
<lechner>Hi, will the Shepherd's 'make-kill-constructor' be able to locate the process to kill if the daemon detaches itself, or should i prevent detachment via the command line?
<vagrantc>unmatched-paren: although it's not even really thin clients anymore
<florhizome[m]>how am I ever get on to the cool stuff
<unmatched-paren>florhizome[m]: sorry! i promise, i'll take a look if i get a third voucher and obtain commit access...
<florhizome[m]>unmatched-paren you are the least responsible!
<vagrantc>unmatched-paren: in short, graphical terminals that connect to a powerful centralized server to run applications
<florhizome[m]>I was going to annoy you anyways :D
<unmatched-paren>vagrantc: i see...
<podiki[m]>was someone saying earlier that the infodocs for the kernel (new phase) takes a very long time?
<florhizome[m]>vagrantc are you a contributor-not-maintainer?
<unmatched-paren>vagrantc: i saw your name on; would you be able to vouch for me for commit access? i only need one more :)
<vagrantc>unmatched-paren: in such an environment, the X11 server is on the thin-client, and the X11 clients are running on the server
<unmatched-paren>gah, florhizome[m] beat me to it :)
<vagrantc>unmatched-paren: i'm not qualified to evaluate your work :/
<vagrantc>which is an awkward position
<unmatched-paren>vagrantc: well, okay, i'll wait for someone else, then :)
<florhizome[m]>civodul still here?
<unmatched-paren>i also sent voucher emails to julien and andrew tropin
<civodul>florhizome[m]: i think so
<unmatched-paren>s/emails/request emails/
<unmatched-paren>though i just noticed that the emails i sent to andrew and vagrant had empty subject lines, so they might have been missed or dismissed...
<florhizome[m]>maybe civodul can provide help to end this begging and restore dignity
<podiki[m]>any packages with patches depending on version? I've just done a (patches (if (version>=? version "5.10") (search-patches "somepatch") '()) and that seems fine to me but open to suggestions
<civodul>florhizome[m]: you're referring to unmatched-paren asking for commit access?
<civodul>seems like a good idea to me
<civodul>but i'm not a maintainer
<nckx>florhizome[m]: If you're begging you're doing it beyond wrong.
<civodul>yeah if you're looking for a 3rd voucher, i'm confident you can find one without "begging" :-)
<vagrantc>maybe targetted advertising?
<civodul>something like that :-)
<nckx>podiki[m]: Who sets version?
<ahriman>Hello guix, if I submit a patch adding a package and its dependencies do I make it all one single patch? or do I first send the package patch and then send each dependency as a separate patch to
<podiki[m]>to answer my own question: infodoc build phase for linux-libre does take a while, a substantial portion of kernel build time
<podiki[m]>nckx: in a procedure that defines a package (e.g. take some arguments for version and other needed bits)
<civodul>fun story: i was trying to understand why that redirect i set up didn't work
<civodul>turns out i had reconfigured the wrong server
<nckx>Ah. Sure. No, looks OK, I don't think that needs to be overcomplicated.
<civodul>(since the web site is currently on bayfront)
<nckx>podiki[m]: ☝
<podiki[m]>nckx: was just wondering if what I wrote was too hacky and I missed some better way to do that
<nckx>I think it's simple & clear.
<podiki[m]>nckx: thanks. usually I write something that seems easy enough to find out it was done and available elsehwhere anyway :)
<nckx>My only concern was that you might be expecting (package (inherit foo) (version "6.0")) to magically affect the source, but you've been around a bit too long to do so :)
<podiki[m]>ah. no didn't think of that, it is the reverse in this case, inheriting and then modifying source/patches :)
<podiki[m]>ugh I love making packages in guix, just so nice to do this programatically (is that a word?)
<podiki[m]>it is addictive I tells ya!
<nckx>Double m, but yes it is, and I agree. I can't go back to system that try to enforce ‘declarativity’ (is that a word?) through bloody YAML or whatever.
<singpolyma>I love declarative, but half the yaml systems out there have embedded shell and aren't declarative anyway :P
<podiki[m]>not to take us too off topic, but historically what were early efforts to do packaging and all that like this? is it only with nix that it got somewhere with the store and functional machinery?
<podiki[m]>perhaps civodul knows (or is in one of their papers?)
<nckx>If anyone knows the prior art… :)
<civodul>Nix was the first to really push it
<florhizome[m]><civodul> "but i'm not a maintainer" <- That’s actually good, we need vouches from committers-not-maintainers :)
<civodul>but before that there were somewhat similar efforts like GNU Stow
<civodul>well, "similar" in a broad sense
<podiki[m]>civodul: was it the development of the functional programming and store monad that really pushed it to something usable for the whole system?
<civodul>"store monad" is a Guix thing but NixOS already existed and all back then
<podiki[m]>oh, interesting. would have thought that would have been in nix too, but I don't know the internals there at all
<civodul>it's not called that way but in a way the Nix language is built around it
<civodul>it's implicit
<podiki[m]>(the math and programming loving part of me would have probably gone in a very different direction if I had learned about functional programming in school)
<unmatched-paren>civodul: oh, since you're not a maintainer, but you are a committer... isn't that even better? since maintainers are the ones who are going to be evaluating the vouches...
<podiki[m]>neat. maybe that Haskell book on my desk needs to be opened again :)
<civodul>unmatched-paren: true!
<vagrantc>unmatched-paren: people who've already worked with you (presuming i have the right pairing of irc nick and email): git log | grep Signed-off-by | sort -u
<vagrantc>ACTION calls "not it" and runs off
<lechner>Hi, i am trying to write my first service (for cachefilesd, Is this is going in the right direction? Thanks!
<unmatched-paren>vagrantc: thanks for the tip :)
<podiki[m]>yes that's a nice one liner
<vagrantc>should i push the mnt/reform patches to a wip branch or something?
<vagrantc>i've never had clarity on what's acceptible for wip branches...
<twopubsolar[m]>is there a reason that guix shell does not set LANG?
<rekado>speaking of prior art: GoboLinux was the first distro I know of that worked around the FHS with symbolic links
<twopubsolar[m]>to host lang ot C.UTF-8 or something
<twopubsolar[m]>it's just not set
<twopubsolar[m]>and causes errors
<unmatched-paren>twopubsolar[m]: because it's a completely reproducible, isolated environment
<twopubsolar[m]>*or C.UTF-8
<unmatched-paren>use -E LANG to use the outer env's LANG
<twopubsolar[m]>i know, i did --preserve=LANG and it built
<twopubsolar[m]>many programs just break when you don't have a LANG ending in .UTF-8
<nckx>Not a single programme has broken for me because of a ‘missing’ LANG, ever.
<nckx>Some ‘break’ when DISPLAY's not set. Hence, -E.
<podiki[m]>rekado: never heard of gogolinux, but yes very interesting what they do
<nckx>Oh, I'd forgot about them!
<twopubsolar[m]>no, actually C.UTF-8 doessn't work there too
<nckx>C.utf8 is a very recent thing. I'd still expect it to work, but that could be related.
<twopubsolar[m]>nckx: tons of them get file errors because they can't load a path with ???? instead of normal chars
<vagrantc>i thought the glibc with C.UTF-8 (or however you spell it) is only on core-updates
<nckx>Both are accepted. .utf8 is a bit more encouraged than .UTF-8, but they are exactly the same thing.
<nckx>I thought it had landed but I'm sure of nothing now.
<vagrantc>glibc 2.35 ...
<vagrantc>i am eagrely awaiting as i prefer to use C.UTF-8 on my debian machines, which causes issues when i ssh to a guix machine that doesn't support it
<nckx>ACTION checks out the fancy new package browser.
<twopubsolar[m]>yeah that's it! i have 2.36 on the debin apt and 2.33 in guix.
<nckx>…2 minor versions behind, even.
<nckx>2.33 is the newest.
<lechner>vagrantc / Hi, why is C.UTF-8 superior to en_US.UTF-8 again? I gradually switched to the latter on all my systems over the years
<twopubsolar[m]>could we get C.utf8 by default when we get a nethe libc?
<vagrantc>i think it's not supported as an "always there" locale even in newer glibc
<twopubsolar[m]>lechner: doesn't imply the user is american. and i guess it doesn't use imperial system?
<vagrantc>lechner: i prefer the time format default and that it's always present on debian ...
<twopubsolar[m]>s/a/the/, s/nethe/new/
<vagrantc>lechner: mostly the latter, but actually getting more annoyed by the former
<vagrantc>namely a 24-hour clock rather than 12-hour with AM or PM to make timezone math extra confusing
<vagrantc>other than that, i'm not terribly picky :)
<nckx>ACTION recommends en_IE.utf8 for those seeking English-but-with-sane-units.
<vagrantc>too many sane units could be difficult
<nckx>(The currency is eurocentric but I've never used software that uses that bit.)
<nckx>twopubsolar[m]: I think it makes sense as an upgrade from C, and it's technically doable. I'm less convinced that a variable that (significantly) changes based on whatever glibc version is present will be well-received.
<nckx>If it causes issues (and on most systems it won't), you can set it in .bashrc already [pending the glibc bump].
<nckx>* ‘it’ = ‘C’ proper.
<nckx>* second ‘it’ = ‘C.utf8‘ christ I'm a lucid writer.
<kaelyn>Finally back at my computer. `./pre-inst-env guix build -s i686-linux --rounds=2 libreoffice` was successful! \o/
<vagrantc>python 3 tends to traceback when doing things in a non-UTF-8 locale
<nckx>kaelyn: Nice.
<nckx>vagrantc: Big yikes.
<unmatched-paren>kaelyn: woot! last release blocker removed, i guess :)
<civodul>kaelyn: woow, yay!
<vagrantc>i think the guix daemon by default runs on en_US.UTF-8 ?
<nckx>Why would LTO cause irreproducibility anyway? PGO, sure, I get that.
<vagrantc>potentially linking things in a different order?
<nckx>Yes, but why.
<nckx>Why would LTO affect that.
<nckx>You can do traditional linking poorl^Wnon-deterministically, but just, don't.
<vagrantc>i'm with you there
<nckx>Is there something new/unique about LTO?
<nckx>I don't know!
<vagrantc>i said i'm with you!
<nckx>I said I don't know!!
<vagrantc>i suppose i should know, given some of the hats i wear...
<kaelyn>So with a few minor changes, libreoffice can be built reproducibly for i686-linux
<kaelyn>(at least on the same GuixSD host :)
<vagrantc>kaelyn: were you able to unreproducibly build it on the same host before?
<nckx>kaelyn: Can you share the final package?
<kaelyn>vagrantc: there is/was about libreoffice not being reproducible
<nckx>And the hash.
<vagrantc>kaelyn: but did you do a build with --rounds=2 before your changes?
<kaelyn>nckx: /gnu/store/xhjram1dq5jh7v52cmdnwkf9hz64jmcd-libreoffice- for the libreoffice with the diffs from and applied
<nckx>My bad, I meant the output hash. ‘guix hash -r /gnu/store/xhjram1dq5jh7v52cmdnwkf9hz64jmcd-libreoffice-’. The store hash is based only on inputs, not output.
<kaelyn>vagrantc: for the build fix, I did a --check after the initial success and verified via diffoscope that the only difference was the zip timestamp issue
<nckx>kaelyn: Thanks. On top of which Guix commit?
<nckx>If I'm going to build LO I want to get it right the first time :)
<vagrantc>the number of times i've tried fixing something, only to find my build environment didn't actually trigger the issue (consistently)
<kaelyn>nckx: sorry about that! pkg hash is 152qpsxjgwdxqnfqnzxfdi32kwnbxnkwgda61sjm69gj671d8rpy and based on guix commit 8f3e10ae819aabbe8216bfee6cd3e7857bc27293
<nckx>I'm always paranoid something will embed the weekday, or (more realistically) the year…
<twopubsolar[m]>thank you
<twopubsolar[m]>but containers don't read .bashrc?
<nckx>twopubsolar[m]: Good point.
<nckx>I was thinking only of --pure.
<vagrantc>i've sometimes changed date stamps to include seconds when testing date variations ... to make it easier to be sure.
<nckx>kaelyn: Since you mention having the error messages: could you add a (short is fine) comment to the configure options, explaining why we need them? ‘--enable-foo’ is obviously ‘we like foo’, but these 2 are not self-explanatory.
<vagrantc>ACTION pushes wip-mnt-reform
<nckx>Frustratingly, I can't get xhjram1dq5jh7v52cmdnwkf9hz64jmcd-libreoffice-, with or without grafts.
<nckx>ACTION gets y2jydm8l05k403dqk1zg9valmfq93zqx-libreoffice-
<nckx>Well, I'll build it anyway, maybe the output hash will match and we can pretend nobody noticed.