IRC channel logs

<podiki[m]>mekeor: might not be libgcc, might be something else in the dependency chain? i might look via strace or something similar to see what it is trying to load and fails

<civodul>andreas-e: hi! yes you can, it's a cache

<civodul>it shouldn't be necessary though

<civodul>(i never do that)

<civodul>apteryx: nice, thanks!

<civodul>mekeor[m]: hi! what if you keep "gcc-toolchain" but remove "gcc"?

<civodul>found an "interesting" Fibers issue: https://github.com/wingo/fibers/issues/80

<andreas-e>civodul: Well, / has only 15GB, and cuirass stops building when there are less than 5GB in /tmp. With one build taking 4GB, a second one would not be started. And this cache has about 0.4GB and starts to make a difference.

<civodul>andreas-e: it's 400M on berlin?

<andreas-e>No, on the powerpc64le virtual machine.

<civodul>hmm ok

<andreas-e>Maybe we can get more space in /, or move some from /gnu to /.

<civodul>we're not gonna remove it manually every day/week though, are we? :-)

<civodul>dunno

<andreas-e>How fast does it grow?

<andreas-e>It is only 270MB on berlin.

<civodul>165M on my laptop

<civodul>it grows as a function of substitute queries

<civodul>cuirass-remote-worker fetches prerequisites via substitutes

<civodul>so every time it has to build something, it asks for substitutes

<civodul>i guess that can add up more quickly than in "normal use"

<civodul>currently 'guix substitute' removes expired entries from /var/guix/substitute once per week

<civodul>see %narinfo-expired-cache-entry-removal-delay

<andreas-e>Okay. The systemd journal cache was worse, about 1.5GB.

<civodul>ah, see? :-)

<andreas-e>And we should do "guix gc"; with Guix on a foreign distro we do not have the mcron service ready.

<andreas-e>I just limited the systemd journal cache to 100MB.

<mekeor[m]>civodul: does not help :)

<cbaines>ooh, yay, someone else is having the backtrace problem https://github.com/wingo/fibers/issues/76

<mekeor[m]>podiki: here's the strace. it's weird that it looks for libgcc...so in glibc-for-fhs: https://paste.rs/3f0

<mekeor[m]>anyway. i'll try to package this tomorrow :)

<civodul>cbaines: eh :-)

<sughosha>Hi all, how to include 32 bit version of glibc as native input?

<sughosha>A package needs stubs-32.h.

<wdkrnls>Dear Guix, is there a way to add /usr/bin/env into a guix shell call without making a system level change?

<wdkrnls>e.g. on a foreign distro

<mitchell>do you mean in a container?

<mitchell>you could give --emulate-fhs a try

<podiki[m]>mekeor: it will look everywhere for it that it knows to look; do you see a libgcc though?

<zacchae[m]>guix home sets XDG_CONFIG_DIRS to include ~/.guix-home/profile/etc/xdg, even if that folder does not exist. This is causing phosh to crash. Is this a bug with guix home or phosh?

<podiki[m]>mekeor: you need the gcc:lib output

<wdkrnls>mitchell: I will use a container. Thanks, I had forgotten about --emulate-fhs.

<mitchell>Does anyone know how to send traffic to a guix container from the localhost?

<mitchell>or to the localhost from the container?

<zacchae[m]>Actually, I take it back. XDG_CONFIG_DIRS pointing to a nonexistant directory may indeed be a bug in guix home, but it's not the real reason phosh is crashing

<mitchell>Of course as soon as i ask the question i find the answer https://guix.gnu.org/cookbook/en/html_node/Container-Networking.html

<sughosha>I am trying to package https://github.com/marzer/tomlplusplus. meson-build-system is using the meson version 0.60, but the package requires >=0.61. How can I make this package use the later version of meson?

<apteryx>#:meson meson-0.63

<apteryx>soon we'll be at 1.1 (that's on core-updates0

<apteryx>oh, perhaps the reason of my offloading woes: extent tree corruption detected\0\0\0014failed to trim

<apteryx>mirai: do you know how mcron behaves for honoring schedules across reboots?

