<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'
<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?
<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.
<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 firstname.lastname@example.org address" but in the code they write "--email@example.com"
<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
<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?
<lechner>nckx / occasionally, I receive emails from debbugs (or from bug respondents) that include "firstname.lastname@example.org" among the sender or recipients. Is "reply all" an appropriate action in those cases?
<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>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
<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]>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
<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
<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>.
<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>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>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
<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
<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 :(
<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
<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>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
<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 :)
<lechner>unmatched-paren / did i use the words 'host' and 'target' correctly?
<vagrantc>guix weather --system=aarch64-linux email@example.com ... ~"Sure, we have that ..." ... guix build --system=aarch64-linux firstname.lastname@example.org ... ~"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: 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 email@example.com ... 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.
<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)
<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>(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].
<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.