IRC channel logs

<Tadhgmister>hello, when I try to use `guix system image` with a platform set to arm it fails to compile glibc-mesboot and I was wondering if that is because I'm specifying something wrong or whether you just can't cross compile a system image

<Tadhgmister>I ended up doing `--system=armhf-linux` and then removing tests of a few packages that the tests failed on qemu

<freakingpenguin>I think cross compiling isn't heavily used compared to qemu so breakage wouldn't surprise me.

<Tadhgmister>freakingpenguin: I get that but the default settings for system image breaks when you specify another architecture?

<cow_2001>freakingpenguin: what is "(gnu ci)[all-packages]"?

<cow_2001>it looks like some sorta commonmark link

<cow_2001>no, commonmarks got the parentheses and square brackets switched

<Tadhgmister>cow_2001: `;;; Commentary: This file defines build jobs for Cuirass.` is what gnu/ci.scm says

<cow_2001>oh oh

<freakingpenguin>cow_2001: Just a way to say the all-packages function in the gnu ci module

<zeropoint>dthompson: I'm glad I'm not the only one :)

<cow_2001>i tried cd gnu/ci[tab][tab][tab] and didn't find a dir... should have looked it up with an ls

<cow_2001>ACTION is a dingus

<freakingpenguin>I might be making up the [] part of the notation, guess if it failed the very first time I used it it's not very good haha.

<pomelo> hello, is there a way to search online for precompiled binaries present in the guix repositories by architecture? I'd like to see which precompiled binaries are available for i686

<Tadhgmister>when you say repositories, do you mean substitute servers?

<freakingpenguin>pomelo: Online, ci.guix.gnu.org has a search bar in the top right with instructions to check for specific systems.

<freakingpenguin>From the CLI, guix weather --system=i686-linux <package> should do what you want if I understand correctly.

<Tadhgmister>freakingpenguin: the thing is that the "cross compiling" the system image falls during setenv step of `glibc-mesboot` because `(assoc-ref inputs "libc")` gives #f and that is invalid to pass to string-append

<freakingpenguin>Tadhgmister: There might be a bug there. I don't /think/ anything says cross compiling system images is invalid.

<Tadhgmister>can be reproduced with `guix build --target=arm-linux-gnueabihf -e "(@@ (gnu packages commencement) glibc-mesboot)"`

<Tadhgmister>the problem is that that package is a dependency of 31000+ packages so changing it to use a different way to grab native inputs instead of normal ones causes basically everything to recompile

<pomelo>freakingpenguin: sorry to bother you with this next question, but in the website you linked, i searched for icecat, on i686, and it said the status on the master specification susseeded, however, on the vm i installed guix, when i type guix install icecat, it says that "icecat@102.5.0-guix0-preview does not support i686-linux". Why is this?

<pomelo>succeeded*

<freakingpenguin>Is icecat 102.5.0 still packaged in Guix? You might need to run guix pull.

<freakingpenguin>Icecat is at 115.10.0-guix0-preview1 for me.

<pomelo>ah, i assumed it must have been because the release is outdated

<pomelo>and unrelated question then, it's taking a reaaaaally long time to update the system, is this normal? or is this come mirror problem? if it's the later I'll search how to change mirrors

<freakingpenguin>There might be some fixes for i686 between the two but that's just a guess.

<freakingpenguin>It can take a while to run pull if you're really out of date. Every new commit needs to be authenticated. I think it's usually on the order of minutes though, not hours.

<pomelo>well, i am running on a virtual machine, but i also think it might be a mirror problem, as i live quite far from europe and the usa

<pomelo>anyways, thanks for your answers, I will check when my VM updates if I can install the binary substitutes

<Tadhgmister>how would I figure out what additional modules I can stick in the initrd for my operating system? it doesn't seem to be able to find the usb device with the operating system and I'd like to identify if there are additional modules that could be loaded before I assume I need a non libre kernel

<Tadhgmister>oh wait, PCI is needed for usb devices right? I remember seeing people say edits to the linux kernel were needed to fix some issues so just loading existing modules may not do it....

<dthompson>zeropoint: :)

<Tadhgmister>when you are compiling something for the host platform do the `native-inputs` end up in the `inputs` list but when cross compiling they don't?

<Tadhgmister>that would explain the percieved bug in commencement.scm about `glibc-headers-mesboot`

<coyote>native inputs are the ones that are only needed during building, so they do not appear as inputs for the target architecture i'd assume

<Tadhgmister>yeah, I'm still trying to figure out how to report the bug, using `system image` with a different platform tries to cross compile `glibc-mesboot` which fails because it is using the inputs list to refer to a few native inputs

<Tadhgmister>so either it shouldn't be trying to cross compile that or whether the package should be changed, cause nearly every other package depends on the bootstrap process so changes to that package would be severely delayed

<pomelo>hmmm, on my vm, trying to do guix pull just hangs after it gets to 95%

<pomelo>building /gnu/store/[...]-guix-packages-base.drv

<coyote>that might take some time if you're upgrading from a quite old version i think