<apteryx>does it simply reset its counters (I'd think this is what it does)

<apteryx>e.g, if I have the fstrim service enabled (every 2 weeks), but reboot every day or two, it'd never run?

<apteryx>hm, 'btrfs scrub' found nothing

<sughosha>apteryx: Thanks, that worked!

<sughosha>Is it possible to add one input of different cpu architecture? I am trying to package yabridge which requires stubs-32.h even for x86_64-linux system.

<podiki[m]>yes, take a look at wine or dxvk I think

<sughosha>podiki[m]: I went through dxvk. There it is possible to chose wine or wine64 as they both are seperately packaged. But in case of mine, glibc does not have seperate package for 32-bit. Now how can I add input of 32-bit version of glibc?

<podiki[m]>I think you can inherit a package and set in arguments #:system "i686-linux" for instance

<podiki[m]>we generally don't have separate 32/64bit packages, it depends what system something is built for, e.g. guix build <package> --system=i686-linux

<podiki[m]>the #:system argument is what is done in wine/dxvk if I remember, too

<podiki[m]>e.g. https://paste.debian.net/1277758/ this should work

<podiki[m]>e.g. dxvk: of fo

<podiki[m]>whoops

<podiki[m]> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wine.scm#n428

<sughosha>So should I build the same package twice, just like wine and wine64? Then it should be like yabridge32 and yabridge.

<podiki[m]>may need to, not sure what will be easier depending on the details

<podiki[m]>many packages have difference based on architecture, handled in one package definition though

<podiki[m]>whatever is easier to do I would say, to start

<sughosha>I wish there would be a way like ("glibc" ,glibc #:system i686-linux)

<sughosha>..in inputs.

<podiki[m]>you could write a short procedure to do that, shouldn't be difficult, just takes the package and system as argument and makes a package

<PurpleSym>apteryx: Did you figure out what to do about python-trio?

<sughosha>Is it possible to have same argument twice with different values?

<sughosha>Packaging yabridge, want to use #:system twice, once with "i686_linux" and then with "x86_64-linux"

<sughosha>Or is it possible to change system inside different phases?

<abrenon>hi guix

<sammm>hi - i want to re-ask a question: i've added a new channel to my ~/.config and `guix pull` works to update it. The issue is that `guix search/install` (i'm assuming other subcommands also) _only_ see the official channel _unless_ I run as root, then I can see packages from the additional channel. any ideas why this might be?

<sammm> ah, I had to run guix pull as root it seems... I really thought I had done that, /shrug

<abrenon>sammm: wait what ? that's really weird, you're not supposed to need root as long as you don't reconfigure your system

<abrenon>guix pull is supposed to be for your user, and enough for guix search / install / shell / … to find new packages

<abrenon>what system are you doing this from ?

<andreas-e>Hello guix, hello abrenon!

<efraim>sammm: what's the result of `which guix`?

<andreas-e>sammm, try to find out which Guix you are using. Normally it should be the one you pulled, but if the PATH is wrong, it could be the one from the system.

<andreas-e>Maybe do "hash guix" after pulling for the first time.

<user_oreloznog>Hello guix!

<rovanion>Ehlo!

<abrenon>o/ andreas-e

<abrenon>how are things going with ghc ? I haven't been of much use, but I'm glad you and zimoun seem to have devised a simpler path to bootstrap the compiler

<andreas-e>zimoun does the work, I have no idea about ghc ;-) I just look at red dots in the dashboard.

<andreas-e>The more I look at all these languages, the happier I am to program in C...

