IRC channel logs
2026-03-23.log
back to list of logs
<test202020>Hi/ how i can clean guix home? always when i reconfigure home gdm is broken. <test202020>before yesterday update one way to fix gdm is remove .guix-profile. today is need to remove .guix-home link too <yarl>Also, "(guix)Building the Installation Image for ARM Boards" is outdated? The way you built the iso is not very user-friendly. <Rutherther>yarl: unfortunately not, it's hard for me as I do not have a way to test it, I have to bother other people to do it :D the idea is that you get this iso on a usb drive, not on an sd card. Because you would use this iso to install a system <Rutherther>yarl: I wouldn't say it's outdated. Many boards do not have UEFI, so the 'generic' installation iso will never work for them <yarl>I think to use an USB, you need a flashed SPI. <Rutherther>although yes, we should also mention the new way as well <Rutherther>yarl: you need UEFI, so presumably that lives on the SPI and you would need it for both SD card and USB <Rutherther>yarl: if you want to do it without UEFI, you cannot use the generic installer. It supports only UEFI boot <yarl>What I mean is that the default, shipped rp64 can't boot directly on USB <Rutherther>yarl: is the default UEFI? I would be surprised if they had UEFI that booted from SD card and not USB... <yarl>One need either uboot on sd or emmc or spi to jump to USB. <Rutherther>you probably are, but as I am saying, with the default SPI the image will not work either way. It's not about USB vs SDcard here, it's about EFI. You need a bootloader capable of booting EFI <yarl>This can work with the default SPI. <Rutherther>does the default SPI support EFI? From my searching it doesn't <yarl>If you have an sd or emmc <Rutherther>I cannot find any information about it supporting UEFI except if you flash U-Boot or Tow-Boot <yarl>Well, if the SPI chainloads to bootloader in (sd or emmc) with EFI support, that's fine. <Rutherther>right, but you need to supply that bootloader yourself in SD or eMMC and then the image can be in USB, no? <yarl>Maybe I'm wrong, I don't remember this stuff very much. <yarl>It's just that you said "the default SPI will not work either way". <yarl>But it might. Still I'm not sure. putting guix on my rp64 is on my todo list, I'm just gathering some infos there. <Rutherther>right, I meant directly from the SPI bootloader to EFI. If you boot from SPI to U-Boot and from that to EFI that is fine of course <Rutherther>but at that point I would be surprised if the image could live only on the SD card <Rutherther>the SPI boot will probably require the bootloader to be at a specific offset and that's just not what the generic image offers <Rutherther>I've also replied to the issue with a more intuitive way to build the image. When you ask me 'how did you build it?' I reply exactly how I built it for. Not with a good way to build it for you <Rutherther>and yes, to answer your original question, you would just dd it directly on something, either SD card or USB. (but I recommend USB so that you can install to SD and I expect if you have something that boots EFI it will boot either one) <yarl>Rutherther: I wonder, should we (guix) provide instructions to flash the SPI? <efraim>I could see possibly leaving a note in a rockpro64.scm, but I wouldn't add it to the manual, better to point to upstream documentation for it <Rutherther>I think we could possibly describe it in the manual in like a single paragraph, linking to somewhere else for detailed instructions <Rutherther>but I don't think giving out exact instructions in guix manual would make sense <test202020>currently i try to new home config and that working, but i have stranfe profile. <test202020>my user have some packages, but now all and appending to home config not install new packages <Rutherther>test202020: you cannot really disable it, it's linked in software. You can disable the auto spawning of a server with "autospawn = no" in the pulse config file <Rutherther>specifically in the client.conf, so client-conf of pulseaudio-configuration <cbaines>I can't reconfigure bayfront because it can't substitute /gnu/store/p5psrv3vcxf99vl99wipxyi0001hfy5n-bdb-6.2.32-doc from itself :( <efraim>sometimes I build with --no-substitutes and let the build machines figure it out <cbaines>it could very well be a server side issue, even though the substitute script is downloading from literally the same machine, it's behaving as such a slow client that the server closes the connection <civodul>oh so it’s the client that is too slow and eventually fails? <yelninei>hi, are there any plans to update ci.guix.gnu.org for guix/maintenance#86? or has that already happened? <cbaines>civodul, well, the substitute script only says "86.0%retrying download of '/gnu/store/p5psrv3vcxf99vl99wipxyi0001hfy5n-bdb-6.2.32-doc' with other substitute URLs..." and I'm having a hard time figuring out from the code what that could mean <cbaines>bayfront is definately slow, but I think this is past the point where the substitute script has a timeout <cbaines>I'm guessing it's slowness that's causing this as I've got it to work by reducing load on the machine <civodul>yelninei: ah sorry no, that hasn’t happened AFAIK <efraim>I'm down to 2 packages building with gcc-10 (I think) <yelninei>civodul: all x86_64-gnu builds are blocked by it, but afterwards "guix build guix --without-tests=guix" and "guix pull" (from a local clone) work <andreas-e>Their "sources" are an appimage. That is not something we do in Guix, we require to build from source. <mroh>you need dotnet to build this. I guess, its impossible to bootstrap dotnet -> good luck! <andreas-e>We have 17 (!!!) versions of mono in Guix and only 13 of gcc. <mroh>oskarw: there seems to be only 1 package in guix that uses the mono-build-system: the nuget importer. take a look at import/nuget.scm. have you tried building this with mono? <yelninei>compilers that require a previous self are fun to bootstrap <janneke>and indicate its developers have no clue whatsoever about bootstrapping <trev>what's the correct way then? <gabber>trev: have some minimal/base compiler that is able to build some modern compiler that can self-host <identity>that means you have to write your compiler in C, though <trev>i suppose you could always backport to before you start self-hosting? <trev>i.e to your compiler written in C <trev>s/could always/would always have to <gabber>janneke: this, from you? you should write your compiler in MES Scheme, of course! <janneke>ACTION is "waiting" for ekaitz' amazinsg performance improvements though before making that statement :) <identity>the approaches are, essentially: no bootstrapping (or extremely obtuse bootstrapping); make a small compiler in an easily bootstrapped language like, ugh, C; make somebody else bother with bootstrapping (ranges from ‹just fine› to ‹i hope one day you will have to compile your compiler with pen and paper›) <yelninei>the main issue is making sure your bootstrap compiler can keep up with the latest source / being conservative with using new syntax/features in the compiler to not require 100 intermediate ones <oskarw>mroh: After reading this conversation I think I will just use appimage, It would be too hard for me <mroh>oskarw: yeah, I think, that's a good decision. <kratacoa>It seems to have broken somehow libunistring, as guile is now unable to execute <kratacoa>/gnu/store/wjs73lq5xhfqjglh3gzksskqnzxw4zmc-guix-1.5.0-2.520785e/libexec/guix/guile: error while loading shared libraries: /gnu/store/lb65h1xdxzpyhrww6qv3xidyvmi8f13g-libunistring-1.3/lib/libunistring.so.5: unexpected reloc type 0x20000001 <kratacoa>Do I go on and report the issue as is, or is this a known one? <ekaitz>janneke: for the time being we have an architecture improvement only lol <ekaitz>making it fast will need some time <janneke>ekaitz: well, transparency/readability is much more important than performance, imo <andreas-e>kratakoa: Did you try a second time? I wonder if this is simply a network problem. <kratacoa>andreas-e: running a guix pull? I can't, because guile is broken <kratacoa>I'll try to manually change the profile later on as it doesn't seem to be fixable in any non-manual way <kratacoa>the error from guix pull does seem unrelated to the guile one and I'm clueless as to what's the link there <andreas-e>I am confused. "guix pull" should be atomic; if it does not succeed, nothing should change. <janneke>has upsream been sent a link to that post? <Rutherther>andreas-e: mono is replacement of .NET Framework, not of modern .NET <janneke>it's obvious they don't really care about bootstrapping, but... <yelninei>janneke: what was the issue with graphviz-minimal? it should build natively but maybe it does not cross compile <janneke>also, graphviz was being excluded, but guix now uses graphviz-minimal <janneke>kinda silly in a way "graphviz" doesn't also match "graphviz-minimal", i understand it, but yeah <janneke>i'm puzzled how substitutes for i586-gnu aren't available, been building automake-1.16.5 for over three hours now... <janneke>possibly git-minimal has gotten a new "curl" dependency? <yelninei>janneke: automake 1.16 should be easy as it does not run tests, automake 1.17 has a substitute, unless you are on a very old revision <janneke>building /gnu/store/avgkjqq20s71cigzrqr01bi0v1s120ay-automake-1.16.5.drv... <janneke>this is on i586-gnu, very latest childhurd built this morning <janneke>running: guix shell --bootstrap git-minimal <yelninei>the trick is to use a a cross compiled git-minimal :) <janneke>sure, there's a cross-compiled one in the store that works... <janneke> commit: ac45ca625a2edd5eb4a5607717bebed3d6d81b43 <janneke>ACTION didn't do a guix pull, of course -- that might be the problem? <janneke>because i didn't think of that but also, you need git to clone guix and pull from the local guix git tree, to then get a git-minimal...hmm? <yelninei>janneke: what is your guix --version? shouldnt it be 1.5.0-2.520785e? <yelninei>because i cant find your commit on savannah or codeberg <janneke>ah yes, i built from a commit that i've been carrying for years <janneke>REMOVEME devel-hurd: Add console=com0. <janneke>that allows for getting qemu to send messages to my emacs shell/console and not do graphic nonsense <yelninei>i think that might be still before the core-packages-team merge from last year, so automake 1.16.5 was still the default automake <yelninei>and that automake/guile has a test failure with libgc large block warnings on stderr <janneke>i seem to remember we used to do *two* guix package updates because of this a couple of times... <Rutherther>two package updates are no longer done because the guix images use (current-guix), not the guix package that they used to use <Rutherther>the ones for release that is. Whether your ones do that's up to the configuration you use <Rutherther>two updates are quite cumbersome, sometimes you could miss one not building or the CI hasn't picked it up <janneke>Rutherther: well, i built a fresh image from master this morning and got guix-1.4, so yeah? <Rutherther>janneke: what's the definition of the image then? <Rutherther>you need to pass (current-guix) to guix field of guix-configuration in guix-service-type <janneke>Rutherther: gnu/system/examples/*hurd*.tmpl <janneke>i guess they should have been updated with this insight? <Rutherther>hard to say, depends on what the use case of these images is <yelninei>did you run with ./pre-inst-env and your branch with the extra commit has not been rebased? <Rutherther>you can see that the vm-image.tmpl and gnu/system/install.scm do use (current-guix) as these are used for the release artifacts <janneke>yelninei: with extra commit, has been rebased <yelninei>because you seem to have downgraded your guix to Dec 2024, at least that is when the update to 1.4.0-30 happened in 942942ee75542e684baaccdd26372cfa6e2bc2a2 <ieure>yelninei, I see this when my shell init files aren't loading my Guix profile. <Rutherther>it's quite easy to do that if you reconfigure a few times, your guix version will be decreasing every time if you haven't pulled, but you will need to --allow-downgrades <bjc>why would the guix version decrease on reconfigure? isn't it just the git commit id of the guix channel? <bjc>if i reconfigure a bunch of times without a pull, i wouldn't expect the guix version to change at all <Rutherther>because every guix version has an older (@ (gnu packages package-management) guix) package version <Rutherther>then your expectation is wrong, you're reconfiguring with the system guix version as long as you have never pulled and that one is decreasing because it uses the package, not current guix version <bjc>that's been 1.5.0-520785e for a while. it doesn't change on every pull <janneke>Rutherther: the (guix-configuration (guix (current-guix))) seems a nice hack, any reason that's not the default? <Rutherther>try it on a newly initialized system and you will see what I mean <Rutherther>bjc: correct, so if you just create a system, you will have 1.5.0-520785e guix. That version of guix had 1.5.0 as the guix package. So when you reconfigure, you will be at 1.5.0. Then the guix you have is 1.5.0.rc1... and so on <Rutherther>the way out of it to not use the guix from /run/current-system <Rutherther>for example you could always use /var/guix/profiles/system-1-link/profile/bin/guix, then it will be stable <bjc>if i'm using 1.5.0-520… and reconfigure, i should stay on that same version, no? <Rutherther>no, because the guix package cannot refer to the same commit you are on <bjc>yeah, the classic problem of embedding a commit id <bjc>brain just glossed over it for some reason <yelninei>janneke: If you updated the guix package privately did you also update the commit id after rebasing? <podiki>efraim: was thinking to update to the newest wayland just released (and mesa point release) but see it needs mdbook; we have crates but not the actual mdbook? <kratacoa>andreas-e: sorry for just getting back to you. Yes, I'm confused as well. Might be a filesystem or RAM issue too, no idea. That's why I decided to ask here first and check if there's any lore <andreas-e>Hello podiki, please refrain from making big changes to the mesa-updates branch that are not bug fixes; about 20000 of its 30000 packages have already been built by QA. <Rutherther>kratacoa: try "guix gc --verify=contents", does it show any issues? <Rutherther>in case it didn't work due to guile issues, try older guix version you have on disk, if any <Rutherther>ie. /var/guix/profiles/per-user/$USER/current-guix-X-link/bin/guix or /var/guix/profiles/system-X-link/profile/bin/guix <podiki>andreas-e: i was thinking at least the latest mesa bug fix release (26.0.3), and since that depends on wayland to bump that too; but if you think we can merge very soon then i guess it has to wait <andreas-e>podiki: I hope we can merge soon, which assumes that no show-stopper bugs appear. Since you followed the builds on CI, I am rather optimistic. (Personally I only look at QA, which needs to catch up.) <podiki>berlin got up to ~83% if i remember the other day on x86_64 <PotentialUser-59>Hey has anyone been able to build GTK recently? When reconfiguring my system today Guix kept trying to build it and it always failed in the check phase. I heard that it can take a couple of retries for tests to pass but I have tried like 7 times already and It's almost always the same tests failing <andreas-e>QA makes it easier to see the failing packages, since a few key packages breaking can cause a lot of annoyance not just in the numbers. But if you feel confident you could also merge just from looking at CI. <andreas-e>On the master branch, there is a substitute for gtk. <podiki>let's see how this current evaluation goes and i'll at least see if i have subs for my desktop too <Rutherther>PotentialUser-59: are you perhaps using unprivileged daemon? There is a known issue that it doesn't pass a test <andreas-e>Rutherther: But should it not just use the same substitute? <Rutherther>andreas-e: sure if there is a substitute and they use the substitute server, it will use it <PotentialUser-59>andreas-e thats weird, guix weather no substitudes available for me and i pulled like 3 hours ago <yelninei>is there an easy way to add -K when offloading? i can guix build the derivation manualy or with GUIX_DAEMON_SOCKET but then all the dependencies wont get offloaded <kratacoa>Rutherther: sorry again for the late reply, I'm doing chores in the meanwhile <kratacoa>that was the first thing I did (and you taught me!), but unfortunately as guile is broken it's giving me the same error <kratacoa>(sudo guix gc --verify=contents,repair that is) <kratacoa>thanks for the other tip, that was what I was thinking of doing (and you taught me as well haha) <podiki>anyone from python-team or python experts around? <podiki>has there been some change in guix that could lead to sharedmemory changes? getting an error "OverflowError: Python int too large to convert to C ssize_t" in something <podiki>(unfortunately something not in guix, so can't share an easy reproducer yet) <podiki>probably more a container issue than a guix change i'm thinking now, but not sure how to figure it out <podiki>ah got it, a 32bit python was being used <bjc>well, i can answer the question from earlier: you can't use (current-guix) when cross-compiling <bjc>at least in my case, i ended up with a linux binary for guile that the guix script was trying to use <Rutherther>hmm, does the channel build system not support cross comp? That should be added probably then <bjc>i'm not sure why it didn't work. (current-guix) just emits a package definition <bjc>but i didn't dig into it once i confirmed why the guix command wasn't working in the childhurd <Rutherther>yeah, the channel build system currently ignores #:target <theesm>hi guix o/ should we move the contents of the cyrus-sasl module to mail? currently working on a PR to add cyrus-imapd and considered to propose renaming cyrus-sasl as a module to cyrus but merging it to mail probably would be the better call. <mubarak>I tried to install Guix x64 latest after updating BIOS driver on Windows. I boot guix form usb flash driver the kernel load fine, and the cursor blink on the bottom-left screen for a long time and not lunching the installer. When I switch between CTRL+ALT+(F1,F2,F4) nothing happens(maybe when I return to F1 it shows random colors on the screen, and <mubarak>once it showed the installer but the screen it's not clear(I can barely read part of the text <mubarak>I also tried 1.5.0 x64 stable release <ieure>mubarak, I haven't run into that. What kind of computer are you trying to install on?