<Tadhgmister>for the longest time I thought my cross compiling thing was hanging, turns out it was just rerunning gcc over 20 times to check whether certain flags worked and that was super slow with virtualization.

<Tadhgmister>I don't remember how to get it to show you the live building details for pull, but it is very possible it isn't hanging

<pomelo>ah well, i'll just install it on real hardware when i get a wifi card that works with linux-libre

<digitalrayne>hello, i have been working with GuixSD and have been trying to land on a workflow for making changes to the guix main git repo, rebuild ISO images from the local repo, and then test the changes. i keep getting stuck on authenticating commits when building an iso with local changes. what kind of workflow is needed to authenticate local commits or skip authentication?

<digitalrayne>the commits which fail to authenticate are my own commits, and even if i add a trusted gpg key fingerprint to .guix-authorizations, i still hit this problem i think because my key is not trusted by an existing key, so it is ignored. is there a better local development flow i could use?

<freakingpenguin>digitalrayne: I don't know the workflow for building the installer ISO, but is --disable-authentication applicable?

<digitalrayne>freakingpenguin, i think that would solve the problem, but my testing showed 'guix system image' does not support this flag, and then i found an issue for it https://issues.guix.gnu.org/57229

<peanuts>"guix system image forces commit authentication?" https://issues.guix.gnu.org/57229

<freakingpenguin>I see what you mean. As a workaround you could try overriding authenticate to #f in (gnu build-system channel) for now, but that's unfortunately the best I've got. Good luck!

<digitalrayne>oh thank you, that's helpful! I'm fairly new to how guix channels work so I'll give this a try.

<digitalrayne>also i have not looked at <build-system> docs before, so I'll read all of that, too

<PotentialUser-6>hi. it seems that the link of latest development image is broken.

<KE0VVT>efraim: https://lists.gnu.org/archive/html/help-guix/2024-04/msg00089.html

<peanuts>"Audio on Chromebooks" https://lists.gnu.org/archive/html/help-guix/2024-04/msg00089.html

<sneek>adanska: Greetings :)

<pomelo>so i found out a random wifi card i had lyinf around works with linux-libre! which means i'm off to trying to install this on real hardware

<adanska>Hi Guix!

<sneek>Welcome back adanska, you have 1 message!

<sneek>adanska, jpoiret says: It's in (gnu tests install), you can use `make check-system TESTS="..."` as detailed in "(guix) Running the Test Suite"

<adanska>ok, thanks!

<adanska>sneek: botsnack

<sneek>:)

<Guest8775>Hello!

<sneek>adanska: Greetings!

<dariqq>why is the rust package ecosystem such a mess. Currently tryingto update my wip package for fractal to the latest release released yesterday and have to add 10 000 lines of more rust dependencies. And it will probably still not work because it depends on some crates at some random commits that are almost impossible to package for guix.

<dariqq>how do other distros deal with this? or do they just give up and let cargo handle that

<adanska>dariqq, yes, thats what nix does at least

<cnx>yea nixpkgs also include patchelf'ed binaries so it's not exactly a standard to strive for

<civodul>o/

<cnx>btw since guix versioning scheme include a patch number, could there be more often releases?

<cnx>it sould help foreign distros to (decide to) package more recent guix and on guix system, user can use the system guix

<cnx>(the one built by guix system reconfigure)

<cnx>i'm still trying to figure out a way to avoid having to run guix pull for every user

<dariqq>ok i am giving up now. The update would also need newer libadwaita and gtk. and afterwards i ran into more rust compatibility issues that i don't really want to look into now.

<dariqq>there used to be a release tarball which vendored the rust crates but that seems not available (yet?)

<futurile>Cargo makes Python look sane heh

<bienjensu>dariqq: I've had similar issues packaging rust. Packaging for guix tends to reveal (and break) packaging magic. Cargo hell is different but not necessarily better than cmake hell. I think I was trying to package bevy

<dariqq>the (recursive) importer helps and i've even written some (Terrible) guile code to generate the #:cargo-inputs field from a Cargo.toml using the toml parser currently on python-team branch. Maybe this could be adapted to generate full package-defintions from a lock file instead to save my sanity. This sounds definitly more fun than to dive deeper into cargo hell

<futurile>that sounds cool - anything that reduces the burden is useful

<bienjensu>dariqq: There's a video of Tropin making something similar for Elixir here if you're interested https://yewtu.be/watch?v=s3VO9Kb0sHw :)

<dariqq>although i am not a huge fan of that as it seems like the equivalent to giving up on traditional dependency management

<dariqq>bienjensu: Will have a look, tthank you

<taeltydes>hi all. is anyone aware of any docs that might be helpful in bundling packages within a service definition?

<taeltydes>on second thoughts, I should probably take a look at some source ... my brain works halftime on a friday.

<JonRob>Hi - I'm now trying to get my head around a simple package. I've created https://pastebin.com/ygUyeQ7n in `~/src/guix-channel/packages/kubectx.scm`. /src/guix-channel is a git repo, if that's relevant. I've then run `cd ~/src/guix-channel && guix build -L. kubectx` but just get `guix build: error: kubectx: unknown package`. I assume my package