<abrenon>ohhh… ? : ( but Haskell is so fun ! ^^

<adamnr>Hi - sorry I was having connection issues yesterday

<adamnr>I'm trying to use guix shell --container --network --emulate-fhs but when I run a command in it sudo make .... I get the error sudo: /bin/sudo must be owned by uid 0 and have the setuid bit set, any ideas how to work around this?

<adamnr>efraim: I get the following error: sh: /run/setuid-programs/sudo: No such file or directory

<andreas-e>abrenon: Somehow the bootstrap difficulties of almost all other languages, or their dependency maze (python) do not really entice me to invest in them...

<andreas-e>And like with everything, it is a lot of habit. I feel so at ease in C.

<PurpleSym>What are the remaining issues with GHC? Just i686?

<andreas-e>Yes, the real issue is 8.10 and 9.2 getting stuck in their tests on i686.

<andreas-e>But they also do so on master; this is not blocking the core-updates merge. But of course it would be great to repair it!

<mirai>apteryx: mcron doesn't honor reboots

<mirai>it doesn't have “anacron” capabilities

<mirai>about the every 2 weeks part, I think it depends on what kind of time expression you're using

<mirai>best way to confirm this is to run a herd mcron schedule

<sammm>thanks andreas-e and efraim, which guix is same for both root/user (in .config), am on 1.4.0-5.286cdf0, i should mention, using guix system

<sammm>but as i said, seems ot be working now

<abrenon>sammm: if you ran guix pull as root, I'm still worried about the exact state of your setup

<andreas-e>This is okay, but one should also run guix pull as the normal user.

<sammm>i ran as both - anything I should check to confirm my setup?

<andreas-e>If "which guix" points to the right one, everything should be okay.

<adamnr>In guix shell does their need to be some kind of alias from an exposed: /run/setuid-programs/sudo to /bin/sudo - inside the shell with fhs they dont seem to be related

<sammm>guix points to a binary in ~/.config/guix/current/bin/...

<sammm>ah, yeah and that is a symlink to the store

<allana``>Hi #guix, seems that python-google-auth and python-google-auth-1 are broken at the current guix, and looks like it might be related to an issue with python-cryptography missing an x509 module. Could this be a security mitigation? Anyway, wish there was a way of knowing what channel revision I could go back to find a working version. Anyone know a way? Is there a way to see when python-google-auth was last built successfully by the CI

<allana``>server?

<AwesomeAdam54321>allana: The build farm last successfully built python-google-auth at commit c371555a4b46a5c9288f54753b0f158f9c4b8abc

<allana``>AwesomeAdam54321: Thanks! how did you determine that?

<AwesomeAdam54321>You can use the search bar of ci.guix.gnu.org

<allana``>:-)

<AwesomeAdam54321>Is anyone interested in the effort of unbundling IceCat's dependencies? Right now it's time-consuming to try and build icecat because of how much there is to unpack

<AwesomeAdam54321>The size of icecat would become much smaller if all of it's dependencies were unbundled and guix would be the first in such an ambitious task

<civodul> https://guix.gnu.org/en/blog/2023/dissecting-guix-part-3-g-expressions/ wo0t!

<civodul>unmatched-paren: ↑

<civodul>well done!

<apteryx>mirai: thanks

<apteryx>is there a trick to strace SSH when it's launched on-demand by shepherd (inetd-style) ?

<apteryx>I try getting the right PID in top or nethogs but it's not easy or robust

<bjc>if ssh is allocating a pty, you can use the ‘-t’ flag on ps to find the right one

<apteryx>PurpleSym: yes! I've just been battling weird offload GSSH errors which makes it very inefficient :-). I just found a merge error with fonttools, I think it'll cure most of the other failures I was seeing.

<apteryx>the trio change looks like: https://paste.debian.net/1277793/

<apteryx>AwesomeAdam54321: most of it is rust nowadays I reckon

<apteryx>but the C/C++ libraries are the low hanging fruits which probably could be unbundled (I think Nix does better than us in this regard for their firefox package)

<andreas-e>apteryx: Do you think you could do the master to core-updates merge now? Otherwise I would try, but I am certainly less confident in myself than in you to get it right... There are merge conflicts in python-xyz, samba and gnutls.

<PurpleSym>apteryx: Ah, okay. Since you're not touching python-trio itself, python-anyio is still broken then?

<efraim>I thought we were downgrading python-trio to 0.21

<efraim>civodul: (I'm poking you since I don't have access to the berlin web interface) I'm still waiting on a bunch of aarch64 builds for the rust-team branch, most notably https://ci.guix.gnu.org/build/877005/details

<efraim>grunwald and overdrive1 look like they are ready to build more but my builds never get queued up

<andreas-e>efraim: rust comes after master and core-updates in priority. I think that the aarch64 machines do not look completely busy is an artefact of the visualisation.

<andreas-e>If you look at the completely red dashboard for aarch64 on core-updates, it follows that rust will have to wait - we will also have to restart a number of failed builds.

<andreas-e>When I look into the logs of berlin, I see that a build job is started and fails about every half a minute on overdrive1; some rust package from one of the other branches. I think they fail so fast that they never show up on the ci workers page.

<rekado>the rust-team branch has been ready for quite some time

<rekado>it’s very unfortunate to see it delayed even longer

<andreas-e>The plan was to merge staging and core-updates first and then to start with feature branches. I think we cannot cope with a potential fallout of rust updates that will make it to core-updates now.

<andreas-e>When we say that core-updates is frozen, it is a white lie: Whatever people commit to master, we will have to cope with in core-updates as well.

