IRC channel logs
2023-04-22.log
back to list of logs
<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? <spiderbit>so I still fight with bash and setting my terminal titles <spiderbit>It seems to me that bash does set that by default to something like user@host:CWD <spiderbit>with urxvt the title changes when I go to remote with ssh <spiderbit>but it should change with every CD and even start with user@localhost: <home-path> <spiderbit>can somebody tell me how their title is... is this the default behaviour <spiderbit>that window class is Xterm and title is xterm, and Urxvt - urxvt respectively <oriansj>spiderbit: there is no need for titles on one's terminal <bjc>it's handy for window manager integration <bjc>you can have rules set up to size, move, or jump to them, etc, based on titles <spiderbit>PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"' <spiderbit>but the question is how to get that in .bashrc <spiderbit>.bashrc -> /gnu/store/9xs7cw9gpb000b1dyaigv5a0x065vx4d-bashrc <spiderbit>I think it's managed by guix home-config or what's it called <f3n1x>jackhill: nice to know... i can see pipewire and wireplumber, but not pipewire-pulse package . What am i missing ? <spiderbit>does it ever make sense to call guix home import again <spiderbit>if the file is tracked by guix home it would be read only anyway right <lispmacs[work]>I'm getting an error "record ABI mismatch; recompilation needed" when I try to build a local guix checkout. how to deal with that? <spiderbit>export PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"' <Zambyte>f3n1x: pipewire-pulse is actually included with the pipewire package. <jackhill>f3n1x: pipewire-pulse is in the main pipewire package <jackhill>you'll have to rebuild every scheme file afterwards. Presumably you could get by with less, if you knew what records were involived, but seems safer to do it all <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 <bjc>rust spends all this time and energy creating this safe language, free of data races and memory corruption, and then just leaves the front door open with cargo <bjc>in any realistic sense, i don't think rust can be considered "safe" when it's this ripe for attack <bjc>i'm going to remember that <vagrantc>but payload is overloaded, for example, it is also used in malware delivery systems <bjc>there's a web server in alacritty somewhere <bjc>i've forgotten how i got down this path. somewhere in winit. toml, maybe? but i'm now packaging up a web server library for my terminal emulator <bjc>it was toml. the configuration file format parser. it has a web server library <bjc>(alacritty doesn't even read toml files) <spiderbit>anybody idea how you start gvfsd in a tiling-wm? <spiderbit>when I install gvfs as user I find no gvfsd or something similar in my path <podiki[m]>ChocolettePalette: did you try "xsetroot -cursor_name left_ptr" ? <podiki[m]>(not guix specific, should be same info you'll find in general) <ChocolettePalett>Ah, I've seen this advice too, but I thought it wasn't what I wanted. Though, it certainly is: after putting xsetroot into .xinitrc, cursor has changed to the desired theme. <ChocolettePalett>It didn't work with dwm & st windows for some reason though, but at least it works with all the other windows <podiki[m]>i don't know about those exactly, might be something else (gtk theme maybe) <sneek>Welcome back AwesomeAdam54321, you have 1 message! <sneek>AwesomeAdam54321, zacchae[m] says: Haha, no. I'm running PureOS + guix home <carmenshea[m]>AwesomeAdam54321: hi, just joined, trying to figure everything out <jpoiret>i figured out what was causing zig to crash, now i need to fix some tests <jpoiret>then i'll try reconfiguring with core-updates <carmenshea[m]>AwesomeAdam54321: Hmm, possible issue with the Ement.el client? <carmenshea[m]>AwesomeAdam54321: Is your user name fully showing now on my replies? <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 <minima>andreas-e: hey, thanks for checking! hm... it must be something wrong with my setup then /me thinking... <andreas-e>"guix pull" of April 11, then I did "guix shell avr-toolchain" and compiled a random small C file, which creates a statically linked a.out. <minima>hm, and you also used '-mmcu=atmega32u4', i guess <minima>oh wow... it does work for me too if run in a guix shell env... <minima>i do have avr-toolchain already in my guix home <minima>hm, i'm puzzled - but at least i have it working now, via guix shell <minima>thanks for helping with this andreas-e, you gave me a good hint with regard to guix shell <mfg[m]>minima: are you on a foreign distro? <minima>mfg[m]: yes i am (although i'd checked that the avr-... commands were being taken from the guix path) <sammm>what service would be the best to invoke a simple daemon? I was thinking of running it as a user service, but it requires root for certain operations... thank yo uin advance <mfg[m]>minima: yeah, i'm also on a foreign distro and i always run into things like you described; guix shell always is tho solution :D <minima>mfg[m]: ah, yeah, i should have thought of that! how are you finding it running on a foreign distro? i'm very happy with the setup but i'm still longing for migrating to pure guix asap :) <mfg[m]>Besides the occasional weird things that happen, it works pretty well. I have been running it since 2019. <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 <tribals>Could someone help me with setting up native builds on my x64 laptop? <mfg[m]>minima: then there actually is a third party channel, that you might want to use. They also have a channel on libera it's #nonguix. <andreas-e>Also happy to see you back; so your upgrade did not completely destroy your machine. <jpoiret>i haven't reconfigured on c-u yet :p <jpoiret>I hate how debugging these kinds of things ends up creating very innocuous patches. "Accoucher d'une souris" would be the correct description <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 <jpoiret>i still do not have committer rights :) <jpoiret>to clarify: I haven't applied for committer rights <andreas-e>I tried to compile both zigs at the same time, but one of them was killed due to memory, I suppose. <PurpleSym>Trying to figure out why GHC is failing on i686, I can now reproduce the issue with runtests.py using 100% CPU. <andreas-e>Should we not update zig-zls from 0.9.0 to 0.10.0 and then drop zig@0.9.1? <jpoiret>yes, zig requires ~6G of memory to build stage2 <jpoiret>andreas-e: maybe, I didn't think that far <jpoiret>oh no, it will probably not build then, i noticed it doesn't inherit its phases from zig-0.10 <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>zig@0.9.1 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? <mirai>are the substitute downloads performed with HTTP/2? <mirai>and are they pipelined/multiplexed? <mirai>andreas-e: can you share a hash/path for the kdoctools build you've fixed yesterday? <namcsi>I'm trying to flash the image to the emmc they sell alongside the unit <namcsi>I've never used u-boot so I'm a bit lost trying to figure out what's wrong, hoping somebody just has an image recipe that works out of the box:) <andreas-e>mirai: ./pre-inst-env guix build kdoctools -n <andreas-e> /gnu/store/lm747s3p09rkdid1xpgkp04ldkkybk3v-kdoctools-5.98.0 <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>podiki[m]: is there no way out of it? i also use yubikey-manager, it wouldn't be a deal breaker if it isn't there for a bit but it would be nice <andreas-e>You can always keep the previous version with "guix package --do-not-upgrade yubikey-manager -u ." <andreas-e>Now it is time to reconfigure, wish me luck! <jpoiret>good luck! I'll be following you there soon <jpoiret>will it fix all my tooltip bugs? stick around to find out! <bjc>the tooltip issues seem to be fixed in 1.8 <bjc>i've been on c-u for like a week, i think? <andreas-e>For the time being, I just reconfigured my user. <andreas-e>And get "(process:27576): Gtk-WARNING **: 17:35:59.811: Locale not supported by C library." <jpoiret>yeah, that's because you're not using the new locales yet <bjc>most of the locale warnings went away for me after i reconfigured my system and rebooted <jpoiret>you'll need to reconfigure the system <andreas-e>Okay. I do not have any locales in my user profile actually. Maybe that is the thing. <jpoiret>on guix system we use the system-provided locale, whereas on foreign distros you need to manually install the locales in your user profile <andreas-e>./pre-inst-env guix system reconfigure ~/config.scm <andreas-e>The second one, using the same command, failed... <bjc>ludo put in some kind of fix for the locale issue, which i would have thought fixed the issue without a system reconfigure in 4f4c38c881d4224dc545c82253d2a8f631f95927 <andreas-e>The second one uses the guix from the git checkout of the reconfigured user. Once I roll the user back, I can update the system. <bjc>andreas-e: i've seen that happen too! i don't know what caused it, nor what made it go away <bjc>for now i'm running ‘pre-inst-env’ in guix shell to work around other issues: guix shell --pure -D guix -- ./pre-inst-env guix … <andreas-e>The system builds /gnu/store/...-locale-2.33.drv. That is weird! <andreas-e>And now also ...-locale-2.35.drv, which makes more sense to me. <jpoiret>yeah, locales are being built for both glibc 2.33 and 2.35 to ease the transition <andreas-e>I started to wonder, because 2.33 is my current version. <jpoiret>otherwise you could end up with a system with glibc 2.35 locale with user programs needing glibc 2.33 ones <jpoiret>podiki[m]: what's the package causing all the rebuilds? <andreas-e>Now for the user: ./pre-inst-env guix package -u <andreas-e>guix package: error: gcry_md_hash_buffer: Function not implemented <bjc>you have to run it inside guix shell, like i said earlier <andreas-e>Last time I updated system and user, I could not login through gdm any more. <andreas-e>With "guix shell -C -D guix" I now get the following: error while loading shared libraries: libguile-3.0.so.1: cannot open shared object file: No such file or directory <bjc>hmm. i haven't tried with -C <andreas-e>Ludo suggested with -C. I will try without it. <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 <bjc>did pre-inst-env start working? <andreas-e>What did not work, for instance, was logging in via gdm as my other user, which I had not updated yet. I will try this first. <bjc>i'm doing a full recompile cycle, just to see if something has changed <andreas-e>But I could read some Chinese spam, and I have accents! <andreas-e>./pre-inst-env guix package -u still does not work. But -A glibc works. <bjc>is it the same error with missing definitions from c? <andreas-e>Missing gcrypt something, yes. I would like to recompile from scratch first. <andreas-e>But first I need to revive login with my other user... <bjc>good luck. it hasn't worked for me <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 <bjc>that's as far as i got before i got sucked into trying to get alacritty to work over the last few days <jpoiret>ah, the icedove bug is because we haven't updated icecat, and icedove relies on the icecat source <andreas-e>jpoiret: Why would we have to update icecat? <jpoiret>because icedove uses the same base code <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 <bjc>jpoiret: ouch. my wounds are still open <ngz>mirai: it looks like a red herring. <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. <mirai>ngz: so that “template” package thing is invalid? <mirai>it's missing a lot of things but it's not meant to be a “standalone” package <mirai>the idea is to inherit it to pre-fill some of the fields for actual package definitions <ngz>Try to provide reported missing fields and see if the weird googletest error disappears. <jpoiret>you can add the missing field initializers with dummy data <bjc>andreas-e: since i'm about to do a system reconfigure again, what do you think about patching python-setuptools to fix the 1980 issue with zip files? <bjc>too many dependents to safely do at this point? <mirai>got it, source and version must have some value <andreas-e>Too many dependents probably. It would also be nice to get some feedback from the Python team. <bjc>fair enough. i'll just monkey patch my individual problems, then <andreas-e>So I deleted lots of stuff in .cache and .config. Hopefully this will help the graphical login... <jpoiret>ah, the icedove situation is a merge problem it seems <jpoiret>can anyone with committer rights look into 2d25ea429c359d14955ee44baeeb5778cc56cc7d not landing in core-updates? <jpoiret>don't want to create merge conflicts down the line with a new commit that does the same <jpoiret>it probably would just need to be applied on top <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>jpoiret: Merge errors, so these are my speciality. <jpoiret>I wouldn't fault you for that, it's a revert of a duplicate commit that landed on both staging and master <andreas-e>Hm, so you want me to cherry-pick that commit, which reverts a commit already there? How is it even possible to commit the same thing twice? It should not apply the second time. <jpoiret>it got applied *after* some other commit that removed something that commit added <jpoiret>ie commit X added something, then commit Y removed part of it, then commit X got applied (in part) again, then the revert of the previous commit X <andreas-e>Okay, I cherry-picked the revert. This applied. <jpoiret>i'll only be able to reconfigure tonight, since i need the whole rust toolchain up to 1.65 which isn't built by CI (for a firefox packaged elsewhere) <jpoiret>i'll probably also build a vm image with the default configuration <andreas-e>Now I cannot do "./pre-inst-env guix build icedove" because of gcry_md_hash_buffer. Even after "guix shell -D guix"... <andreas-e>Do you want me to just push and we see what happens? <bjc>i had a substitute for rust-1.67 available a few days ago, from the rust-team branch <bjc>not sure if that helps you, though <andreas-e>Oh, I made a mistake. It is not "guix shell guix -D", but "guix shell -D guix"! <jpoiret>bjc: rust-team isn't based on c-u, right? <jpoiret>then that won't help, unfortunately :) thanks though <andreas-e>./pre-inst-env guix build icedove -n succeeds. I will try -S. <bjc>without ‘guix shell’? <jpoiret>can't wait for the feature branches! we'll have to spend some time setting up better coordination channels but it will be worth it <bjc>yeah, c-u has been rough <andreas-e>jpoiret: -S starts downloading firedfox sources. So I suppose that this is enough, and that I should simply push? <jpoiret>andreas-e: if it's 102.10, then yes! <jpoiret>oh, looking at the commit history, we now have native notification support in icedove? that's great! <jpoiret>no longer will I have notification windows taking up half of my screen when i receive new mail :) <jpoiret>anything broken I could work on? I don't want to be just watching my laptop build rust <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 <reyman>I use yubikey for decrypt/encrypt, for commit signing, for ssh <jpoiret>i don't directly use ykman often though, gpg takes care of everything for me <jpoiret>but yes, if I don't have my yubikey then I can't sign commits or send signed emails <andreas-e>This is serious. libubikey builds, however; the python layer does not. <andreas-e>Maybe we should add it to the manifest of release critical things? <andreas-e>It is also broken on core-updates, but podiki[m] had a solution. We could push it immediately after the core-updates merge and build it on CI. <jpoiret>yes, I wonder how much of it can be retrofitted without causing too many rebuilds. But it's possible that you can't hack your way out of it <jpoiret>i'm suspecting that podiki needs a swig update for something and that it's the one causing rebuilds. There should be a workaround for it <jpoiret>so, any other c-u breakage I could be working on? <andreas-e>The current python-yubikey-manager version is 5.1.0. Maybe a mild update to 4.0.8 or 4.0.9 could work? <reyman>Need to move on my side, thanks guys ;) ! <jpoiret>no, the python-cryptography>=4 support was added in 5 <andreas-e>I tried the 4.0.x, and they do not work. I suppose 5.0 will cause all kinds of problems... <andreas-e>Yes, it also needs a newer version of pyscard. Now I am not going to redo the same work as podiki[m] :) <andreas-e>Very well, I "guix pull"-ed everything to core-updates, and I can boot and graphically log in. <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! <mirai>why isn't it installing to a subdirectory specified in the plan and instead dumping everything from the source into the #$output ? <jpoiret>seems that zig is timing out on aarch64 <sughosha>jpoiret: Is there any example of using cross-libc as input or native-input? <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>guix package: error: profile contains conflicting entries for zlib <andreas-e>guix package: error: first entry: zlib@1.2.11 /gnu/store/v8d7j5i02nfz951x1szbl9xrd873vc3l-zlib-1.2.12 <andreas-e>guix package: error: ... propagated from gnutls@3.7.7 <andreas-e>guix package: error: second entry: zlib@1.2.13 /gnu/store/slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13 <andreas-e>guix package: error: ... propagated from gnutls@3.7.7 <andreas-e>hint: You cannot have two different versions or variants of `gnutls' in the same profile. <bjc>andreas-e: did you update from ‘guix pull’? <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 <bdju>since I'm skipping gajim can I also tell it to skip the new dconf or something? <andreas-e>It looks like something else also pulls in the new dconf, or you put it additionally into your profile. <andreas-e>In the second case, you could remove it from your profile, so that it will not be updated. And then gajim still pulls in its old copy. <bdju>kinda doubt I manually installed dconf, but I'll take a look <jpoiret>andreas-e: zlib 1.2.12 should never get propagated, that's very weird <bdju>okay I totally did actually... it's in my manifest file. <andreas-e>I think something weird happened because I tried to "update" from core-updates to master, and there were grafts in master I suppose - there are two zlib versions. <andreas-e>Things will still fail if an old and a new package both have dconf as a propagated input. <janneke>i forgot x-debbugs-cc teams headers for two guix home bugs, should i add them to the bugs afterwards and if so how? <bdju>more gajim-related bits kind of it seems <jpoiret>bdju: there's only one of them left in c-u <bdju>people keep asking me this, I'm just on whatever the normal/default thing, a regular user trying to update their system <bdju>I think I'm on master but not entirely sure <bdju>added gajim-omemo and magic-wormhole to the list of things to skip and now python-keyring is apparently an issue. what a mess. <bdju>and now python-matplotlib. it's seemingly always python <bdju>now python-pillow is a problem <bdju>without meaning to sound rude, doesn't stuff like this get tested before it's pushed out? seems odd that things are this bad <bdju>maybe the issue isn't as bad as it appears and if I weren't trying to skip the failing gajim build the rest wouldn't be an issue either. not sure. <bdju>python-secretstorage is the next problem <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 <bdju>bjc: good to know. thanks for the info <jpoiret>1.4.0 should be fairly stable, I don't think we've fixed any installer-related bugs since <Nuri>I'll try reinstalling. It could be if I run into an error or something I'm missing. If I can share this here I think I can get some help. <Nuri>unknown filesystem grub rescue <Nuri>This is on my screen. I can't install with uefi option either. <jpoiret>so, you put the .iso on a usb stick and just booted up, and that's what you get, right? <jpoiret>how did you put the iso on the stick? <jpoiret>what system are you on? x86_64 with EFI? <Nuri>From the terminal, run dd if=guix-system-install-1.4.0.x86_64-linux.iso of=/dev/sdX status=progress <jpoiret>have you checked that your stick is not faulty? We've had some of these in the past <Nuri>I really want gnu guix to be the only operating system on my computer. But i won't be able to install it without help. <zeropoint>anybody have suggestions for best practices for composing config.scm files? I'd like to abstract my file system definitions for instance so I can re-use configuration for another computer. <jpoiret>Nuri: can you look at the partitions on the stick on a live linux, see if they work? <jpoiret>mirai: you're getting that error because of a g-exp, right? <mirai>the 'echo-again phase would print all of the arguments to these phase procedures <mirai>but since it's nearly unreadable I thought on using ,pp within a guile repl <jpoiret>what's up with the stray _ in format? <jpoiret>how are you getting the code you're putting in the (define x ...)? <jpoiret>it contains actual guile procedures, which are printed as #<procedure ....> but can't be read back <mirai>jpoiret: the _ kinda works, it's the argument to lambda <mirai>I don't really care about the procedures themselves, I was only looking to pretty print this thing as a list <mirai>since that thing as a single line is almost unreadable <jpoiret>that's really weird that you could use _ that way, I don't think it should bind, but alas <mirai>though I managed to extract with ctrl-f the info I was looking for <mirai>in that sea of garbage, there's this: #:install-plan ((. ./)) <mirai>but I thought I substituted that in substitute-keyword-arguments? <jpoiret>in the guix codebase at least, the _ form is always followed by default value for some reason <mirai>I can use any other valid name and it's still the same <mirai>surprisingly, I can even change the strings within #:install-plan and it doesn't trigger a rebuild <mirai>well, perhaps not that surprising since it's getting ignored for some reason <jpoiret>i'm thinking that in the case where there is no default value, and the argument doesn't exist in what you're substituting, it will not do anything <jpoiret>i could also just read the macro definition <mirai>??? I can but it's even less clear <mirai>`./catalog.xml' -> `/gnu/store/5lhw7rwjh6l7785z84kxl2acnixp3j7d-docbook-xml-5.1/xml/docbook/5.1//./catalog.xml' <mirai>previously: `./schemas/catalog.xml' -> `/gnu/store/pi8z5gpa3a0i6zql7nm8br86s9wmm4xr-docbook-xml-5.1/././schemas/catalog.xml' <mirai>I added #f as a default value to #:install-plan <mirai>I see that #:install-plan now appears in the echoed output with the correct plan <mirai>it was really about the default value <mirai>you were correct that without a default value the substitution does nothing <bdju>oh I finally skipped enough things to get upgrades to go through. sweet. <apteryx>did someone successfully boot the 1.4.0 iso in UEFI mode? <rekado>I noticed that on core-updates cross-gcc is broken. I wonder if that’s for all packages using the cross-gcc procedure or just for some of them. <rekado>the problem is due to the parent GCC package using gexps (instead of a quasiquoted expression) <jpoiret>fixing it will probably not cause too many rebuilds <jpoiret>but also, we don't build our cross-gcc the proper way, only the same version of gcc will successfully build <jpoiret>or at least, if it builds for other versions that's just luck <bjc>is it acceptable to just tack ‘#:skip-build #t’ onto rust packages because it's so draining to constantly add and update rust packages? asking for a friend <Jerops>Hello! How can I make a profile with a working cross compiler so I can play around with it? <jpoiret>Jerops: you probably need to use a manifest for that, unfortunately. You will then need to include the cross-{libc,gcc,etc..} you need in there, they come from (gnu packages cross-base) <Jerops>Yeah, I already did that. The compiler doesn't know about the libs and headers though <PurpleSym>andreas-e: I have a fix for Haskell on i686 – I think. Can I somehow test it on cuirass without pushing to core-updates? <andreas-e>Not really. As soon as it is on cuirass, it is going to be built on all architectures. You could with a login on berlin. <andreas-e>Can you send me the commit, or send it to guix-patches? <andreas-e>I could try to run it and tell you tomorrow. <andreas-e>To everyone who submitted core-updates patches to the mailing list: I am trying them out right now before pushing them. <Guest19>I get "guile: warning: failed to install locale" if I compile my package. How can I fix that? <jpoiret>have you looked at what (guix build-system gnu) adds as default packages? <PurpleSym>andreas-e: I don't have access to berlin. Will send it to you tomorrow, as it's too late to polish it into an actual commit. <mirai>what's the specs of the substitute building machine <andreas-e>PurpleSym: You could just send me a "dirty" commit by email, then I could launch it at least once overnight. <apteryx>jpoiret: there's a patch addressing the cross-gcc inferred to be the right one <bjc>if i were to throw in the towel on this alacritty upgrade project, would anyone want my work so far? <bjc>i hate to throw it all away, but the fractal explosion of dependencies is really getting to me <bjc>and i'm seriously at the point where i'm never going to use alacritty or any other rust project again because of what i'm seeing, even if i complete this interminable work <bjc>i cannot realistically say how much is left to do. every time i think i'm getting close to done another dependency ends up pulling in dozens and dozens more <jpoiret>bjc: exactly how I stopped using protonmail bridge <jpoiret>it's in Go, had the exact same experience. I'm never using rust or go again. Except that now it's in librsvg, firefox, etc. :( <Nuri>I tried to boot a different usb and install it with it, but I couldn't install it again. <bjc>i'm honestly shocked and apalled. it may seem like i'm trying to be funny or facetious, but i'm not. this is the worst thing i've ever seen and it's endemic <mirai>andreas-e: good news, I managed to make docbook-xml packages not conflict in profile and simultaneously make that substitute in kdoctools for DocBookXML4 unnecessary <jpoiret>Nuri: so, you're still getting dropped into the grub rescue shell right as you boot? <bjc>yeah, i assume go has the same issue. anything, really, with these trivial auto-download package manager+build systems <mirai>andreas-e: am investigating if we can also do away with the substitution at docbook-xsl <andreas-e>mirai: Sounds good! But after the core-updates merge please :) <Nuri>I want to use gnu guix. But not being able to install it makes me very sad. :( <ekaitz>jpoiret and bjc same here... the npm effect is everywhere :( <andreas-e>bjc: Did you get to a leaf anywhere? Then this could be submitted even if so far it has no other use. <jpoiret>Nuri: I am downloading the iso to try it out <bjc>i have some leaves, but it's all a mess at this point <bjc>it'd take me a long time to track down what's done and what's still waiting on updates <Nuri>jpoiret: thank you very much <jpoiret>you said the error message was unknown filesystem, right? <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 <sughosha>Ok. I will try something. Thanks for helping! <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 <podiki[m]>maybe could just relax some requirements and things will work, but virtualenv was several years old if I recall already