IRC channel logs
2025-09-17.log
back to list of logs
<FuncProgLinux>If I made a perl-next version and wish to use it, do I need to re-package all of the modules I use? <ieure>FuncProgLinux, Depends how the perl-build-system works. <gabber``>FuncProgLinux: does Perl generate compiled/bytecode files like Python? if it just uses plain Perl script (text) files it could just work to use your python-next as the interpreter. <FuncProgLinux>gabber``: It does. but I noticed that my package `perl-next` cannot reuse others like `perl-readonly` <FuncProgLinux>ieure: I made my variation using inheritance, it worked and I posted it on an issue in codeberg. I was thinking about making a PR with it, but 56k packages it's...a lot <bdju>I'm getting error spam when I have imv show image previews for ranger after an upgrade in the last few days. Seems related to librsvg and libxml2. https://0x0.st/KcgE.png <bdju>/gnu/store/y1155ka4i01y46ndc3miskjjxiyfqira-imv-4.5.0/bin/imv-wayland: /gnu/store/z37dmax9jy01qpsfkkivblxclysfd3c1-libxml2-2.14.5/lib/libxml2.so.2: no version information available (required by /gnu/store/7gaxx8nig0a6fcrlc1l7y8vckicnydn5-librsvg-2.58.5/lib/librsvg-2.so.2) <apteryx>Odd, if I have just one build ongoing, and try to create a 'guix shell', just building /gnu/store/685adz4ks2jqp3vyj1wz1wrg48awpvdf-profile.drv causes guix shell: error: all build users are currently in use; consider creating additional users and adding them to the `guixbuild' group <apteryx>perhaps that old 'building grafts' can exhaust builders issue <gabber``>FuncProgLinux: 56k packages is a lot but better create that PR earlier than later, especially with our dot-release coming up soon (ETA november) <Rutherther>Yes. There is no branch main, you cannot open PRs to it <identity>the error could be more informative than that… <identity>can you people stop working on the same packages at the same exact time as me? i want to submit a pr without my hard work being nullified by somebody who did the same thing slightly faster than me! <efraim>I was beaten by 6 minutes earlier this week <Rutherther>kestrelwx: well it could be crazier if you tried to authenticate :) <efraim>my "favorite" is trying to push commits and failing several times in a row as everyone else is also pushing commits and I need to rebase and rerun make again and again <Rutherther>efraim: you need to rerun make to ensure your changes didn't break anything combined with new changes? <efraim>it's part of the pre-push hook, make check-channel-news, which needs a completed 'make all' first <efraim>it's only the incremental differences, but sometimes it's a lot of files <gabber``>ACTION just pushed some commits in only the 3rd attempt in a row <efraim>I have `git pull --autostash --rebase` in my command history, it's how I normally end up pulling from the repo <csantosb>gabber``: I think something went wrong with latest commits ... <efraim>I have a duplicate for openfpgaloader in electronics and flashing-tools <csantosb>Correct. Additionnally, openfpgaloader is in its 0.13 after d7cb3fcd5 <csantosb>openfpgaloader needs to be removed from electronics, kept in flashing-tools, and updated to 1.0 <AlmostGuixUser>i have been wondering why does guix doesn't support lvm on luks? <gabber``>AlmostGuixUser: the answer to this kind of question is usually: "because nobody made it work (yet)" <gabber``>that being said: will happily review, test, then accept and push your pull requests (: <efraim>gabber``: I took care of it, no need to worry anymore <gabber``>AlmostGuixUser: you reach a broader audience (with more chance of success) if you email help-guix@gnu.org <Rutherther>AlmostGuixUser: luks+lvm is not officially supported as root partition (as in, the partition with /gnu/store) <AlmostGuixUser>just found issue with swap partition, gonna reboot and try again, bb <graywolf>Hello Guix :) How do search paths work together with guix pack? <graywolf>I am trying to pack a program to use on non-Guix system, however it seems that search paths are not used in any way, so the program does not start. <Rutherther>then as with every profile, you need to source the etc/profile inside the profile that is built <graywolf>I am not sure I follow. I build the pack with `guix pack -Rm manifest.scm -S /bin=bin', copy it over, extract, and run dir/bin/BINARY ; I assumed that is the point of the -S flag <graywolf>Hm, so I need to write a wrapper script that will basically do `. dir/etc/profile && dir/bin/BINARY'? <Rutherther>the -S flag links parts of the profile, yes, you need to also link etc if you want to not look in the store for it. Or just link the whole profile with something like "-S /profile=". Yes, making a wrapper script would also work, though it's not how you typically use guix profiles <graywolf>The thing is I do not want to really want to use "guix profiles" in this case; I want to install `mg' so that I have something sane to stick into EDITOR <graywolf>So for that wrapper script will probably work better then first sourcing the profile <graywolf>Oh, that looks quite neat. Will take a look <graywolf>For now a two (well, three, shebang) wrapper script seems to do the trick as well; but would definitely be cool to solve this directly in the manifest, so will check out your code <csantosb>civodul: Ey, may you have a look at #208 in guix science ? Removal of fpga module in Guix broke the channel. <gabber``>csantosb: whoopsie. could we have anticipated that? <ekaitz>I had no idea about yocto but isn't it like guix but worse? :) <ekaitz>apteryx: which burger menu is that "top right?" <apteryx>ekaitz: it's very embedded focused. It feels inelegant and heavy to me, but manages to make reproducible images, and has good traction in the industry (embedded niche). <apteryx>since 140.3.0, pushed some hours earlier, it doesn't work. <apteryx>I tried to debug the underlying JS, but I don't see what's wrong so far. <ekaitz>apteryx: i put a screenshot in the issue so it is more obvious <gabber``>ekaitz: didn't have to work with it for long but it is amazingly messy: everything is defined in a "layer" which makes you look for what is defined where. IMHO guix itself is not *that* far from being a well working alternative. especially with Rutherther's cross-shell thing working <ekaitz>gabber``: "look what they have to do to mimic a fraction of our power" hehe <ekaitz>apteryx: I'm in guix f4e852b and it still works... <ekaitz>weird, i'll try to take a look to that later <apteryx>I'm happy if it's just broken for me ^^' <csantosb>gabber``: I don't think so, this is just the way it is; these are two changes to be applied in sync, more or less <Rutherther>gabber: I mean yocto is about building embedded systems, my cross-shell thing is for obtaining compiler and packages for compiling in a shell, so in other words it's for making an environment for compiling packages you didn't make a guix package for. I initially decided to make it because I wanted to use buildroot with packages from guix. buildroot is an alternative to yocto, it's more lightweight, built on kconfig and makefiles <Rutherther>s/building embedded systems/building os for embedded devices/ <apteryx>assad: there's a #nonguix channel for related questions :-) <apteryx>but I believe their home page covers it <Rutherther>Guix can also be used for building os for embedded devices, but it's not really it's goal, that's why I wouldn't say yocto and guix are similar projects, guix is more generic build system <apteryx>Guix needs more cross-compilation support, needs to reduce the closure size of its packages, to compete in the embedded world <Rutherther>yeah, definitely, the base system you make with buildroot is like 100 MB, while Guix has more than a GB <apteryx>Although routers with 8 GiB of storage are now a thing. <futurile>assad: you should ask in the #nonguix channel - and a google search will turn up some articles <jacobk>I ran into a problem with CA certificates, and I was able to fix it by following the instructions at <https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html>, but is this something that should ideally be included in the dependencies for the program? For example in my case it is pmbootstrap that fails without CA certs; should I open a bug that pmbootstrap has an undeclared dependency on nss-certs? <jacobk>I understand this probably only happens on a foreign distro (Trisquel in my case), so maybe it would be better for distros to handle the installation of those packages in the same way that Guix OS would. Though, it seems like the necessary environment variables can be arbitrary, so maybe it's not possible for the distro to know what to do in all cases. <civodul>so… Emacs (+ EXWM) just crashed, and that happens quite frequently lately <sneek>civodul, you have 1 message! <Rutherther>civodul: I don't use exwm, but I can confirm emacs crashes for me. Sometimes it can can crash multiple times almost instantly. Usually crashes when I click or when I pop up a frame <Rutherther>it has been happening for a few weeks for me. It seems it crashes less when I don't use a daemon, but still it does crash <Rutherther>I have coredumps, though I probably don't want to share them. I am not sure what secrets I could have there. Here is at least backtrace https://paste.debian.net/1397025, though for a version without a lot of debug symbols. I should probably compile emacs with debug symbols to shed more light onto this <civodul>Rutherther: thanks! what about ‘thread apply all bt’? <civodul>we have this libxml2 “situation”, which looks pretty bad (with loader warnings) <Rutherther>yes, but the crashes are definitely happening to me before libxml2 graft <Rutherther>(I can check once more, but I am pretty sure I have upgraded past libxml2 grafts only today, I was holding back until enough issues are found out & solved/I don't care about them) <FuncProgLinux>gabber``: The latest version of perl works OK with pretty much the same instructions as used on v5.36 but it's those 56k packages that I'm worried about :( that includes the kernel <Rutherther>I was on 2e476f9ad87e99a2a819118d2eaed5bcf3c8d309 (5th Sep) till today, looks like the initial merge of libxml2 grafts (through changing packages that propagate libxml2) happened at Sep 4th https://codeberg.org/guix/guix/pulls/2319, so I was wrong, I could've been using the grafted version of libxml2 <Rutherther>civodul: I don't think the warnings themselves are a problem. Though the versions are ABI-incompatible, but I don't think the warning itself captures that in any way <FuncProgLinux>I was reading through the libxml issues but couldn't understand. Why did we upgrade to a non abi-compatible version? :L I read something about a CVE but was that the only way to go? <Rutherther>FuncProgLinux: because no one knew it was abi-incompatible <FuncProgLinux>I'm reading on foreign rolling distributions but no one seems to be "free" from this problem and most are rebuilding various packages <FuncProgLinux>Second question, how can I help with this issue on the MATE side? So far using the libxml2-next-for-grafting fixed the libmateweather conflicts. The only thing that comes up to my mind is to upgrade the packages and report the common GNOME ones to Lily <tschilp>Do you have an idea how to fix keyboard layout settings in Gnome? Since my reconfigure yesterday, headless ttys properly use what I have set in operating-system. Gnome settings show "de" correctly, but I actually appear to have "en". If I click "input sources" in the settings, I for some reason can only chose between "Arabic", "English", "French", "Portugese", "Russian", "Spanish". Interesting enough, everything properly translated to <tschilp>German... Are there any new additional packages I am missing, maybe? I have not been reconfiguring for some months, so I might have gotten a bit off track... <Rutherther>the conflicts weren't caused by ABI-incompatibility, it's a different topic. I am not sure what you can do, the best step forward is ungrafting it, that's already happening, the CI should be building it. As for what to do until that is merged, fixing the packages that are broken because of the ABI-incompatibility. Ie. upgrading the version they are built with instead of grafting, patching them somehow etc. <tschilp>But did not see anything specific in the pull news... <Rutherther>tschilp: that is caused by libxml2 grafts. For now you can use setxkbmap instead of relying on Gnome's settings <Deltafire>tschilp: i've rolled back to a commit before all the libxml2 madness <Deltafire>will upgrade once the world rebuild is complete <FuncProgLinux>Rutherther: I was looking at parabola packages, they seem to maintain a mainline libxml2 and libxml2-legacy but no patches there. Maybe some upgrades are necessary to "just build" with newer versions? <tschilp>Aaa -- so ieure yesterday meant both, chromium AND keyboard layout ... I thought libxml2 just had an influence on that one.. <tschilp>Rutherther, thanks for the hint at setxkmap, will need to put it into my profile. training fingers is also OK for now... <simendsjo>I see a very strange substitution error in xinit where startx has a broken linux for mcookie. But what is patching this? My guess would be a bug in gnu-build-system, but I'm not familiar with this code and don't have time to dig into it. But why then haven't anyone else experienced it...? https://codeberg.org/guix/guix/issues/2763 