<andreas-e>If the branch is ready and core-updates compatible, it can be built out and merged shortly after the core-updates merge.

<pjals_>Does anyone know how to use 10-bit x265 instead of the "normal" one in the ffmpeg package? It seems like 'build-10-bit and 'build-12-bit phases exist, but I don't know how to use them. (would be more convenient as an output)

<pjals_>Oh god, they are seperate .so files. How will I make Guix use a different .so file for x265???

<civodul>efraim: no idea why this build isn't picked up; i clicked "Restart" but it doesn't seem to have an effect

<civodul>andreas-e: that's in cuirass-remote-worker.log, that overdrive1 issue?

<Guest15>Hello, I want to install specific manifests via my guix configuration.scm. I looked in guix/profiles.scm but there doesn't seem to be a manifest->packages procedure. Does anyone know if this is possible in guix right now?

<pjals_>Is libx265_main10.so even a standard way to indicate that its the main10 version of the library?

<pjals_>Because I'm completely confused why there wouldn't be atleast an output on ffmpeg to use 10-bit x265...

<pjals_>Would anyone know how to swap out libx265.so for libx265_main10.so on the ffmpeg package?

<apteryx>andreas-e: I'll try to do so before noon here

<andreas-e>apteryx: Great, thanks!

<andreas-e>civodul: I do not think it is an issue, just a shortcoming of the web page https://ci.guix.gnu.org/workers , which is not real time. I have seen that builds are sent in cuirass-remote-server.log on berlin.

<civodul>Guest15: you can do something like (map manifest-entry-item (manifest-entries manifest))

<Guest15>civodul: i will try that, thank you

<janneke>crap, ubuntu 22.10 does not grok guix-home's authorized_keys symlink to the store

<janneke>and home-openssh-service-type does not take #f for authorized-keys

<janneke>how about adding #f to mean: leave .ssh/authorized_keys alone?

<apteryx>how to debug an SSH connection that gets closed all the time?

<apteryx>this is what the strace of my ssh session looks like after it's killed: https://paste.debian.net/1277823/

<apteryx>the message is: "Connection to localhost closed by remote host." and "Connection to localhost closed." (I connect to a reverse SSH tunnel maintained by autossh)

<apteryx>ah, perhaps it's the ServerAliveInterval I've set to 15 in my remote ~/.ssh/config (honored by autossh)

<apteryx>when the connection saturates perhaps the watchdog times out and reset the SSH tunnel

<apteryx>I'll try the following: set the autossh monitoring port to 0 (disabled) and relax openssh' ServerAliveInterval to 60 s with ServerAliveCountMax at 20 or something high.

<unmatched-paren>civodul: woo!

<unmatched-paren>(and a good afternoon, guix :))

<unmatched-paren>pjals_: you'd probably need to set some build flag that changes the cc flag -lx265 to -lx265_main10, if such a build flag exists

<pjals_>i didn't find one :)

<apteryx>that seems to have solved my SSH issues... phew!

<andreas-e>Good!

<andreas-e>I see strange failures on CI: "cannot build missing derivation ‘/gnu/store/s08gn4lsgy3cd78r56hihjf8jsbn1w7k-emacs-saveplace-pdf-view-1.0.4.drv’"

<andreas-e>As if the derivation had been garbage collected. But should it not be tagged as protected by cuirass?

<apteryx>that's a known issue I think

<apteryx>#54447

<jackhill>I wonder if it would be practicle to create a guix pack from a guix home configuration. I'm thinking in particular about using it to configure a docker image.

<civodul>jackhill: we could very much add a "guix home pack" command or similar

<unmatched-paren>pjals_: i guess you'll need to patch the package then

<andreas-e>apteryx: That's it!

<jackhill>civodul: cool. Yeah, the other question is "does it make sense to do so" or "am I holding guix home wrong". My current quest it to create images for unprivledged pods in kuberneties.

<civodul>jackhill: whether it makes sense, i have no idea :-) i don't use k8s

<podiki[m]>apteryx: do you still have some big python changes for core-updates?

<janneke>ACTION creates bug with patch to have home-openssh-service-type leave ~/.ssh/authorized_keys alone by default

<jackhill>civodul: hehe, well, me neither until now. I'm just trying to build an alternative to download random binaries from the internet :)

<civodul>that makes a lot of sense :-)

<apteryx>andreas-e: still building stuff... I'll keep you posted

<civodul>janneke: it's a feature! :-)

