IRC channel logs
2024-03-19.log
back to list of logs
<festerdam>How long does it take for a message to appear on a mailing list? Do I need to be subscribed? I've sent a message to bug-guix@gnu.org 6 hours ago, and it doesn't yet appear to me in the mailing list. <festerdam>Or does the subject need to have a specific format? <PotentialUser91>festerdam: if it's your first message it can be several hours, at least that's what I was told when I submitted my first issue <hapst3r>When preparing to hack on guix and following the manual (bootstrap, configure, make...), does the `make check`-step need to be executed as root? <wigust>hapst3r: afaik no steps need to be executed as root, including `make check` <wigust>also `make check` is not required unless you need to run tests <hapst3r>wigust: but i guess I should still not proceed if that step throws errors, right? <wigust>hapst3r: for the package update it is enough to build it, and if you use it run it would be great <wigust>./pre-inst-env guix build PACKAGE <hapst3r>Yeah, that's along the lines of what I want to do (using `guix refresh -u`) <efraim>ulfvonbelow: for rust on i686 currently you can cross compile to it but no native support currently <ulfvonbelow>hmmm... so I guess to actually use a package that depends on rust on i686-linux I'd have to cross-compile the package, then use 'guix archive --export' or 'guix copy' to send it over to the other machine? Is there a way to use 'guix package' to then install that? For example, could one do on an x86 system: guix package -i --target=i686-linux --system=x86-64-linux package-that-uses-rust (or whatever those proper system specifications <ulfvonbelow>are) and have it install the appropriate package exported from the x86-64 system? <ulfvonbelow>(iirc one can install the store path directly if they have it, but then that doesn't include things like search paths) <efraim>I guess, I'm not sure of a good way to do it. I suppose you could try to define a package with #:system as x86_64 and #:target as i686 and use that <ulfvonbelow>welp, the cross-build attempt errors out with "build system `python' does not support cross builds" <civodul>lemme know if you’d like to get involved <civodul>rekado: hi! just tried the ‘wip-js+css’ branch of Cuirass, that LGTM! <cartographic>civodul: Sorry for the delayed (!) response. I'll have a look into the GUIX_LOCPATH when I get a moment. Currently it is set to /home/me/.guix-profile/lib/locale, inside of which there are various versions (?), 2.29, 2.31, 2.35, inside of which there are various locales but none that match mine - en_GB.UTF-8 <zamfofex>Hello, Guix! I just wanted to complain a bit, I hope it isn’t taken wrongly: I feel like two of my biggest issues with Guix are that packages built by a given user can be seen by any user on the system, and also the difficulty in running prebuilt binaries for other systems. <zamfofex>Now, the first one is only ideological, because I’m the only user on my system, but the second one is a legitimate limitation for me. Oftentimes I want to run programs that are difficult to package in Guix, for example. I wish the mindset towards that kind of issue was different. <efraim>zimoun: I was able to build julia using openblas in place of lapack on x86_64 and aarch64 <zamfofex>attila_lendvai: Sometimes the issue is a bit more foundational. Like, of course I can use a custom build system that runs ‘patchelf’ on binaries or run ‘patchelf’ myself, but sometimes I just want to be able to use e.g. pip or npm and install packages that pull in native binaries that I want to work naturally. Like, I wish Guix could be compatible with FHS by default, without the need of a container for it. <efraim>I bet you could hook something up with debootstrap to create a debian chroot <zamfofex>I have always thought that a way to solve both of my issues might be to use chroot in some form when a user logs in. Imagine that each user has its own root directory on the system, and thus e.g. ‘guix install’ or ‘guix home’ can install packages relative to that root (e.g. ‘/etc/guix/home/profile’) and then files like ‘/bin’ could be symlinks to the directories within those profiles. <efraim>create a guix profile and then chroot into it? <zamfofex>Well, the problem is that all files would be read‐only, no? Besides, it’d contain symlinks to files on the store (outside of the root). <zilti>I also get "Issue not found" for patches I sent in just yesterday now. Is there something going wrong, or are the servers just so overloaded? <civodul>cartographic: i see; make sure to pick one of the locales that’s available there <civodul>just thought about a hackathon/game: get the smallest Guix System image with a POSIX shell + utilities, an SSH server, a DHCP client <cartographic>civodul: thanks for helping me debug this. Yes i will have a go when i find a minute <civodul>the OpenWrt folks manage to squeeze that in less than 10 MiB <civodul>efraim: yes, that’s probably part of the answer <civodul>but i suspect we’d still be far from what OpenWrt achieves <efraim>I'd like to try to "fix" my gparted image to be back at almost CD size, it seems to have ballooned to 2.5 GB <efraim>`guix system size` of my base gparted.tmpl is 1.5GB, that's without any minimizing of packages or their inputs <yewscion>Hello Guix, I'm still suffering from an issue with the state of texlive packages on Guix. What was once a collection of packages that allowed my work to continue smoothly is now completely nonfunctional, and I don't have the bandwidth or disk space to migrate to the full texlive package. Specifically, I'm getting this error: https://paste.debian.net/1311251/ It seems to be looking for `mktexfmt`. Any ideas? <civodul>yewscion: hi! can you show how to reproduce the error? <civodul>FWIW i use the modular texlive packages routinely and it works great for me <yewscion>civodul: I can show You my package list, but paring down to a MWE is difficult as I am apparently already missing something, haha. <yewscion>civodul: I haven't seen this new version yet; I still have individual packages selected in my profile. I bet swapping to the ones mentioned there will solve the problem. <civodul>yewscion: you’re missing texlive-scheme-basic, and i don’t think it can work without it <civodul>can you check whether it works when adding texlive-scheme-basic? <yewscion>civodul: On it, reconfiguring now. Thanks for the help! <yewscion>civodul: Yup, that seems to have been the issue. Glad it was so simple! <civodul>yewscion: awesome, glad that it worked <reedm>I'm trying to write a package definition for Gleam (an Erlang VM with a compiler written in rust). I've never packaged any rust apps with Guix. I'm getting an the following error: https://paste.debian.net/1311268/ This happens whether I have rust-async-trait-0.1 in #:cargo-inputs or #:cargo-development-inputs. <reedm>Does the cargo package version in the "rust-<package>" guix packages have to exactly match the version specified in the Cargo.toml file for the cargo-build-system to find it? <reedm>the Cargo.toml file for v1.0.0 of gleam specifies async-trait = "0.1.51" but the latest version in guix is 0.1.77 <Altadil>I did add the setuid-programs field to my system declaration, by copying from the example (and then reconfiguring). <Altadil>But I still need to use sudo to be able to launch the VM. Is there a way to check if the suid bit has indeed been set properly ? <zamfofex>civodul: Have you ever heard of “Damn Small Linux”? It is just 700MB (used to be 50MB) with a lot of programs packed in (including WMs and browser). I feel like surely Guix can fit into about 50MB if it waives a lot of those kinds of programs if someone really tries! 🤔 <PotentialUser17>Quick question: is anyone here familiar with how the official guix build farm works? I'm trying to set up a small build cluster locally and just want to make sure I'm going down the right path. My thought was to have a low power machine using "guix publish" to distribute substitutes and for any substitutes not on the machine it will use "guix <PotentialUser17>offload" to have a more powerful machine run the build. The only thing I'm not sure about is if a substitute is missing on the machine running publish, is there a way to have it automatically run a build command that gets offloaded to one of those other machines? I'd like to avoid having the machine that requests the substitute from the publish <hapst3r>I am trying to update the mixxx package (FLOSS DJ software) but it fails due to a cmake error I don't quite undderstand. I am not at all versed with building and would love to get a better understanding of the whole process in General and in the context of Guix in particular. <hapst3r>Can someone recommend material (maybe even specific to building with cmake in the context of Guix) <hapst3r>Oh, and I'd also love to know if there are resources on the setup of a "proper" build environment both for New packages and updates of existing packages. <hapst3r>(Currently reading the cookbook, sorry for the spam!) <old>for the guile-build-system, how would one prevent to compile and install guix related file: e.g. .guix/modules/my-package.cm and guix.scm <old>this is typically a probleme I guess when building from a checkout <old>sneek: later tell drupol send me your mail in private ; I have feedback for you <hapst3r>podiki: I'm not sure if I want to do what is described there if what I want to do is create and update packages. Then, I wonder if I need to follow all the steps describes. Finally, I wonder if - when `make`-ing guix, I need to pull in all the dependencies described in the manual section you linked. <hapst3r>But possibly that will be clarified further in the Guix cookbook :) I still take recommendations regarding resources/Materials! <podiki>you can create packages separately of course (your own channel, or just a scheme file), or have updated versions, but if you want to contribute them back to guix it'll make sense to have patches applied on top of a guix checkout to send <zamfofex>sneek: later tell civodul: Well, after trying for a little while, I got something that shows “329.5 MiB” with ‘guix size’ after ‘guix system build’. If Guile didn’t appear three times (??!!) in the closure, I feel like that could be cut significantly. <zamfofex>sneek: later tell civodul: I haven’t bothered trying to run it yet, though, maybe it doesn’t even work. Maybe this might seem interesting in some way, though. I can share the file I came up with for it, if you feel like it might be useful.