<JonRob>definition or path is wrong, but I'm not sure how?

<peanuts>"(define-module (kubectx) #:use-module (guix packages) #:use-module (guix d - Pastebin.com" https://pastebin.com/ygUyeQ7n

<civodul>JonRob: hi! it should be ‘guix build -L packages kubetcx’

<civodul>or, alternatively, rename the module from (kubectx) to (pacakges kubectx)

<civodul>er, (packages kubectx)

<JonRob>let me try that - thanks

<dariqq>JonRob: also i think your parens are not right. the build-system should be at the same level as source

<JonRob>dariqq - thanks I just noticed that and fixing that too

<JonRob>thank you both

<JonRob>thanks I got that to work

<dariqq>hmm the guix toml parser can't parse array-of-tables yet which makes this a bit more interesting now :)

<futurile>Don't forget it's the Guix online patch review sessions tonight: 18:00 UK / 19:00 Europe / 13:00 New York - https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

<peanuts>"Group:Guix/PatchReviewSessions2024 - LibrePlanet" https://libreplanet.org/wiki/Group:Guix/PatchReviewSessions2024

<civodul>yay!

<civodul>futurile: BTW, that page is full of tips that’d be worth adding to the Cookbook

<nat-418>I am trying to send in my membership form but I don't see an email for the treasury.

<nat-418>Also what is the IBAN for the foundation ?

<futurile>civodul: yeah - noted - but not committed to ;-)

<RavenJoad>Does anyone have any experience debugging convert errors for SVG -> PNG for app icons? I have an issue where the output PNG is completely blank and cannot track down the issue. I'm asking here because it happens both in a Guix build and when I manually use it from my shell.

<futurile>RavenJoad: not really - can you convert it in any program - like I don't know gimp or something?

<RavenJoad>futurile: I can with inkscape. In fact, that is what imagemagick's convert is doing under-the-hood. If I run 'convert -verbose icon.svg icon.png', it runs inkscape. If I run that inkscape command, it outputs the correct PNG.

<futurile>RavenJoad: so the image isn't corrupted as far as imagemagick's concerned then. How are you converting it "from my shell" that is failing?

<RavenJoad>Image is not corrupted in any way. In my shell I am using the same command as in the build. 'convert -background none -resize 512x512 ./icon.svg ./icon.png'. You can add a -verbose in there to see what is actually happening.

<futurile>oh maybe I misunderstood your first comment. So basically you can convert it without any problem (using imagemajick). But it's failing to convert when you do it in a Guix package? I guess Guix uses something else to do the conversion

<RavenJoad>futurile: No, imagemagick fails both in my shell and in a "guix build". But imagemagick shells out to inkscape to convert SVG to PNG, which _does_ work in my shell.

<futurile>oh wow - that's so odd

<RavenJoad>Imagemagick fails the same way in my shell and "guix build" (producing just a white square with the corret size), so I thought it may be something Guix-y.

<futurile>Yeah - I would think it's not because you're running imagemagick in one way and 'it works', and 'in another' and it doesn't - so it sounds like there's some difference in the way it gets called when it's shelled out to through Inkscape

<futurile>I guess it could be the version of imagemagick that Guix has - has some odd bug

<futurile>I did a search on issues.guix.gnu.org - didn't show any mention - but give that a go just in case

<RavenJoad>futurile: I checked if the file works with imagemagick at all. I used imagemagick in nix, and it produced the right thing. So the file is fully correct. Maybe a version difference? Nix has imagemagick 7.1, Guix has 6.9.

<futurile>ah that sounds like it then

<RavenJoad>Guix has an extra step in the convert pipeline, an "mvg" thing. I might just have to fall back to using inkscape directly for now.

<weary-traveler>how well does julia work in guix? do all packages need to be installed via guix?

<RavenJoad>futurile: I narrowed it down. It's not imagemagick actually. It's inkscape.

<bdju>no fastfetch package yet?

<dlowe>I'm having the hardest time trying to package a system that a) uses cmake and b) also uses another library that doesn't use cmake. I can't make the cmake package see the non-cmake library

<dlowe>I'm sure most of this is my unfamiliarity with cmake

<dlowe>most of the other cmake packages in guix can find their inputs fine, though there are an amusing number of inserted phases called "fix-cmake"

<dariqq>managed to write something to generate #:cargo-inputs from a (jsonified) cargo.lock file. Though git sources don't work because cargo-build-system deems only gzipped tarballs as valid. Also it t would be nice if I could use the lockfile from the origin for generating the packages but I don't think this can be done easily

<freakingpenguin>Anyone here use guix deploy -x to reboot machines after upgrading? I find -x -- reboot throws an error at the first machine once the SSH connection drops.

<freakingpenguin>Restarting a group of remote machines seems like a common use case, so I'm curious if I'm just missing something and there's another way to reboot.

<taeltydes_>have you tried using tmux?

<freakingpenguin>taeltydes_: Sorry, how will that help?

IRC channel logs

2024-05-03.log