<roptat>hi guix!

<civodul>hey roptat! long time no see!

<devmsv>hi, whats is the best way to create a shepherd service thats starts a docker image?

<jackhill>andreas-e: in your recent vulkan bug survey, is there anything yet about the failing tests? e.g. https://ci.guix.gnu.org/build/936944/details ? I've seen something locally on master too, but it doesn't look like ci has tried that yet

<apteryx>podiki[m]: I do! the fonttools merge issue spot this morning means a rebuild of a many things

<andreas-e>jackhill: It was not me who made the survey, it was Kaelyn Takata. I do not know if they are on IRC.

<jackhill>andreas-e: ah, ok, sorry. In that case I'll look myself, and perpahs file a bug when I understand my build failure a little bit better

<efraim>rekado: https://ci.guix.gnu.org/build/877005/details rust-1.67 for aarch64 finally got registered!

<janneke>civodul: it's a feature?

<janneke>ACTION hopes their "solution" to this feature makes some sense

<janneke>;)

<andreas-e>efraim: Better yet, it "compiled" in only 15 minutes by being downloaded as a substitute, since apparently it was already there.

<civodul>janneke: i find it nice to have authorized keys managed declaratively; declarative known hosts would have been trickier: https://issues.guix.gnu.org/55912

<civodul>anyway, i'll look at the patch!

<Guest20>hi. i found out that there are packages you can use in a package definition but can't find nor install manually. e.g. qt5ct depends on "qttools-5" but if you do "guix search qttools-5" there are no results, there is only "qttools". why is that? and is this documented somewhere? i spent a good amount of time debugging why my custom package didn't

<Guest20>find qttools although i specified "qttools" in the propagated-inputs..

<janneke>civodul: me too, and i'm using it everywhere, except on ubuntu where the generated authorized_keys file does not work

<civodul>d'oh

<janneke>so my solution is to --only for ubuntu hosts-- set authorized_keys to #f

<janneke>yeah

<janneke>"solution" -- cough

<mfg[m]>How do i construct a valid package name out of a string?

<mfg[m]>i.e. i have a function that returns a package, but one of it's inputs names depends on one of the parameters

<mfg[m]>i thought string->symbol would be enough, but it apparently isn't

<podiki[m]>apteryx: re: python; ok! feel free to make a note here post any fixes, I'll see what else I can fix up after

<jpoiret>mfg[m]: string->symbol gives you a symbol, not a package

<jpoiret>you probably want specification->package

<mfg[m]>jpoiret: that's precisely what i was searching for, thank you :)

<jpoiret>mfg[m]: may I ask what you're using this for?

<jpoiret>ie what your function does

<andreas-e>Guest20: You need to distinguish between the variable name and the name that is used on the command line.

<andreas-e>Try this: "guix package -A qttools". It shows you two packages named qttools, one of version 5 and one of version 6.

<andreas-e>Apparently you needed 5, so you can do this: "guix edit qttools@5".

<andreas-e>That should open your editor on "(define-public qttools-5 ... (name "qttools")(version "5.15.5")...)"

<andreas-e>So the Guile variable to be used in a program (and a package definition is code) has the name qttools-5. On the command line, the content of the "name" field is used, which you can have followed by "@" and a version if there is ambiguity.

<andreas-e>Most often, variable name and the name field coincide; in such cases where we have several versions, we need different Scheme variable names for the same "name" field.

<mfg[m]>jpoiret: i'm trying to write a function that creates a package, this may not be the correct way to do that though. The packages share most of their definition but their target differs i.e. riscv64-elf arm-eabi and such

<jpoiret>mfg[m]: I don't really understand where you would want to convert a string to a package there is all

<jpoiret>specification->package is mostly here for convenience and for CLI scripts

<mfg[m]>otherwise i don't know how i would get the corresponding package

<Guest20>andreas-e:Thank you for the explanation! I will use this the next time I'm running into this situation.

<apteryx>is there a trick to purge cached substitute servers (udns-discovered) ?

<apteryx>'herd restart guix-daemon' appears to be one

<jpoiret>mfg[m]: wdym "how you would get the corresponding package"

<jpoiret>you can get the package from one of the (gnu packages xxxx) modules

<PotentialUser-74>Hey. Could anyone be so kind to try this package definition? For some reason it builds but it hangs on one test. Not sure how to debug this. It is for pixman@0.42

<PotentialUser-74> `https://paste.debian.net/1277845`

