<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.
<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
<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
<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!
<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
<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>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>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>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))
<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
<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 firstname.lastname@example.org
<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]>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>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
<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’
<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
<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>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>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 email@example.com 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)