<lispmacs[work]>hey all, I use gajim like 100 times a day and was wondering if anybody had notice that broken build bug I filed on it
<lispmacs[work]>i noticed we are quite a ways behind the lastest release number, maybe just the version needs to get updated?
<jackhill>f3n1x: not quite, you can still use pavucontrol and other pulseaudio clients as pipewire-pulse implements the API. What you need to do is make sure pipewire, pipewire-pulse, and a session manager like wireplumber are running.
<jackhill>I'm sure someone has a fany home service or something to do it, but you can also do it by hand. Just note that clients often cause the pulseaudio deamon to be automatically started, so make sure pipewire-pulse is running beofre then, so they'll have something to connect to
<jlicht>lispmacs[work]: I have a patch that makes gajim build; are you able to apply it locally to see if it fixes your issue?
<graemep>I was using the package search on the website to see if Guix has what I need (and I noticed that Post 11 - 15 are one minor version behind and missing a fix for CVE-2022-41862. Is this a concern or am I missing something?
<spiderbit>well my bug with suspend was still happening in kernel 5.15
<spiderbit>so in gnome suspend works outside with loginctl suspend or similar commands not or it works 1-2 times then next time crashes the system never enters fully suspend mode
<mvnx>I tried a manual install per https://guix.gnu.org/manual/en/html_node/Manual-Installation.html. My `uname -a` shows x86_64 but the very last step `guix system init` revealed the `grub-install` had `--target=i386-pc` for some reason. As such, "Installing for i386-pc platform" failed but with some warnings about "fat" filesystem not supporting embedding and will not proceed without blocklist. This i386 thing seems like the bigger issue of the two?
<mvnx>Hmm maybe detecting based on the way I partitioned
<bjc>every crate i update adds six more crates to update
<andreas-e>jpoiret: Very nice! I think ncdu is also my last package that is not available on core-updates.
<jlicht>reconfiguring my system to core-updates on the train, living on the edge :-)
<vhallac>Hello. If I want to start a service such as pulseaudio-x11 which uses DISPLAY; can you think of a way to make this into a shepherd service?
<vhallac>Or is there some magic in guix that helps me do it?
<jpoiret>andreas-e: I can't reproduce a test failure outside of the build environment though, so this might take a bit, esp. since building zig is quite long
<jpoiret>but yeah, ncdu was the reason for me as well :)
<andreas-e>It is not urgent, I do not use it normally, but needed it once.
<andreas-e>Apart from that, openjdk failed to build on ci. I have restarted it, hoping it was just a transient thing.
<andreas-e>It succeeded immediately! Just confusion then.
<minima>hi, 'avr-gcc -mmcu=atmega32u4 ...' fails for me with error 'avr-ld: cannot find crtatmega32u4.o: No such file or directory', anyone else experiencing this? what puzzles me is that i don't seem to see any recent changes in avr.scm and this used to work til recently
<mfg[m]>On my machine at home i'm running guix system. This feels way better than on a foreign distro, but being able to just install something from AUR when it's not available in guix or other channels is too convenient :D
<sammm>an aur -> guix package transformer would be cool
<minima>mfg[m]: yeah, i see; for me, the main hurdle is to come up with a decent custom kernel (plus a limited number of packages that i'd also need to customise, possibly a browser); other than those two things i'd be fine but i keep pushing that back as it'd take me some time
<mfg[m]>minima: why do you need a custom kernel? what other packages do you need to customize and with what customizations? maybe someone has done something similar already
<minima>mfg[m]: i'd need a custom kernel for some proprietary blobs i suppose (yeah, it's a shame); as for the other packages, i think it'd mostly be a browser, and yes, there's definitely some definition that i've seen laying around that i could take inspiration from
<minima>re why i'd need a custom (as in non-vanilla guix) browser, i think it's because for very few very specific pages i tend to switch to my distro browser
<jpoiret>i'll send them and then go talk a walk, and reconfigure later in the afternoon (with hopefully zig built on CI in the meantime, since I've removed the debugging apparatus I added to the phases and haven't rebuilt it yet)
<minima>mfg[m]: yeah, that's the channel that i was thinking of using (or possibly, taking inspiration from), thanks for mentioning that
<andreas-e>PurpleSym: Good luck! This looks difficult to debug.
<jpoiret>for more info, anyone know what the status of librt is in glibc 2.35? I had to remove -lrt from zig's default linker flags because neither gcc nor llvm can find librt, and sure enough we only have librt.so.1, not librt.so.
<andreas-e>firstname.lastname@example.org does build for me, even if it does not inherit the phases. I think it also built before your patch, so this is not so surprising.
<mirai>what does CMAKE_SYSTEM_PREFIX_PATH expand to under a build phase?
<podiki[m]>andreas-e: I emerged late last night having made it out of Python dependencies and updates. I got yubikey-manager updated and built, roughly 10 packages updated. But at least one results in 3k builds so I'm guessing we want to do post-c-u
<podiki[m]>I can submit the series later so people can take a look, mostly trivial with just a few tests/dependency checks too work around
<andreas-e>podiki[m]: Good news! But indeed let us wait till after the merge.
<andreas-e>You can indeed send it to the patches mailing list already.
<podiki[m]>I'll make a local branch for this also, to be ready for one of those shiney new feature branches soon
<podiki[m]>I haven't looked yesterday, but how's Python on c-u now? Looked like it was pretty decent before?
<podiki[m]>(I'll have to check if any of my patches fix anything on c-u without bringing in the big changes)
<andreas-e>I think it is okay now. But it depends on what you need. I got calibre and am happy :)
<podiki[m]>yubikey-manager I need for something but I can do that locally
<jpoiret>andreas-e: with -C you would need to bootstrap and reconfigure first
<bjc>i think there is a bug here somewhere, tbh. i can't reason why i suddenly need ‘guix shell’ when i never did before c-u
<andreas-e>So now the system and the user are updated. Maybe it would be a good idea to do a "make distclean ; ./bootstrap; ./configure --...; make". And then hopefully ./pre-inst-env will work again.
<bjc>but there are weirdly built guile modules sitting in /run/current-system that get picked up by ‘pre-inst-env’ that aren't used otherwise, and i don't know what's building them and why they're being built wrong
<andreas-e>Before that, I will reboot. Hope to be back soon :) Keep your fingers crossed.
<bjc>andreas-e: it will not work again. i have been down this path many times
<mirai>apteryx: was there some particular reason for docbook-xml to go straight from 5.0.1 to 5.1 ?
<mirai>instead of having a docbook-xml-5.0.1 package
<andreas-e>Interesting. Because that would mean that something more fundamental is broken. Once everything is on core-updates, there should not be any difference any more with a newly installed system.
<bjc>i'm honestly kind of frustrated that that ticket was closed. i'm hoping if it happens to other people there'll be some action on it
<andreas-e>This was difficult, but at the same time I did not upgrade with "guix pull". So I assume the user experience will be better once core-updates is merged.
<andreas-e>Maybe I should also just have "guix pull"-ed to the corresponding core-updates commit.
<andreas-e>Because now my "guix" command is still from master. That must be a weird combination.
<bjc>i don't know what the difference is between a git pull + rebuild and guix pull. the derivation guix pull calculates is a mystery to me
<bjc>i can't use ‘guix pull’ with core-updates, because i need patches that haven't landed yet
<bjc>the issue with pre-inst-env are rogue guile libraries in /run/current-system that are only used in the pre-inst-env environment. somehow, they're using out-of-date system libraries. i don't know how they're built, or how they end up in current-system
<andreas-e>But if we also do not upgrade icedove, then things should be fine?
<jpoiret>basically, icedove was lagging a bit behind icecat, so icecat was updated and a new var was added for the 102.9 sources of icecat, to be used by icedove. But then, when icedove was updated, the 102.9 version of icecat sources wasn't replaced
<jpoiret>which is weird, i would assume that it never could build this way
<jpoiret>bjc: alacritty? you mean the complete server distribution? :p
<andreas-e>I have updated my second user with "guix pull --commit=..." and "guix package -u".
<jpoiret>right, it also comes with a GPU-accelerated terminal
<andreas-e>It worked, but I still cannot log in to xfce4 using gdm with this second user, while the first one can. I get a black screen and need to reboot. Have you got any ideas which cache files I should delete?
<bjc>i was down to something like 2 packages to upgrade by mid-afternoon yesterday. now i have over 30
<jpoiret>mirai: probably some module import cycle again :)
<mirai>ngz: thought so since I didn't spot any googletest usage in the file
<ngz>mirai: when you have a malformed package definition, guix spits out some weird error messages.
<andreas-e>So now I could log in with my other user as well! It took unusually long. Maybe I was just too impatient before, or maybe I needed to delete the caches and it took a while to create them again.
<jpoiret>re: the icedove issue, 2d25ea429c359d14955ee44baeeb5778cc56cc7d didn't land in c-u somehow, could you look into that once you have the time?
<mirai>is (define-public docbook-xml docbook-xml-5.1) the right way to define a package name alias?
<andreas-e>I think it would be good if I "guix pull"-ed all my profiles.
<andreas-e>ci now builds a gcc on aarch64 that dates from March 5...
<reyman>yes i have this with classic guix pull then sudo guix system reconfigure on my .scm file
<reyman>yes this is master : branche : master commit : 5b545763ed9b8a3fade7f756d543819fc090953f
<jpoiret>damn, i guess this comes from staging then :(
<jpoiret>reyman: this is going to be broken for a bit, at least until the core-updates merge. In the meantime, you can use `guix time-machine --commit=<SHA> -- shell python-yubikey-manager` with an appropriate older guix commit to use it, or if you happen to use it a lot, create a new profile for it and install it there
<andreas-e>Is it something that people need for logging in? Or for external crypto applications such as Internet banking?
<bjc>yubikey is pretty important to people that have one. it's used for a tremendous amount of stuff
<tribals>One more question: it is possible to force system for which package would be built in code? Or, how to use `guix build --system=...` option from code?
<sughosha>Hi all, I am trying to package yabridge and am very close to complete it. However, one thing is remaining, making it build with a 32-bit bridge (here called as bitbridge), which needs only 32-bit glibc's headers in addition. That means, I need to have both 64-bit and 32-bit glibc as native-inputs. Is it possible to do so? I don't need anything else in 32-bit, only glibc.
<jpoiret>sughosha: you're probably going to use the old-style inputs
<podiki[m]>I'll have to catch up when I'm back at a computer, but nearly all the updates were for Python, it was something like a dirutils or fileutils something like that on Python; mostly leafs
<jpoiret>anything special causing a bunch of rebuilds?
<sughosha>jpoiret: I am trying that, is there any variable for system architecture so that I can use something like (let ((system "i686-linux")) ("glibc" ,glibc))?
<jpoiret>sughosha: you can use cross-libc from (gnu packages cross-base) if you only need libc
<sughosha>jpoiret: Oh, I think that's what I need. I will try this. Thanks!
<andreas-e>aarch looks terrible, even on master. It is half red. So luckily this will not prevent us from merging core-updates, but it does require work and love, independently.
<andreas-e>bjc: On my system where everything is core-updates now, I created a new git clone of guix, bootstrapped, configured and built. Now "./pre-inst-env guix package -u" works without complaining about a cryptographic function.
<andreas-e>Yes, everything. The root and my two user profiles and the system.
<bjc>hmm ok. i'm not able to use that, maybe there's some magic happening in the derivation guix pull runs
<jpoiret>i do want to get a riscv board at some point. But aarch64?
<bjc>i did a complete ‘git pull’ → ‘make distclean’ → ‘guix system reconfigure’ a few minutes ago, followed by a reboot, and i'm still getting that error
<andreas-e>Ah, well, I built master instead of core-updates. This should not make a difference for ./pre-inst-env. But it maybe explains my profile problems.
<bjc>i wish there were cheaper risc-v boards. every time i go to look at it, i get sticker shock. i think si-five's stuff is the cheapest for a desktop-equivalent system, and it's still way too much for me
<bdju>so when I try to skip the failing gajim build and do my upgrades I get an error about conflicting dconf versions. is there any way around this issue? is it related to the gajim thing?
<andreas-e>It is possible that the old gajim pulls in an old dconf version.
<bdju>been trying and failing to update my system for quite a few days now. usually skipping a package can do the trick but it seems like quite the mess lately. there's always another thing waiting to halt things
<bjc>things are tested individually. however, to avoid huge rebuilds, certain things are done in separate branches in git. for the last week or so, those branches are being brought into master, and that has caused a lot of issues
<Nuri>I want to install gnu guix on my computer. But somehow i can't prepare the usb installation correctly.
<bjc>hopefully things will be relatively normal again in a week or so, and future disruptions won't be this bad again since merge procedures are changing after this
<bdju>Nuri: if the last stable release is what's not working, try the "latest" image. often some bugs make it into the releases
<sughosha>How to use find-files without recursing subdirectories?
<jpoiret>sughosha: you'll need to use the raw procedures from guile. I think they're in (ice-9 ftw)
<jpoiret>the guile manual will tell you more about it
<jpoiret>Nuri: I've got no clue then, sorry. If the checksum of your iso is fine, then it might be related to your hardware, but i would say it's outside of my expertise
<Guest19>If I do guix shell -D -f file.scm I have a different cmake version as if I do guix install cmake. Shouldn't they be the same? I don't know why but the shell one isn't working. I want to run cmake --preset=gcc-release .. but it says unknown version field. I don't have this error by just doing guix install cmake
<sughosha>jpoiret: Thanks. I think scandir is the nearest for what I need. Is it possible to "grep" and "grep -v" the list of this?
<Nuri>jpoiret: Thank you for taking the time for me.
<jpoiret>Guest19: when specifying packages via the CLI, you by default get the latest version, but that doesn't mean the default package that's used is that one. You'd have to look at what the cmake variable points to in Guix
<Guest19>I did guix shell -D -f file.scm and ran cmake
<podiki[m]>jpoiret and andreas-e: I think it is python-filelock (not sure if anything else) that has ~3100 dependents; version bump needed if I remember for updating virtualenv, for fixing poetry, needed for yubiki-manager