<lilyp>PotentialUser-74: you can try raising an error before check and then use `guix build -K` – assuming you know how to debug the pixman build itself once you get to the source directory

<PotentialUser-74>I'm afraid I don't know. I just tried with the -K which even if cancel leaves the fail directory. And I'm you messing around executing the `make check` rule.

<PotentialUser-74>I'm not familiar at all with pixman. I was just trying to package all the dependencies for Hyperland WM

<mfg[m]>jpoiret: i was just confused. I was too focussed on finding out how to use the target which is a string to get packages which contain exactly that string in their names automatically. Instead i just pass the correct ones as additional parameters now

<jpoiret>so you're using different packages per target?

<jpoiret>you could also match the target string and pass the right packages

<apteryx>note: the GSSH errors may have just been caused by the SSH pings not making it across a saturated SSH connection (I was using 'ServerAliveInterval 15')

<apteryx>if you have GSSH errors, check you ~/.ssh/config!

<mfg[m]>jpoiret: true, i will try that out

<jpoiret>mfg[m]: I would recommend using the (is-...?) predicates instead of matching the string raw

<jpoiret>sorry, target-...? in (guix utils)

<mfg[m]>how do these predicates work? What i'm precisely trying to do is: I want to add support for more architectures to mitchells zephyr channel. How do these predicates work? As i'm essentially creating cross toolchains, would they work for me?

<mfg[m]>Simply duplicating these packages, worked. So now i'm trying to simplify things

<efraim>yikes, llvm-13 on riscv64 on core-updates: collect2: fatal error: ld terminated with signal 7 [Bus error], core dumped

<apteryx>andreas-e: gnome now builds locally; is this an improvement or already achieved? :-)

<apteryx>PurpleSym: for anyio I see 3 failures; is this what you see?

<apteryx>err, python-trio

<PurpleSym>apteryx: Dunno about python-trio, but anyio fails, because it is incompatible with trio 0.22.

<apteryx>ah, updating anyio fixes it

<apteryx>hm, the build of python-trio passed for 2 times now

<alethkit>Is there anything special one needs to do in order to get KDE working as a desktop service?

<PurpleSym>apteryx: Really? I was under the impression *no* version of anyio supports trio 0.22.

<apteryx>wait a bit, I may be confused :-). python-trio failed once, then passed twice, without any updates

<apteryx>I haven't seen anyio passed yet, I think

<PurpleSym>Ah, okay, sorry didn’t mean to sound impatient.

<jpoiret>mfg[m]: yes!

<jpoiret>you can look at how we make cross toolchains in (gnu packages cross), there are a couple of target-specific things we do iirc

<mfg[m]>jpoiret: alright, i will check it out tomorrow, thanks for the pointers :)

<andreas-e>apteryx: I think gnome already built before... But it is nice to hear nevertheless.

<apteryx>I think because of the fonttools merge issue it doesn't currently, a near miss: https://ci.guix.gnu.org/build/1050108/details

<andreas-e>Maybe! But we were close.

<apteryx>OK, seems not much is missing for the branch to be in a great shape

<andreas-e>How about the merge from master to core-updates? I intended to do one every evening from now on, so that we are akways ready to merge core-updates to master. And we already misses yesterday.

<andreas-e>Yes, I think we are close as far as packages are concerned.

<andreas-e>Then it would be good if people could try to reconfigure their systems and profiles on the branch.

<jpoiret>we might need to test them now, bjc has experienced a lot of issues for example

<jpoiret>i couldn't reproduce the ./pre-inst-env issue though with a guix shell coming from the core-updates

<jpoiret>i'm really stuck on the zig problem

<jpoiret>it seems as though it's using its bundled glibc 2.34 to build the stage 3 compiler even though it's going to link against libraries using glibc 2.35

<andreas-e>zig is strange...

<apteryx>PurpleSym: python-anyio's test suite passes with its commit cdc88ef33dbca9c8744f1056cfb410bd4bc20bd8

<PurpleSym>But is that version of anyio stil API compatible? I read that they’re going to release version 4 soon-ish.

<PurpleSym>There’s also an open issue for this: https://github.com/agronholm/anyio/issues/508

<bjc>jpoiret: the glibc locale issue was fixed by civodul some hours ago, and i can confirm it works. the issue with ‘pre-inst-env’ doesn't show up when invoked by ‘guix shell -D guix -- ./pre-inst-env’, only when run without ‘guix shell’

