IRC channel logs
2022-11-25.log
back to list of logs
<apteryx>jgart[m]: nice to know! I haven't read it yet myself. <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' <dec0d3r>I am trying to understand shepherd, so I can use it as an alternative to sysvinit and systemd <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>jjjjjxiiiej.i.bbhdpythggeutuixijuppig.kitipx <apteryx>apologies, I don't know what happened <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? <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! <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 ‘libz.so.XX’ 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>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. <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. <zamfofex>I’m glad I was able to help in some way. <zamfofex>Have you considered trying to use ‘guix shell -CF …’? <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 guix-patches@gnu.org address" but in the code they write "--to=guix-patches@debbugs.gnu.org" <PotentialUser-30>OK. So the cover to guix-patches@gnu.org and the manual is to be corrected? <PotentialUser-30>Enable video for nheko messanger / and therefor the tiny little gst-plugins-good-qt thingy (you remember you helped me) <unmatched-paren>ACTION notices that their package-features proposal would be quite helpfel here <unmatched-paren>PotentialUser-30: don't use etc/teams.scm here; there isn't really an appropriate team for this patchset <PotentialUser-30>OK. So first the email to guix-patches@gnu.org - waiting for the issue number and then --to=ISSUE_NUMBER@debbugs.gnu.org ?? <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." <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 <PotentialUser-30>But there's only --annotate and no -a switch. Strange. Anyway. I used the -a and we will see what happens :-) <jonsger>mirai_: do you know what exactly shepherd-requirement expect as a "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>(shepherd-requirement '(radicale)) works <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! <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: <https://logs.guix.gnu.org/2022-09-19.log#195243> <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>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 ci.guix.gnu.org today <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! <rekado>ACTION rebuilds libreoffice again… <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>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. <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>When in a wet paper bag: code. <yasht>nckx: Thanks. I'll try it out now <mirai>I might have missed some replies then <mirai>without resorting to wrapping the main program in a shell script or in this particular case, tweaking nginx itself <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 <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 46049@debbugs.gnu.org to comment." then <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>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? <nckx>As I suspected, you are whitelisted, and not otherwise blocked 🤔 <nckx>I did get it: lmtp(…tobias.gr)<1842><So8VK2HqfGMyBwAA0J78UA>: save: box=INBOX, msgid=<1d3856f6-8adb-7b1a-57c5-bb22533c202e …makinata.eu>, from=mirai <…makinata.eu>, 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>‘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>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 <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. <lechner>nckx / occasionally, I receive emails from debbugs (or from bug respondents) that include "guix-patches@debbugs.gnu.org" among the sender or recipients. Is "reply all" an appropriate action in those cases? <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 https://ns-global.zone/ <jonsger>lechner: that green (#00c627) is better then the #9f9 green, on my monitor with my eyes :) <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>You know where to send it 😉 <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 https://trends.debian.net/ <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: https://ci.guix.gnu.org/metrics 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>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! <nckx>lechner: I wouldn't have gone for the full-page background myself, but my god is <https://packages.guix.gnu.org/> 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…? <lechner>you have been having a lot of disk problems lately <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>perhaps there is elevator or HVAC equipment on the other side of the wall <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]>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 ? <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 <reyman>hum, so i need to create a package definition <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)) <reyman>i package a looooooot of crates to compile "deno", i hope this is the end of my suffering <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>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]>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 :) <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 crate.io, 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? <iska>lechner Idk, no experience <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 <guix-patches@gnu.org> <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 <lechner>iska / i'll walk you though it, or i can send the patch on your behalf (with you as committer) <jgart[m]>But you can just read that one liner and copy paste it into your terminal <jgart[m]>git send-email --to="guix-patches@gnu.org" -1 <reyman>hum, now seems the CLANG is not recognized and rust buid try to download " build_script_build::clang_download" <reyman>strange because i have (native-inputs (list ninja gn clang-toolchain clang)) <jgart[m]>unmatched-paren: why is the --base=auto required? <unmatched-paren>jgart[m]: not required, but it adds a little ``base-commit: ...'' to the bottom of the first message <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. <unmatched-paren>jgart[m]: i think you could also do ``--base=origin/master'' but i'm not sure <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]>unmatched-paren: do you use git worktrees when packaging? <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 <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? <oat>what is the difference an issue and bu? <apteryx>rekado: looks like we have yet another disk failure on node 129 <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) <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>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 <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>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 <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>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 <rekado>guix describe says it’s commit a0178d34f582b50e9bdbb0403943129ae5b560ff <civodul>yarl: hmm that looks good as well, i must be missing something <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/local.mk, 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]>They get together on Discord unfortunately <civodul>yarl: i see: there's a typo ("configuration" vs. "configuraton") <yarl>civodul: Thank you/sorry :(. <rekado>jgart[m]: Guile things are better discussed on #guile. <jgart[m]>rekado: but Guix is Guile and Guile is Guix... <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... <nckx>Then Guile would still not be part of Guix. <nckx>rekado: Just fmyi, have you tried anything more with LO? <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. <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 <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 <jgart[m]>lechner: That might be a #guile question <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 <mirai>lechner: its a #guix question <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>gnu/services/configuration.scm <mirai>the manual also covers about this <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 <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>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>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' <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 <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 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' <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 <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>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>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 <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>I’m currently using 3 of the 8TB drives for the honeycombs <apteryx>I thought you were still in the process of having their system installed on them <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? <rekado>and I’d rather have nod 29 available in case something happens to ci.guix.gnu.org <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 <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>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 <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>the serializer doesn't necessarily need be a gexp <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>and you probably don't need the newline there <mirai>take a look at serialize-configuration in gnu/services/configuration.scm <mirai>as it's calling string-append, not string-join as I thought <mirai>lechner: you need the newline <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 <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 <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 issues.guix.gnu.org <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>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 <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? <apteryx>ah, it's not an out of memory condition <unmatched-paren>apteryx: hmm, a cursory search does seem to suggest that lto makes things non-reproducible <unmatched-paren> https://docs.yoctoproject.org/test-manual/reproducible-builds.html > 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>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 <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. <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>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 <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>(That might be universal, I dunno. But I was horribly surprised.) <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. <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 :) <cwebber>$ ./bootstrap.sh && ./configure && make <cwebber>$ ./pre-inst-env scripts/terminal-phase <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 <vagrantc>so many cores, and sphinxbuild can't even use half of one <cwebber>nckx: try pulling again and re-configure <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 <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 <nckx>I don't think I have weird state, but LMK if you want me to nuke the whole thing. <cwebber>I'm confused, what's wrong with a string for string-join <nckx>I'll nuke it just in case… <nckx>I'm waiting for the ob—oh. <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>ooh guix is using fibers for realsies now? <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? <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 / 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’. <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. <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. <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. <florhizome[m]>Still waiting for someone to respond to my nemo/power-profiles-daemon and two more desktop services mails :( <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 <unmatched-paren>florhizome[m]: sorry! i promise, i'll take a look if i get a third voucher and obtain commit access... <vagrantc>unmatched-paren: in short, graphical terminals that connect to a powerful centralized server to run applications <podiki[m]>was someone saying earlier that the infodocs for the kernel (new phase) takes a very long time? <vagrantc>unmatched-paren: in such an environment, the X11 server is on the thin-client, and the X11 clients are running on the server <vagrantc>unmatched-paren: i'm not qualified to evaluate your work :/ <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? <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" :-) <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 NNN@debbugs.gnu.org? <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>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) <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?) <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… :) <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 <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 <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 :) <vagrantc>unmatched-paren: people who've already worked with you (presuming i have the right pairing of irc nick and email): git log --author=paren@disroot.org | grep Signed-off-by | sort -u <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... <rekado>speaking of prior art: GoboLinux was the first distro I know of that worked around the FHS with symbolic links <unmatched-paren>twopubsolar[m]: because it's a completely reproducible, isolated environment <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! <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>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. <nckx>…2 minor versions behind, even. <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 <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 ... <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. <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>* 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 <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>Why would LTO affect that. <nckx>You can do traditional linking poorl^Wnon-deterministically, but just, don't. <nckx>Is there something new/unique about LTO? <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? <vagrantc>kaelyn: but did you do a build with --rounds=2 before your changes? <nckx>My bad, I meant the output hash. ‘guix hash -r /gnu/store/xhjram1dq5jh7v52cmdnwkf9hz64jmcd-libreoffice-7.3.5.2’. 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… <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. <nckx>Frustratingly, I can't get xhjram1dq5jh7v52cmdnwkf9hz64jmcd-libreoffice-7.3.5.2, with or without grafts. <nckx>ACTION gets y2jydm8l05k403dqk1zg9valmfq93zqx-libreoffice-7.3.5.2 <nckx>Well, I'll build it anyway, maybe the output hash will match and we can pretend nobody noticed. 
