<civodul>it was fine last week (9a5e1dc1f16f5f8c056e64f2077b035784003673)
<civodul>perhaps a problem with the 'staging' merge?
<mvnx>I've been in a legacy boot environment in QEMU so far. Now I'm trying to use grub-efi-bootloader. The only Guix-specific part of my question is during a manual install `guix system init /mnt/etc/config.scm /mnt` should my grub-efi-bootloader configuration target be /boot/efi or /mnt/boot/efi because my Grub is failing to install though it could possibly be my partitioning stuff as well.
<rekado>civodul: hmm, I don’t know. I’ll look into it tomorrow.
<rekado>ACTION fixed linphone-desktop on c-u, again
<rekado>civodul: this is good. Could you share your list of texlive packages, please?
<spacecadet[m]>I've got a kind of odd situation, I have two channels and need to reference a module from one in the other. Both are in my channels.scm, and when I use the repl the modules work fine, but when I run guix pull I get "no code for module", do I need to modify %default-channels somehow or am I missing something?
<civodul>rekado: there are none, that's the weird thing
<civodul>i'm not supposed to get that profile hook
<lfam>Does anyone know off-hand how I can expand the swap partition created by the Guix installer?
<chipb>can you point me to your derivation? I'm curious.
<podiki[m]>lfam: just saw your openimageio fix as I was working on it (missed it, my fault!) is there a reason for 188.8.131.52 rather than latest 184.108.40.206?
<lfam>podiki[m]: No real reason. As I was working, I thought to myself "what's the smallest and easiest change that might work?" Like, I didn't want to have to start updating dependencies of openimageio
<lfam>But, feel free to update it again, as long as everything still works
<podiki[m]>i try for latest and then work backwards :-P
<bjc>lfam: was it you who said i should use ‘git format-patch --stdout’ for a patch series?
<bjc>how am i supposed to attach this to a ticket? it looks like an mbox file, but i don't see a mime-type for that, and ‘application/octet-stream’ isn't rendering well anywhere
<podiki[m]>lfam: my previous commit didn't format the invoke string properly (I included the same test twice instead of combining the string); what's the right commit message now, gnu: python-ecdsa: Fix faulty commit. with a message describing the formatting change in the 'check' phase?
<podiki[m]>(pushing, figure better to fix quickly, i'll receive my demerits later and any other fixes)
<lfam>bjc: Yes, it's the --stdout option, if you want to use it. You can attach it in any way you want. When downloaded, `git am` will apply it
<lfam>podiki[m]: I think it's nice to include a message saying which commit it is a followup to
<podiki[m]>alas, I pushed, modeled after a similar commit I saw. it was the very next one though
<lfam>There have been AI text generators for a while, it's been happening for a few years now. But the last year has been terrible
<podiki[m]>(i'm worried that package has nondeterministic tests sometimes, but every time I see a failure and rebuild it works. just did 10 rounds without issue)
<bjc>lfam: i was more curious in the right way to do this that'll make life easient for someone reviewing the patch. something that'll render properly in mumi would be good, for instance
<jpoiret>i will try running it, or rather, the base configuration of the installer
<andreas-e>rekado: Your fix for linphone makes us end up with two openldap packages with the same version, but which are not the same. This is confusing (it made me remove one of them when I updated the other one to the same version). Should it not have a different version, and preferably a smaller one, similarly to what we do with non-released git checkouts? Or if the version number becomes larger because it is a commit after the release, hide the package?
<andreas-e>But it also happens inside "guix -C -D guix".
<jpoiret>andreas-e: I know the origin of the error! Basically, our guile is compiled with the older glibc, so the newer gcrypt library can't load because it relies on glibc >= 2.34, but glibc 2.33 is already loaded
<jpoiret>i don't really know how autotools cope with updated dependencies
<andreas-e>I see. Now I remember that I deleted my guix checkout and created a new one before the gcrypt thing worked. (Which caused other problems, because I lost my git hook of signing all commits.)
<andreas-e>But "make distclean" also remove the guile binary.
<efraim>in that case I normally run 'git clean -dfx'
<andreas-e>That looks dangerous! I do have a complete untracked subdirectory with a TODO list and other stuff.
<efraim>I generally keep that outside of the repo and symlink it in
<efraim>I have a .exrc for vim stuff that lives in my home directory for each of the git worktrees
<jpoiret>clemens3: that's also what we do for architectures which don't have rust
<ngz>I'd like to push <https://issues.guix.gnu.org/62670>, but I'd like to understand its relative lint warning first: "#:tests? must not be explicitly set to #t". Do you have an idea of what I did wrong?
<andreas-e>jpoiret: So python-shiboken-2 is not ready to be pushed because of the obscure differences between python(-minimal), or did I misunderstand?
<jpoiret>no, python-shiboken-2 can be pushed i think, it's another failure of python-pyside-2
<ngz>jpoiret: I understand. I was misleaded by the "must not" and the fact that I mostly commit Emacs stuff, where tests are disabled by default. Thanks.
<clemens3>jpoiret: yeah, i wonder if the never ones are really necessary.. other projects should just boycott librsvg
<jpoiret>clemens3: it's hard to boycott a well-written library though. of course projects are going to depend on it
<andreas-e>ngz: There are so many texlive packages, it cannot only be po4a. Probably they are needed for the documentation of all kinds of other packages. After all, I countered over a hundred dependencies!
<clemens3>jpoiret: yeah, it is in the control of each project.. but in the end each user can also decide which project to use.. so better the projects make good choices first
<andreas-e>"counted", but indeed I think they should be countered! Freudian lapsus.
<clemens3>jpoiret: I think i needed librsvg for gimp.. as a user, i just stay with an old gimp..
<bjc>so hopefully ldd will give me some guidance on where these broken symbols are coming from
<jpoiret>can you confirm with the above test that it is the guile binary that causes this problem?
<bjc>In procedure gcry_md_open: Function not implemented
<jpoiret>did you `autoreconf -fiv .` then `./configure --...` anew before regenerating `guile`?
<bjc>yeah, i did a full rebuild starting from ‘./bootstrap’
<ordoflammae[m]><_jdb> "I am running Guix system in a..." <- I tried doing the same kind of thing, but I think the only real way to do this properly is to insert it into the fstab service manually, rather than go through the default `device` property.
<jpoiret>and you're using `guix shell -D guix` with the newer `guix` I presume? Sorry I'm asking these basic questions but just to make sure
<jpoiret>did you find out which glibc guile was linked against?
<_jdb>I guess I'm wondering if it makes sense to try and `stat` the 9p device given that it isn't actually represented by a file on the file system. Separately, I also wonder if `stat`ing relative paths makes sense at all because it introduces impurities based upon the directory you run `guix system reconfigure` in.
<_jdb>I'm pretty sure not every type of mount results in a `stat`, so I would propose adding `(type "9p")` to those exceptions.
<ordoflammae[m]>Yeah, but you'd have to add a new type. It's just an edge case that hasn't really been considered yet.
<ordoflammae[m]>It would definitely be useful to add a new type of file system that bypasses that check, or has a different check, but I'm not entirely sure where that check is handled. I found it a while back, but it's been a while since I figured that particular difficulty out.
<ordoflammae[m]>I think the stat happens whatever the type of the device is, though.
<graywolf>Hello :) I need to execute some shell code (well, one command) on system shutdown, *after* network is down; Would someone have a example how to achieve that? I'm not really sure, especially that part of doing something only on shutdown and after network is already down...
<bjc>graywolf: i don't think there is any way to do that right now
<_jdb>Yeah, I think a file system type that bypasses the check makes sense
<graywolf>bjc: Not happy to hear that but thanks anyway :/ Currently my system just hangs on every shutdown. It's not a deal breaker, but definitelly annoying.
<bjc>are you using nfs or some other networked file system?
<graywolf>No, shepherd is just waiting for kernel thread(process?) to stop (and it never does). The command I need to run is "modprobe -r mt7921e" to stop the `[mt76-tx phy0]' "process".
<graywolf>(it's driver for wifi, that is why I was asking for "after network is down" :/)
<bjc>i see. yeah, i don't think you'll be able to order that explicitly. afaik, the only hook for terminating things is ‘user-processes-service-type’, but that doesn't have an explicit ordering
<bjc>there are similar issues with network file system mounts, which is why i asked
<bjc>you may be able to hack around it, depending on how desperate you are. if you attach something that forks to ‘user-processes-service-type’, which can watch the network status, and then remove the kernel module
<graywolf>I see, interesting idea. Will try to give that a try.
<graywolf>I guess I'm not too desperate, since the "hold the power button" method for shutting the system down works, but for some reason it triggers me a bit
<ordoflammae[m]>_jdb: Anyway, while you are waiting for that to be implemented in guix, my code snippet should help work around the check without breaking anything.
<efraim>I suppose you could have a service which depends on networking with something like #~(lambda #t) for the start script and your shell script (with a small sleep) for the stop script
<efraim>oh, this is what I get for having joins/parts/quits hidden
<efraim>sneek: later tell graywolf For your 'modprobe -r mt7921e' on shutdown I suppose you could have a service which depends on networking with something like #~(lambda #t) for the start script and your shell script (with a small sleep) for the stop script
<andreas-e>rekado: Among the packages that fail all the time on core-updates, I see propeller-*; I have no idea what it is, except that it is a cross-compiler. So I wondered whether your gexp miracles could work there also, although I do not see anything fishy in the (hidden) propeller-gcc package.
<andreas-e>I see that disabling the test hides the problem. What options have we got for solving it? Would a bug with a stop-gap measure of doing a binary bootstrap be an option?
<civodul>until now we were arranging to have GTK+ & co. without Rust on i686 (as with the recent Samba fix)
<bjc>was there a graft for glibc 2.33 that bumped it to 2.34 at some point?
<bjc>i'm just started looking back into this pre-inst-env problem, and when i try (dynamic-link %libgit2) i get this: In procedure dlopen: file "/gnu/store/kmqzzvwm4a85jbrs4sb6h2frpxwgsr49-libgit2-1.3.2/lib/libgit2.so", message "/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6: version `GLIBC_2.34' not found (required by /gnu/store/kmqzzvwm4a85jbrs4sb6h2frpxwgsr49-libgit2-1.3.2/lib/libgit2.so)"
<bjc>that says that the glibc2.33 library is looking for GLIBC_2.34? why on earth would that be the case?
<jpoiret>bjc: no, rather libgit2 requires the GLIBC_2.34-specific features, which are also available in GLIBC_2.35
<bjc>but it's trying to load everything from a glibc2.33 store path
<bjc>interestingly enough, if i ldd that libgit2.so, it shows that it's linked against 2.35
<jpoiret>yes, that's because glibc-2.33 is loaded before by the main executable
<jpoiret>you can only load one glibc, so if glibc 2.33 is already loaded it won't try to load 2.35
<jpoiret>otherwise you'll be using dependencies from master instead
<bjc>i have not run that step. or, rather, i did a while ago, everything broke, and i had to rollback my system
<andreas-e>I did a "guix pull" for root to reconfigure the system and the root profile, and then for (each) user to reconfigure the user profile. I am a bit wary of a mixed system and user profile, although this should theoretically work.
<attila_lendvai>changing the network config in NetworkManager asks for my unix user's password. is there a way to avoid that? all i find is some polkit magic that looks like something the nm service should add, not me, the user.
<jpoiret>attila_lendvai: what login manager are you using?
<mvnx>From discussions here and mailing list IIRC only LUKS2 pbkdf2 works for encrypted root on Guix but with /boot unencrypted? That's fine enough. I see a few example system.scm's that supposedly work but none outline their disk partitioning. Can someone please point me to a working config and the `parted` commands that are required for it to work? I must have tried every permutation other than the one that works.
<bjc>nice, i only have one open bug left on core-updates and my whole system+home works 👍
<lfam>mvnx: If you don't get an answer here, try sending mail to <firstname.lastname@example.org>
<lfam>It will let Python people focus on Python, rather than having to become experts in everything
<mvnx>jpoiret: I'm okay with /boot unencrpted but I've tried different permutations of, in addition to / via mapped /dev/mapper/root, either separate /boot, separate /boot/efi (this one makes sense not to work if all of /boot needs to be unencrypted), separate /boot and /boot/efi, and even tried /boot and /efi per Arch docs, and variations of setting esp/boot flags on the partition so I was hoping to find more specific `parted` commands.
<podiki[m]>bjc: the plan is a separate feature branch just following core-updates merge
<podiki[m]>I'll get the patchset submitted soon, just been trying to clean it up and have hit other things to fix along the way
<civodul>jpoiret: i agree: adding C.UTF-8 to the installer makes little sense; C.UTF-8 should make sense though everytime we added en_US.utf8 and glibc-utf8-locales
<podiki[m]>it is not really core changes, just happens to hit updates of things that have many dependents, all to fix yubikey-manager
<ekaitz>is anyone having an issue with icecat saying you are in GMT? It's converting all my hours to -2 as I'm in CEST
<podiki[m]>we could throw in more changes, like updateing pytest (rebuilds a lot of python then)
<podiki[m]>I don't know the difference but I'm guessing a bunch of modules stripped out? which then have separate packages. i'm guessing
<lfam>I'm working on a major upgrade of Transmission, and they changed their build system so our patch about locales, which allows "GTK-specific localization", no longer applies. Does anyone know how I can test these features? Use a locale besides en_us at the system level and see if Transmission is appropriately translated?
<podiki[m]>our tooling has seen some nice improvements this past year or so
<jpoiret>Will the installer be able to get me a full GNOME install? find out soon
<mvnx>Presently with my setup after GRUB boot I get "you need to load the kernel first". I have separate /efi (fat32) and /boot (unencrypted ext4). It also already prompted me for my / LUKS password before GRUB.
<andreas-e>Indeed, mumi looks nice, I am eager for the next bug with patches ;-)
<andreas-e>bjc, podiki[m]: Maybe you could have a look at my one line change to python setuptools. It does not appear in the bug; I think I sent it to guix-devel.
<podiki[m]>python-pyflakes is failing now...didn't we have some fix/workaround before?
<andreas-e>It just tells the zip module (or whatever it is) to not worry about files in the past.
<jpoiret>for some reason the install image doesn't have the acl enabled by default... but they *are* in /etc/guix/acl
<andreas-e>podiki[m]: The last time pyflake occures in "git log" was June 2022.
<podiki[m]>andreas-e: hrm. vaguely remember something about it maybe from staging, but perhaps it was through another package. it has ~450 dependents. let me check if it really is failing now
<andreas-e>So probably not. By name it is allowed to be flaky...
<bjc>andreas-e: i haven't tried it yet, but that was exactly what i was going to start with
<bjc>it'll be at least an hour before i can get to it, though
<andreas-e>Well, there is no urgency! The bug wait for us until after the core-updates merge.
<andreas-e>ekaitz: I am not sure whether this is an icecat "issue", it has been like this forever. It is supposed to be an anti-fingerprinting measure. There is some setting you can change on one of these hidden pages (such as "about:"), but I have forgotten what it was.
<andreas-e>Maybe civodul remembers how to set the correct timezone in icecat.
<ekaitz>andreas-e: I have resistfingerprinting set to false :)
<ekaitz>i knew it was related somehow but I don't know why having it to false fails to report the proper date
<podiki[m]>nevermind on python-pyflakes, it builds (just not on e.g. aarch64)
<mvnx>The above paste has that "you need to load the kernel first". IIRC with just separate /boot marked with boot flag (and no separate /efi or /boot/efi) got me the "no suitable video mode" blind mode error. Not sure which is closer.
<apteryx>rekado: I managed to pxe-boot node 129; re-installing
<ekaitz>civodul: if you guide me a little bit on how to organize the code I can send a patch to the quotation issue we found
<zacchae[m]>jpoiret: Oh no! I'll fix it in later versions :)
<jpoiret>mvnx: first time i'm hearing about this error message
<jpoiret>mvnx: did you input the password properly?
<jpoiret>the GRUB LUKS password prompt is in qwerty
<mvnx>I did - only use English US standard qwerty setup. I can remove the heredoc key file and manually enter password when partitioning to confirm
<mvnx>Otherwise it would have just said incorrect password, right?
<jpoiret>not exactly. It would still show you the menu
<jpoiret>if it's a blue background for me I know it didn't unlock the LUKS partition
<apteryx>ekaitz: you need to disable resistFingerprinting
<lfam>Transmission changed from the glib-or-gtk build system to cmake. But we still need to wrap the 'gui' output, which is fine. However, I can't figure out how to use '#:glib-or-gtk-wrap-excluded-outputs' in cmake-build-system
<lfam>Are there any other keys that we sometimes "cherry pick" from one build system to another? I could use those a reference
<rekado>apteryx: oh, good! Do you know why it didn’t work before? (Did you do anything differently or has apparently something changed on the PXE server?)
<jpoiret>pretty weird that we don't include --sysconfdir=/etc in our sample ./configure invocation. It's more correct to also add it
<jpoiret>just got bitten by this + the fact that (current-guix) and hence the installer inherits those configuration options
<apteryx>rekado: it always fails on the 1st try, reboots, then succeeds
<apteryx>so the only way is to change it in BIOS Setup so that it sticks, rather than go through the web page
<unmatched-paren>rekado: git.elephly.net doesn't seem to be responding to web browsers or ``git clone''
<mvnx>jpoiret: When I removed the heredoc for password key file and instead typed it manually, and otherwise the same config and partitioning, my error switched from "missing kernel" to "error: no suitable video mode found Booting in blind mode"
<apteryx>rekado: seems to be booting... taking ages to symlink the kernel file to under /boot
<apteryx>in general when looking for process interactions via STDIN, you can search for open-pipe*
<apteryx>it's a very crude example though, but perhaps it is enough
<podiki[m]>andreas-e: personally works for me, for what that's worth :)
<podiki[m]>actually may be I can push a few more python patches before then, stuck on fixing poetry's tests in upgrading it, I think the patches up to this point are some additions and minor fixes, but getting poetry working would be i think useful
<podiki[m]>but we'll see if I still hit the big dependents
<efraim> I spent some time on poetry earlier, ended up hitting python-virtualenv and python-filelock but didn't try adding a new version of them
<podiki[m]>or rather I didn't upgrade but kept the latest version (from staging too?)
<jpoiret>andreas-e: I have some installer-related patches coming up, but they could also go on master afterwards
<jpoiret>one thing I'm worried about is substitutes availability on arches other than x86
<podiki[m]>efraim: also we weren't running tests before for poetry, so these may not be new failures
<efraim>I was trying to get past the sanity phase first before trying the tests
<efraim>I wonder if I should patch xdg-open in alacritty
<podiki[m]>haha I did that at first and now returning to the tests is also difficult :(
<podiki[m]>I think i'll just disable the 8 tests. i think one or two are trying to detect a shell (won't work in test env?) others i'm not sure if it is trying to download/write something but i haven't gotten anywyere
<rekado>apteryx: actually… I wonder if that node is connected to the right switch
<jpoiret>so there's probably no way to lower the issue processing time
<rekado>I’ll open the ticket anyway to confirm that the rules are identical.
<andreas-e>rekado, podiki[m]: Thanks for continuing to repair packages! Since all these are close to the leaves, they can as well go to the master branch. So even if they do not make it to core-updates before the merge, you can still apply them to master afterwards. However, there might be a short time where the package is not available on master, while it used to build up to now.
<apteryx>rekado: it used to work, a few months ago (December)
<andreas-e>Feel free to push packages with very few dependents on April 24.
<andreas-e>jpoiret: I do not feel competent on installer patches. I will let other people comment. In any case, it looks like they can go to master later.
<jpoiret>andreas-e: yes! I just wanted to get them out
<andreas-e>I am a bit worried about substitutes on aarch64; we have gone from 1 to 5 build machines again very recently, and there is a certain backlog.
<bienjensu>I'm trying to compile Godot 4.0.2 but scons keeps throwing an error about linux/errorno.h being missing despite having linux-libre-headers in the build inputs.
<jpoiret>apart from it being annoying, there's probably no rush to merge c-u.
<jpoiret>meaning that, while we have a single glibc in guix at any point in time (for now), we might have multiple libstdc++
<jpoiret>maybe it could be unbundled? I don't know how reliant gcc is on libstc++ internals
<podiki[m]>andreas-e: thanks in advance for the merge! I'm just getting these python patches in better shape but it will be for a new branch after the core-updates merge. bug number still forthcoming as I whittle down the last of the problems
<andreas-e>rekado: I do not know why you need to build scribus with gcc@10. One (complicated) option could be to compile with gcc@10 and to link with gcc@11 (I think the distribution is built with @11, but it contains @12 as a package).
<jpoiret>maybe it doesn't build with newer gcc, that would be fun
<apteryx>has someone ever had 'guix deploy' hang on 'guix deploy: sending 0 store items (0 MiB) to '220.127.116.11'...' ?
<apteryx>that's running from a remote machine to which I'm connected using SSH
<andreas-e>On aarch64 we are hitting the cuirass bug of removed derivations; as written earlier, we are trying to build packages from almosts three weeks ago, and I suppose many of the derivations have already been garbage collected.
<andreas-e>If they are still relevant for the current evaluation, they will automatically fail as well as all their dependents.
<bjc>is there any reason to not keep derivations for successful builds for months? is disk space too tight?
<andreas-e>The builds are part of the backlog, they have never been run.
<andreas-e>Would it help to run "./pre-inst-env guix weather" on berlin to create the derivations again?
<andreas-e>I have built single packages "by hand", but this cannot be done easily on a large scale.
<apteryx>bjc: yes; after the builds are done, the nars are cached to /var/cache and this is all that is needed for serving substitutes. Running a garbage collection daily avoids multi-hour garbage collection runs after a few months, keeps it constant and predictable.
<andreas-e>(If they are not relevant for the current evaluation, they will also fail, but we do not care; or rather, we are happy since they will fail quickly.)
<bjc>apteryx: ah, i see. thanks for the explanation
<rekado>andreas-e: it does not build with the default GCC
<rekado>there are a number of errors in the pdf plugins
<rekado>and this is C++ type soup, so I don’t see any obvious ways to fix them
<andreas-e>What I wonder is whether one could compile the .cpp files to .o with gcc@10 and then link with gcc@11. But I would not even know how to set this up in a Guix recipe.
<apteryx>strange, 'guix refresh' doesn't know about 2.x series of docker-compose
<RavenJoad>Can you increase the verbosity of the output when building a channel's derivation when performing 'guix pull'? I am getting an error on my channel related to a string-append, and I do not know which file is causing the problem.
<rekado>RavenJoad: you can build the derivation with “guix build”