IRC channel logs
2026-01-21.log
back to list of logs
<attila_lendvai>i have full bash installed. with that i can see that it hangs when calling `/sbin/init --version` <attila_lendvai>(and running `/sbin/init --version` manually cycled my network... :) <attila_lendvai>ieure, yeah, probably. what would be the right move? trying to get a uboot for the R4 packaged, and then packaging a kernel? (not everything is upstreamed yet) <attila_lendvai>FTR, installing guix on openwrt is really just downloading a tar, extracting it, and starting the daemon <flurando>hi, does anyone has experience of doing java stuff on guix system? I am trying kawa scheme, but stuck when attempting to run the compiled class file. With `kawa --main -C test.scm`, then `java test`, it always says "Error: Could not find or load main class test". <sneek>Welcome back flurando, you have 2 messages! <sneek>flurando, Kabouik says: The guix-emacs channel can conflict with official channels because it's a script-based channel that packages Emacs packages from MELPA, it's not really tested before every commit (except maybe some automated tests), let alone against emacs-* packages in the Guix channel. And this is what might be the issue in most cases, a mix of packages coming from this channel and from the official channel, since guix install doesn't <sneek>flurando, Kabouik says: By the way, the "guix package rename-file: is a folder" was indeed the issue I mentioned: I should not have created the last level subdirectory before invoking guix package -m xxx -p xxx. <flurando>Kabouik: Good to hear you being clear what caused the problem. Now I understand why guix-emacs could not co-exist with main guix channels. By the way, I recalled that `guix remove <package>` then `guix gc` would not delete `emacs` from your /gnu/store unless you delete the previous generations of guix profile, as what `guix remove emacs` does is switching to a new profile without emacs. <user2>possible to sign for Server? ZNC? <acidbong>(hopefully Gnome/GTK folks are here) I'm trying to update a package (gucharmap), but it fails to build docs. i included all dependencies from the Nixpkgs recipe, which build successfully, but Guix still complains about `gucharmap.devhelp2` not being found. what can i do about it? <Kabouik>Oh, interesting flurando. You're right. I'm not familiar with that issue at all because, on my machine, I actually don't really need DE integration: I use Sway and a Bash script (sway-desktop-launcher) as my app launcher for desktop files, plus I'm on Guix system. Here on the other machine, KDE Plasma (1) picked up guix-installed software when installed in the default profile, (2) didn't remove them when those programs were guix-removed (probably what <Kabouik> you explained), (3) fails to pick up programs installed by guix in extra profiles. <Kabouik>So maybe a `guix package -d xxx` would help. I'll have to try, thanks. <attila_lendvai>followup from yesterday, trying to install guix on openwrt: it worked, but when i tried to guix pull it tried to build a whole lot of packages locally, and got killed (probably OOM) at: /gnu/store/fzikjcky62w74n7g0jvxbi9dzzcgil3x-gcc-cross-boot0-10.3.0.drv <attila_lendvai>they need to be explicitly enabled? i just issued a pull and it seems to use substitutes. <attila_lendvai>i just restarted the pull and it starts to build the same derivation locally (after a bunch of "updating substitutes" lines) <Rutherther>you do need to authorize them, that doesn't happen without your consent during install or without manually doing it <attila_lendvai>hrm, yeah, there's this line before 20 'updating substitutes': "guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable" <Rutherther>the keys are in /var/guix/profiles/per-user/ruther/current-guix/share/guix <attila_lendvai>Rutherther, thanks a lot, and never mind i fixed that... it's pulling now with substitutes <ewyufg34>Hi, is it normal that the first guix pull and guix system <ewyufg34>reconfigure take so long to complete (like 1 hour on a t420 with an ssd and 10GB of ram) after the installation and during the <ewyufg34>indexing objects phase? I already knew the first guix pull were <ewyufg34>"expensive" but the same happens with guix system reconfigure. <Rutherther>ewyufg34: the reconfigure does the same thing as pull on the first reconfigure. It populates the cache, root's cache. It should not take longer than pull. If it is taking longer, I would expect it means something has gone wrong somewhere <Rutherther>ewyufg34: especially if it's stuck at the same percentage for some time, just kill it and rerun it. It should not happen usually that it would get stuck, but you never know what can go wrong exactly <flurando>ewyufg34: It is perfectly normal. But you can always execute the commands again or try different network routes. <attila_lendvai>FTR, guix pull on the aarch64 openwrt install succeeded. a `guix shell gcc-toolchain` yields a working gcc on a... 5W router, essentially... :) <attila_lendvai>the 1.4.0 release has a substitute key for ci.guix.info.pub, but that entire domain is for sale. after a guix pull it's still present in the share/guix directory. <attila_lendvai>the key is still in the repo in etc/substitutes/ci.guix.info.pub; is this a bug to be reported? or maybe someone who knows what's going ong can just remove it? <andreas-e>attila_lendvai: I think this is a misunderstanding; the guix.info domain is under control of Guix Foundation, and .pub is the file extension. Presumably there is info.pub or a subdomain thereof that is for sale. <fanquake>Was the commit that changed the version to 1.5.0 in the 1.5.0 branch just force pushed away? <yelninei>Rutherther: For 5801 i think these should only be autoloaded to only have a run time dependency. Though (guix import nuget) seems to require (semver), (guix import npm-binary) has a workaround for that. <Rutherther>yelninei: yeah, I also came to this conclusion, see my update there <graywolf>So, uh, I know we sometimes update fast, but go 1.26rc1, really? <graywolf>Was there some pressing need to update to a release candidate as the latest available go? <Rutherther>yelninei: I will let my make finish first and then try to rerun without the ztst dependency. Then adapt import nuget and also without the semvere <yelninei>Rutherther: guile will complain about failing to autoload but it should not cause an error, e.g. (gnu build secret-service) autoloads fibers <graywolf>efraim: Was there a need for this? golang.org still shows 1.25 as latest. <Rutherther>yelninei: yeah the issue is that it's not easy to distinguish actual errors from 'fake' errors in the make. I think the actual error might have been something else <efraim>there was a request to go ahead and package it as long as I was working on the other versions too. otherwise I wouldn't have bothered <Rutherther>fanquake: yes it was just force pushed away, that's why there was no tag or anything. Because if issues arise, it needs to be gone. Issues arose.:/ <graywolf>I mean, go-next or something would likely be better no? <fanquake>Rutherther: right, but why not push a reversion, rather than break the branch for anyone downstream? <Rutherther>fanquake: the branch is not supposed to be used by anyone downstream now, it's a wip branch, similarly to team branches <graywolf>Look pretty weird when you do `guix shell go` and get a release candidate instead of stable version :/ <fanquake>Rutherther: I see. So should it have been named wip-version.. then? <fanquake>Downstream users who are pulling all branches, just end up with git issues, when force pushes are made <fanquake>iirc this also sometimes happens on master even <Rutherther>fanquake: I don't know, maybe, seems fine to me, release hasn't been announced yet, so I wouldn't say so on first thing that comes to mind <Rutherther>fanquake: if one is doing a mirror, I would say they should be force pushing always. This will also break with team branches for them where force pushes are expected quite often <Rutherther>fanquake: I will put this to notes for considerations to the next release, if there should be wip- branch for the version. But it seems like too much work for the people doing the release for little benefit. We would need to be coordinating with CI changing branches <fanquake>Is this practise / the rationale for this documented somewher? <fanquake>Seems a bit odd to just be nuking history / changes, and just expect downstream to be fine with that <efraim>the release branch is for organizing the release, and the potential tag for the release had to be removed. it happens. <Rutherther>guix operates on linear history, the team branches need to be force pushing, merges are used only when absolutely necessary. I think that is documented somewhere, not sure where <fanquake>efraim, I'm also talking generally, given this happens on master <efraim>force pushes only happen on master if we need to remove a commit that wasn't signed <yelninei>is there a way I can run the code from a 'guix build' exactly as the daemon does? <fanquake>Rutherther: It'd be good to see the docs, if some exist, to know what to expect <yelninei>i am having an issue where a normal "make" is fine but when guix tries to build it there are issues <Rutherther>yelninei: I don't think there is an easy way to do that <Rutherther>yelninei: have you tried --keep-failed, sourcing the environment-variables and running make in that environment as first approximation? <fanquake>(still also wondering why a reverting commit (with rationale) can't be pushed, rather than a force push? <Rutherther>fanquake: depends on the commit. If you're asking specifically for verison-1.5.0, it is because the update has been invalidated, there is no 1.5.0 on the commit. Secondly to make the history cleaner. Since it is a wip branch, the history is made cleaner with force pushing. The branch has been force pushed to multiple times in the past few weeks <Rutherther>fanquake: if you're doing a mirror, I suggest to use the tools git provides for that along with clone --mirror and push --mirror that will make sure it's really a mirror <fanquake>Rutherther>: Thanks. I'm not running a mirror. I've got a few branches, and I've noticed multiple times over the past year or more, I've run into this issue. Most recently with the 1.5.0 branch, because we have been testing the changes in the branch. <Rutherther>fanquake: okay, thanks for testing the changes. Have you found any issues? <yelninei>Rutherther: yes that is fine. The issue is a memory leak somewhere with the guile build driver <fanquake>Rutherther: Nothing really so far. I assume there's going to be an rc2 now anyways? <Rutherther>fanquake: rc2 is not really planned, why do you assume that? <fanquake>because of all of the additional changes? <yelninei> Rutherther: THe command to run is in the .drv <Rutherther>yelninei: yes, that is ran by the daemon, but I do not expect it will help you to be honest. Because unless you run it in the same environment as the daemon, including the container ... I am not sure why you would get the same failure <yelninei>well, the daemon runs with --disable-chroot anyway. But i think i might have found the cause now <yelninei>the issue seems to be related with setting LC_ALL and install-locale phase. somehow only an issue on 32bit <Rutherther>yelninei: so afterall you got the error running the builder from .drv, but not running make manually with source environment-variables? <yelninei>Rutherther: No I can still not reproduce it with that, but i saw the LC_CTYPE in the drv and vaguely rememberd something with locales from the issue <Rutherther>yelninei: but I would expect the env vars to be set in the environment-variables and if it was that, then it should be reproducible, strange <yelninei>but I still dont understand how a setlocale causes guile/libgc to leak until exhaustion. I does not seem platform specific as it works on x86_64-gnu <Rutherther>civodul: Thank you. That nuget importer is giving me some chills:/ <civodul>ACTION sends Rutherther support and encouragements <ieure>Someone should make a translation tool called .po' boy <civodul>FuncProgLinux: nope! it’s human-made <FuncProgLinux>civodul: Ah, It was a doubt from the review you left me in the merge request. I didn't give more context there but the Danish translations were causing the build to fail. <civodul>well maybe let’s discuss this on Codeberg <civodul>i was surprised by this mate-autogen script <civodul>it reimplements bits of Automake/Autoconf… <FuncProgLinux>civodul: It caused the segfault error reported by the cuirass bot. And it gets worse, since the FTP is no longer used, by moving into git sources the inputs list needs to grow and some phases have to be repeated <ente>where does guix log the X11 session errors? <ente>it's not ~/.xsession-errors by default <FuncProgLinux>I mean they started providing the pre-built .tar.gz in GitHub as well, but AFAIK we favour git source code over prebuilt sources <ieure>ente, It keeps two logs (current and last) for each X display. <ente>xfce is broken all of a sudden and I can't see why <ente>guess that stuff doesn't go to the xsession-errors log <Rutherther>civodul: moreover locally I see no changes in the derivation for powerpc64le from that commit... <untrusem>last package upgrade for xfce was two weeks ago <ente>black screen with an X shaped cursor <FuncProgLinux>I've also seen breakage in MATE and didn't update the specific package but I think if I upload a mate-menus update some users WILL experiment breakage. <ente>a couple of session services are running but not xfwm it seems <ente>if I log in on openbox instead, things are kinda functional <acid-bong>a question on inputs format: if `(,glib "bin") is preferred over `("glib:bin" (,glib "bin")) , why does `guix lint` complain about the former? <civodul>Rutherther: it’s not a rebuild compared to “guix build jemalloc -s powerpc64le-linux -d” on ‘master’; it’s a different derivation, but same outputs <ente>FuncProgLinux: that crashes in a way that takes me back to the display manager <Rutherther>civodul: btw note that there has been a force push, dropping one commit (update of guix package) and two new commits, one of them disabling tests for jemalloc on ppc64le and one changing the system installer. The evaluation I sent is after this change. Even moving back to the previous commit and doing guix build --derivations on one of the packages that Cuirass is noting as a change I see the same derivation as CI is seeing now. So to me this somehow... <Rutherther>... looks to some kind of an issue in Cuirass? The derivations don't seem to have changed. Am I missing something here? <ente>(someone else's post, not mine, but I agree with him) <FuncProgLinux>ente: I'm unable to find another person with that same error :s <ente>time to ditch xfce, maybe <ente>been having trouble with suspend as well <Kabouik>ente: I don't see where the survey to fill is. Is that the the "call for evidence" thing? I only see comments there. <FuncProgLinux>ente: If you don't miss the whiskermenu I recommend MATE lol <FuncProgLinux> There's a similar menu called brisk-menu, but it's third party and has been abandoned since 2021 I think. Last commit was a gsettings fix and the repo was archived <ente>I think it might be this