IRC channel logs
2024-05-24.log
back to list of logs
<freakingpenguin>You know things are "fun" when you have (bootloader (bootloader (bootloader ...))) <vagrantc>freakingpenguin: installer #f ... might work <vagrantc>i vaguely recall using something like that once upon a time <freakingpenguin>They mention --no-nvram and --force-extra-removable options which could be an "technically correct" way to handle it. <freakingpenguin>vagrantc: Hah, turns out there's already a thing for this because of course there is. grub-efi-removable-bootloader. <Googulator>Hi! I'm working on a bootstrap of Guix on top of a live-bootstrap environment, and have got as far as getting guix-daemon to run and successfully build packages. <Googulator>Now, guix system image -t iso9660 gnu/system/install.scm --no-substitutes is failing with a test failure in guile-3.0: <Googulator>ERROR: web-server.test: GET / - arguments: ((getaddrinfo-error -2)) <Googulator>ERROR: web-server.test: GET /latin1 - arguments: ((getaddrinfo-error -2)) <Googulator>ERROR: web-server.test: GET /user-agent - arguments: ((getaddrinfo-error -2)) <Googulator>ERROR: web-server.test: GET /does-not-exist - arguments: ((getaddrinfo-error -2)) <Googulator>ERROR: web-server.test: GET with keep-alive - arguments: ((getaddrinfo-error -2)) <Googulator>ERROR: web-server.test: POST / - arguments: ((getaddrinfo-error -2)) <Googulator>This seems very similar to how guix-daemon failed when trying to download packages with /etc/services not populated - except that it's happening within the guile-3.0 build, after much of Guix has already been built. <Googulator>Any ideas if this is a recent issue (that maybe got fixed in an even more recent Guix build)? <Googulator>(the fork was needed because live-bootstrap cannot build Guix's documentation at the moment; also, a future goal is to remove the dependency on the downloaded bootstrap binaries "bootstrap-guile", "tar", "xz", "bash" and "mkdir" in favor of reproducible and fully bootstrapped versions built within the live-bootstrap environment) <bigbookofbug>for packaging a rust program, what's the best practice tend to be when a crate version it depends on isn't in the guix repository? i've been trying to package eww but it seems to have various crates it depends on that there's not an associated guix package for, which is causing cargo-build-system to fail <freakingpenguin>Anyone with sysadmin powers mind checking on the aarch64 system substitute for linux-libre-6.8.10-guix.tar.xz? It looks like it's available on bordeaux but corrupt, which causes issues.guix.gnu.org/71160 <Ironsmith>thanks freakingpenguin! this one seems more up to date too, it has librewolf while toys.whereis.xn-q9jyb4c doesn't <ayatsfer>ah, I it has already been mentioned earlier <unwox>Ironsmith: oh, thanks for the report. now the toys site should be up to date too <flypaper-ultimat>efraim: hey, your commit 02427ea997e7218bccabb204d78b3469a63f32a7 (of yesterday) where you added manpages args to gssdp, broke gssdp-1.4, could you add a `(arguments (substitute-keyword-arguments (package-argumenst gssdp)) ((#:configure-flags _) ''()))` to gssdp-1.4 ? <gabber>trying to re-configure my guix home i get "profile contains conflicting entries for coreutils" - how can i figure out *which* profiles contain the conflicting entries? <gabber>... and i'm having this somewhat strange issue (again) that my weak laptop insists on building a big package (or derivation of it) even though `guix weather PACKAGE` shows it's 100% available form my beefy build station. did i misconfigure my setup or is there some nasty bug somewhere? not sure where i could check <cbaines>gabber, the easy way to debug this is do guix build /gnu/store/... for the thing that should be substituted <gabber>cbaines: huh, this miraculously works! so is there a bug which makes `guix home reconfigure` build differently than `guix build FOO`? <cbaines>not that I know of, but I don't use guix home <gabber>interestingly enough: i trying `guix build PACKAGE -n` resulted in: "..derivation will be built". `guix home reconfigure` then actually tried to build. `guix build PACKAGE` made guix download the substitute <gabber>should i file a new bug report? i have the impression the search functionality on issues.g.g.o ORs all my query strings which unfortunately doesn't help me finding if there is a similar report already <freakingpenguin>gabber: I did see some interesting behavior once where a package built directly worked, but as a dependency for another package Guix Home was using did not. In that case it was because the target system was different in Guix Home, x86 32-bit for a multiarch container. <freakingpenguin>If the derivation checksums in build vs. home are different it might be something like that. If they're the same then I have no idea.a <futurile>Yeah - I'm not a naturally creative soul - but hopefully it's good enough for anyone who missed it! <freakingpenguin>futurile: I'll resist the urge to comment "First!". Thanks for sharing! <peterpolidoro>hi, is there an example repository with channels.scm and guix.scm files to compile and package the most basic hello world example in c? <peterpolidoro>the hello world gnu example at mirror://gnu/hello/hello-2.12.1.tar.gz contains lots of files <gabber>peterpolidoro: you can generate your channels.scm through `guix describe --format=channels`, for a manifest a simple `guix shell gcc-toolchain` should suffice <futurile>freakingpenguin: it being Youtube you'd be increasing the average intelligence of comments! <peterpolidoro>gabber thanks! I was hoping for an example guix.scm file instead of a manifest though that shows the proper way to package local c source code. I just want to use it as a template and to show it to others as an example of how to make local packages of c programs <freakingpenguin>There's really two parts to it. One is have a package with a working build system, two is to add the Guix icing on top <peterpolidoro>like Ludovic's blog example of guixifying a repository, I am just curious if an example repository exists that shows best practices for a small c program <futurile>peterpolidoro: if you do a search for 'guix.scm' you can find some other examples <peterpolidoro>futurile those look great I will read them in detail thanks! <futurile>peterpolidoro: you're right there's no 'simple local C project example' though - you'll have to piece it together! <peterpolidoro>are there examples out there that show recommended directory layout for local C projects? <civodul>bayfront has system generations as old as June 2020 <civodul>i guess we can reasonably delete some of these :-) <ieure>Kolev, I run NextCloud's Docker image and it works well, you might try that approach. <Kolev>ieure, do you have instructions on how to do it? <ieure>Kolev, It's the most common way to run it, I followed Nextcloud's docs. <Kolev>ieure, but running a container is different on Guix. <freakingpenguin>Oh man, building this riscv VisionFive2 image sure is a process! Probably 12+ hours of build-time so far. <Ironsmith>freakingpenguin: are you building the Debian or OpenWRT image that starfive publishes? or are you building a guix image? <freakingpenguin>A patch just was merged for a proper Guix image I want to test out. :) <bdju>is there any reason the yt-dlp package stopped getting updated some months ago? <ieure>bdju, There are patces for it pending review, but they've been sitting so long they're stale and need to update to the latest. <ieure>tl;dr patch review is pretty broken <bdju>ah okay. thank you for the info <ieure>Submitted in January, I reviewed a month ago, got no response. <ieure>Feel free to pick that work up! I found the patch because I was about to update it myself, but then saw someone had beaten me to it. <bdju>have never managed to get comfortable with guix packaging work, just wanted to make sure it wasn't forgotten. glad to know at least one other person cares about it <ngz>ieure: Is it still up-to-date? <ieure>ngz, Is what still up-to-date? <ieure>ngz, No, that's why this whole discussion came up. Weird question. <ieure>Version in Guix now is 2023.10.13, patches are for 2023.12.30, current version is 2024.04.09. <Kolev>ieure, could you make a guide on how to get a Nextcloud container working in Guix System? <graywolf>Hi :) Where is setting up the jail for builder done? Or in other words, if I wanted to add another environment variable like `out', where in the code should I look at? <freakingpenguin>graywolf: Are you talking about setting an environment variable during a package build process? <ngz>ieure: I added latest updates for python-urllib3 and python-websockets in "python-team" branch. Hopefully, it will ease updating yt-dlp once the branch is merged into master. <graywolf>freakingpenguin: No, for the executed builder itself. For example #$output expands into ((@@ (guile) getenv) "out") in the builder script. So I am curious where the "out" variable is set, and how I can set additional ones. <ieure>ngz, That's good news. Seems like there's a lot of work stuck in various branches right now. <ngz>ieure: There is. It seems that the first in the queue, "gnome-team" is in good shape. It may be merged very soon. <sughosha>Hi all, hope you are doing fine. I am facing an issue with (local-file) function. If the string is just a "string", no problem. But if the string is a (string-append) string, a warning is given that resolving file relatively to the current directory. What is then the difference between a normal string and what (string-append) returns? https://paste.debian.net/1318016/ <freakingpenguin>graywolf: From what I can tell "out" is added in add-output-paths in (guix derivations) and the daemon actually "sets" the variable in derivations.cc. You'd probably want to look at user+system-env-vars with seemingly handles most other variables in the same way. <freakingpenguin>sughosha: That's because the macro was designed to handle string literals differently. string-literals are relative to the source file, non-literals are relative to the current working directory. <freakingpenguin>If you have a non-literal string that you know will be valid when you run your script, you can wrap the non-literal in assume-valid-file-name, like (local-file (assume-valid-file-name foo)) <graywolf>freakingpenguin: Thank you very much, I will inspect those places ^_^ <freakingpenguin>graywolf: A bunch of other variables are set in build.cc, but most of those seem to be just to isolate the build. <sughosha>freakingpenguin: Thanks for clarifying. assume-valid-file-name worked for my case. <ngz>Say I have two related packages "foo" and "foo-bin". The latter is used to build one or more binaries which should ship with "foo". I don't want "foo-bin" to be user-visible since that's an implementation detail. At the moment, I make "foo-bin" non-public, and copy the binaries to "foo" output, but I think that's sub-optimal. Should I create a symlink instead? Or should I add "foo-bin" to "foo" propagated inputs? Should I use #:hidden? <ngz>More precisely, at the moment "foo-bin" is a native input for "foo" and binaries are copied after installation of "foo"... <ieure>ngz, What's the rationale for having two packages? vs. a package with an extra "bin" output. <ngz>ieure: They have neither the same source nor the same build system. <ieure>ngz, What's the relationship, then? <ngz>Besides, binaries must ship with "foo", so an extra output doesn't help. <ieure>Is this a mixed open/closed source thing? <ngz>"foo" contains data, and "foo-bin" binaries. <ngz>I don't think that will help, but, for example, texlive-afm2pl and texlive-afm2pl-bin. <ieure>I don't see a texlive-afm2pl-bin, so, not sure what the relationship is. <ngz>It only exists in the "tex-team" branch. I think I explained the relationship =/ <ieure>ngz, You could define an origin for the foo-bin stuff and use that as an input to the foo package. <ngz>Yes, but that doesn't work either. I complicates the package definition a lot. <ngz>I'm pretty sure I need two different packages. I just don't know how to "link" them in a way that makes "foo-bin" more or less invisible. <ieure>I'm not sure. I think you'd typically use foo-bin as an input to foo, and patch references to that stuff in foo to point to the store location where foo-bin is. But it sounds like the foo-bin stuff is actually what users will be running? <ngz>In this scenario, however, foo-bin is user-visible. <bavier>ngz, it seems like a propagated input and #:hidden is the way to go? <ngz>bavier: OK. I have never used #:hidden. Should I use define-public or define for the *-bin package? <ieure>Savannah down for anyone else? <ieure>Thanks. Looks like it's back, but was getting network unreachable and timeout errors. <picnoir>Is there a way/trick to interactively pass env variables from a user shell to a shepherd service? Something analogous to systemctl import-environment in the systemd land. <jmes`>Q: I am using a custom module in my guix home configuration, but its source is not in the load path when I run `home reconfigure`. As a workaround I just enter a guix shell to set up the load path for me before running the reconfigure but it seems like there is a better way to do this, any ideas? <civodul>picnoir: hey! maybe “herd eval root '(setenv "XYZ" "whatever")'”? <civodul>hmm now that i think of it it may not work: it’s filtered out by default by ‘make-forkexec-constructor’ & co. <civodul>ACTION needs to read about import-environment <picnoir>I'm not familiar with the actual implementation <civodul>“This is the environment block that is passed to all processes the manager spawns.” <civodul>interesting that there’s an “environment block” for *all* child processes <picnoir>Yeah, we probably could design that in a more granular way. <civodul>jmes`: you should be able to do “guix home reconfigure -L /path/to/modules config.scm” <Kolev>Yay! My Nextcloud container system built! <Kolev>Now, I'm scared to reconfigure the server with it. <civodul>picnoir: at any rate i’m interested in feedback from seasoned systemd users (pain points, missing features, etc.) <freakingpenguin>Hmm, apparently I have to build the entire the rust bootstrap for this riscv sbc image. Guess my pc won't shut off for the next several days. <picnoir>My particular use case would be to forward the wayland display (WAYLAND_DISPLAY), set by the wayland compositor to a shepherd user service that needs to plug to the said wayland compositor. The compositor is launched by the login managed (sddm in my case), not by shepherd itself. <picnoir>civodul: so far, it's been my only pain point. <picnoir>That and an annoying bug I need to find a minimal reproducer for :) <adammo>Is running 'guix pull' on just my user sufficient? I'm not sure if doing that means there's a different guix version for the guixbuilder users, or if that's even a thing! <picnoir>adammo: I'm not a guix guru, but so far, I've been always running guix pull from my user. Using sudo -E to use my user guix profile when I need the root privilege (notably to run guix system reconfigure). <picnoir>I don't think you need to run guix pull from your guixbuilder users. <adammo>picnoir: Makes sense, that's probably good enough for me too. Was just checking to so I don't get suprises in a year when my root's version is super old. <freakingpenguin>TL;DR: it's sufficient. If you're not running Guix System, probably a good idea to do sudo -i guix pull every once and a while. <adammo>freakingpenguin: gothcya. thanks! <Kolev>How does System's `guix` get updated? <Marc2>Hi to everyone. I have a grub configuration issue and would love some hints on how to achieve this in guix. I actually know what I need the "grub.cfg" file to be, but I cannot work out how to tell my config.scm file bootloader section to produce it. <Marc2>For my windows partition to properly start up, I need this entry to be generated: <Marc2>This works fine. The chainloader part is fine, when I do (chain-loader "+1"), but whenever I specify a device, the generated grub.cfg does not show it (from the documentation one could think that device is only used for linux partitions? but then there is one example given as this in the documentation: <picnoir>Kolev: if by system you mean the daemon, I believe it's part of your system closure, so should be updated everytime you run system reconfigure. <NotPuercoPop>I just finished the installation, the next step is installing icecat. Coming from nix the recommendation is avoid using nix-env and instead write things in a file and reload the config. Does the same warning apply to guix install? <NotPuercoPop>The manual talks about ~/.config/guix/, but there is no such directory on a fresh install. Should I just create one or is there a command that does that? <ieure>I know nothing of nix-env. In Guix, you can select packages with a manifest, or use Guix Home to manage you dotfiles and install packages. <Googulator>I'm working on a bootstrap of Guix on top of live-bootstrap (with eventual goal of replacing the remaining bootstrap binaries with ones built in live-bootstrap before bringing up Guix), and have ran into a strange issue: when building libxml2-2.9.14, Guix compiles the Python binding library for libxml2, and then tries to load it into the host <Googulator>system's Python (which fails because the host Python is linked against musl). <Googulator>Is this a known issue when running Guix on top of a foreign distro? <ieure>elevenkb, See the `guix import' section of the manual. <Googulator>For reference, the host Python is 3.11.1, which is newer than what Guix currently packages - could this be the reason why Guix thinks it can just use the host Python?