<jpoiret>ah

<bjc>i'm confused why it's suddenly a problem, though. i've never needed to use ‘guix shell’ with pre-inst-env before

<bjc>ludo says it's libgit2 linking against an old libc, but i have no idea how that's even possible

<bjc>for one thing: my system has been reconfigured. all my packages are now running core-updates, and that includes libgit2. for another: doesn't libgit link with a specific path in /gnu/store, so it'll use whatever glibc it needs regardless of what's in my “system” configuration?

<apteryx>PurpleSym: let's see it has only 36 dependents

<jlicht>hey guix

<andreas-e>Hello!

<apteryx>PurpleSym: backward incompatible apparently

<apteryx>according to its authors

<civodul>bjc: yeah, when switching libc versions, you need to make sure everything's using the same libc

<civodul>if you have things built previously, you have to "make clean"

<civodul>likewise with ./configure caches and the likes

<bjc>i did, though. multiple times, before and after reboot since system reconfigure

<apteryx>PurpleSym: so your recommendation would be to keep trio at 0.20 and python-anyio at its latest release?

<bjc>civodul: is there an explanation somewhere for *how* libgit2 gets loaded into guile? since this only happens with ‘pre-inst-env’, i can only assume i have some object file or cache somewhere that's got a reference to the older glibc, but i can't figure it out

<bjc>i've delete. ~/.cache/guile, too, just to be sure

<bjc>s/delete\./deleted/

<civodul>bjc: Guile-Git dlopens libgit2.so

<civodul>but see my reply at https://issues.guix.gnu.org/62949 for details of how things can go wrong

<bjc>is there a way i can ask guile where it's loading guile-git from?

<civodul>yes, with (search-path %load-path "git.scm")

<bjc>i've read your replies, and it still isn't making sense to me. i'll try to distill it more simply. i have tested three separate combinations of invoking guix: 1) bare guix: ‘guix build foo’, 2) pre-inst-env guix: ‘pre-inst-env guix build foo’, and 3) shelled pre-inst-env: ‘guix shell --pure -D guix -- ./pre-inst-env guix build foo’

<bjc>why would 1 and 3 work but not 2?

<civodul>really, i recommend using "guix shell -C" and stop bothering :-)

<civodul>that way you can be sure that nothing will interfere

<civodul>and you get a consistent environment, with a single libc

<bjc>i would, but i've nerdsniped myself

<civodul>heh :-)

<bjc>git.scm is being loaded from "/run/current-system/profile/share/guile/site/3.0/git.scm" w/ pre-inst-env

<bjc>ah! but the non-pre-inst-env version uses a path directly in the store

<bjc>hmm. i wonder if there's a collision in here with propagated inputs

<apteryx>PurpleSym: hm, this seems like a dead-end; trio 0.20 fails many things too

<apteryx>I'll leave it at that for now

<bjc>i'm also confused as to how i even have an older glibc sitting around for use by packages after reconfiguring my system

<apteryx>if it's still in your store, it's 'sitting around' :-)

<bjc>well, yes, but how is it being brought into my system profile? how was it even built with the wrong version of glibc in the first place?

<bjc>is there a way to ask guix-daemon to delete a specific package from the store?

<ngz>bjc: guix gc -D /gnu/store/…

<bjc>thanks. i'll give that a go when i get home

<civodul>i'm looking at updating python-mypy to 0.981 (not the latest version) for https://github.com/pandas-dev/pandas-stubs/issues/296#issuecomment-1245527765

<civodul>it fixes a bug specifically with Python 3.10.7, the one we have in core-updates

<civodul>is this something people have been looking into?

<civodul>apteryx or PurpleSym maybe?

<civodul>ACTION pushes not 1, not 2, but 3 package fixes, wo0t!

<andreas-e>You are spoiling us!

<bjc>that reminds me: is there a correct way to set the system date when building particular packages? i've got two pending fixes for stuff that uses python's zip library that can't handle dates before 1980

<civodul>"warning: package gtk+@3.24.37 does not support i686-linux" oops!

<bjc>i've got my own code that fixes it, but it feels janky, and there are going to be more problems with this zip library lurking, so a common procedure would be useful

<bjc>(i asked this on the ml a few days ago, but haven't seen an answer)

<andreas-e>civodul: Was this not because of rust?

<civodul>looks like it, but i'm trying to find what pulls it

IRC channel logs

2023-04-19.log