<jackhill>I kind of want to collect all these interesting things people do with thee programming APIs and add them to the cookbook. Over time, I think we might see oppertunities for some gernally useful higher-level APIs too
<darth-cheney>lfam: I got a little further. Noticed the grub boot settings for the usb stick include "modprobe.blacklist=radeon" but the installed grub didn't have it
<ryanprior>Totally with you on both points jackhill, happy to pair with you on it if that would be helpful
<darth-cheney>once I added that, I was able to successfully boot. But of course now there is no graphical capability...
<jackhill>ryanprior: +1 to paring. Dinner time for me now, but you can find me here and the @jackhill.us from the mailing lists
<apteryx>janneke: retrying now, it worked (herd start childhurd). Perhaps it needed some warmup ;-)
<apteryx>hmm, but restarting it leads to a similar problems (trying to start it 3 times in a row now, times out after 60 retries)
<apteryx>that was a problem with my config this time
<apteryx>janneke: ah, the net-options default value shown in the manual was not copy-pastable as-is; we should reformat it with string-append
<apteryx>also, by the default value of 127.0.0.1 means that it will listen only to localhost; dropping 127.0.0.1 as in "hostfwd=tcp::10022-:2222," would have it listen to any interface, which was useful for my use case (connecting to a remote childhurd via wireguard).
***iyzsong-- is now known as iyzsong-w
<apteryx>janneke: I've fixed the space issue in the snippet with ef63a4fa3b
<janneke>apteryx: ah great, thank you -- sorry for the trouble ;)
<apteryx>I'm still seeing very slow boot/warmup times for childhurd on a 2nd machine
<apteryx>it must try at least 3/4 times the 'herd start childhurd' for it to succeed
<tissevert>checked for guix weather ungoogled-chromium but not libreoffice because I'm not really using it, just have to have it installed because of the people I work with and no my guix system reconfigure is taking ages… noooo
<brendyyn>i put that stuff in my user profile instead
<brendyyn>if you just run it without -- meld, it will run a bash shell that you can play with and use exit to get out of
<brendyyn>like what happens with HOME=/tmp/test meld
<fnstudio>ok lol, this is... weird... very likely to be completely unrelated, but this is puzzling me, XAUTHORITY seems to be set to "/xauthority" within the guix env, despite the --preserve option, sending a pastebin in a sec
<fnstudio>brendyyn: i suppose so, although it comes with a gui (not sure diffoscope does?); i'm not that much into guis but i must admit that meld has saved my life in quite a few circumstances and i've grown some attachment to it
<apteryx>civodul: I've run 'make release' from a 'git clean -xfdd' checkout, and it './pre-inst-env guix pack guix' packed /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec instead of 1.3.0rc1 again :-/. The first commit bump (the one going to v1.3.0rc1) is there.
<apteryx>Seems like I'll have to put the workaround of deleting package-management.go before the guix pack command in the release target recipe
<apteryx>the process from a clean tree (git clean -xfdd) was that documented in doc/release.org, but where the correct tag 'v1.3.0rc1' was already present: guix environment guix --ad-hoc imagemagick perl; ./bootstrap && ./configure --localstatedir=/var --sysconfdir=/etc; autoreconf -f (out of paranoia); make release
<apteryx>I had that on berlin before, so it's not like something very special about my filesystem or the likes
<brendyyn>how can i capture the output of invoke, or should i use system*?
<apteryx>civodul: ah, it comes from the guix wrapper itself I think, the one under: /home/maxim/.config/guix/current/bin/guix: (set! %load-path (append (list (string-append "/gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union" [...]
<civodul>apteryx: ok, but how does that wrapper come into play when you run "make"?
<civodul>the wrapper does not set environment variables, right?
<apteryx>so when we use ./pre-inst-env guix pack guix as part of the release target, the guix wrapper from my PATH would get used and insert that /gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union prefixed path, correct?
<apteryx>there's no output else than /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec
<apteryx>but it's really the load paths which are wrong because I've moved that package-management.go out of the way now, and it still picks that one from /gnu/store/mnlzz2zhnn9y8xqla2p95xy7ghc45xsf-guix-module-union
<luis-felipe>Yeah, that part I think I understand: that it seems like a nightmare to make it work. But from a user point of view it still a bug, since Builder is advertised everywhere for Python development.
<civodul>apteryx: ah yes, you could add a dependency on scripts/guix for the 'release' target
<civodul>i always start by running "make" so i didn't notice
<brendyyn>gcc 11 has microarchitecture targets, which seems maybe something to incoperated, instead of customised cpu features. much simpler
<efraim>civodul: I'm building gcc-11 and gdc-11 ATM
<efraim>brendyyn: generally whoever wants to do the work and test stuff. with powerpc64le and the newer glibc we needed at least gcc-8 and I found that gcc-9 and gcc-10 caused more build failures than I was able to fix, while gcc-8 built fine to mesa
<brendyyn>makes sense, so its about not leaving other architectures behind, and bug hunting
<lfam>The command `guix refresh --list-dependent foo` is used to count the number of rebuilds to make decisions about this stuff, although it doesn't count dependencies of build systems. So there is an element of "you just have to know", which it would be great to reduce
<lfam>You can kind of count those rebuilds, if you know a package is used by a build system, by doing `git grep foo-build-system gnu/packages | wc -l`
<lfam>Changing the subject, should we merge the ungrafting branch into master, civodul? Did you test it on your end? It's working okay for me
<lfam>But, I don't use any desktop environments or window managers from Guix
<mjw>yeah, last time I tried updating something (elfutils, which contains libelf, although there is another libelf in guix, which some packages use) I got told it would need the whole world to be rebuild... :)
*vagrantc wonders about encoding something into "guix refresh" to recommend what branch a change should land in
<mjw>lfam, they aren't binary compatible (and might have a few small source incompatibilities, but those are really bugs)
<mjw>now guix doesn't care about binary compatibility (and here I was so proud of elfutils using symbol versioning and a stable so name for multiple decades...)
<lfam>Does `guix graph --type=reverse-package libelf | xdot -` to see how thousands of packages come to depend on this 'libelf'
<lfam>Oof, I wonder if we improve the layout chosen by the dot viewer
<mjw>It probably works, libelf is a funny "unix standard". It isn't really an official standard library, but everybody has an implementation anyway. We still coordinate new interface additions (with Solaris and BSD)
<lfam>It looks like the world of R comes to depend on this libelf, and that's a huge number of packages
<mjw>lfam, does that work for you btw? I get a errors
<mjw>TypeError: <window.DotWidget object at 0x7fce8b729300 (xdot+ui+window+DotWidget at 0x202c0f0)>: unknown signal name: draw
<lfam>It's "hidden", so it doesn't appear in the Guix UI
<lfam>Users will install the package defined below it, and we can update that one freely, without causing a huge number of rebuilds
<lfam>Over the years I have come to realize the value of coordination in a project like this. The most impactful thing you can do is motivate people to work on some task they wouldn't otherwise do
<lfam>I'm slowly trying to get better at it but it's easier said than done :)
<lfam>And also, when I said "Not to mention that it has to be coordinated with updates of other core packages, since they may depend on particular versions of each other", it would be great if core GNU packages coordinated among themselves too
<lfam>I think this could be something the Assembly might talk about
<lfam>Already, Guix has effectively "Tom Sawyer-ed" a distro. Packaging is really easy and maybe even addictive
<apteryx>jonsger: hi! I'll post something to guix-devel after the RC1 is out; we're currently building substitutes for all the archs (mainly for armhf-linux, but also powerpc64le). Assuming there are no more build problems, we should be good for RC1 soon (TM).
<lubrito>cbaines: Hi. by symbol null you mean 'null?
<PotentialUser-81>roptat: so I did that, but it seems like the etc-service-type is adding a "^J" to the end of the file, which is causing doas to error
<roptat>PotentialUser-81, I need to go, but others can help you. How did you specify the content of the file?
<lfam>However, the connection is unstable. Sometimes it stops displaying messages during boot, sometimes it reaches the login prompt but doesn't respond to my keystrokes. I'm using minicom from Debian stable
<lfam>Does anyone have any tips? I've worked at the serial console using screen to interact with a PC Engines APU2, and that works reliably. But it is less stable than minicom with the macchiatobin
<lfam>I'm asking in the vendor chat room but maybe somebody here has advice, too
<rekado_>gagbo[m]: if you feel like debugging this, please apply the guix-daemon.cil file (it’s part of a Guix source checkout), and then look at the SELinux audit logs to figure out what permissions might be missing.
<rekado_>gagbo[m]: note that messages relating to the daemon may appear as “(x-daemon)” in the SELinux logs, which is a little confusing.
<civodul>apteryx: i've tweaked release-manifest.scm on version-1.3.0
<civodul>with these changes, there's only one substitute left: guix on armhf
<civodul>it should take another 1-2h to become available
<lfam>I got past my USB serial console problem by disabling hardware flow control in minicom
<apteryx>civodul: is this the manifest used by distcheckÉ
<bluekeys>I'm currently using exwm. Is it possible to run emacs a service on guix? I'm used to always having emacs around, and autostarting on boot more or less. Also, would love if it could survive between leaving and restart x sessions when playing with various wms