<podiki[m]>efraim: oh nice, I too realized after I complained 😀
<podiki[m]>efraim: still disappointed in what a mess it looks like to update kitty and I don't think it will be possible to build the docs (uses node in the sphinx theme); the go part is annoying too and I'm giving up for now
<efraim>bdju: I... don't know I suppose if you replaced each broken file with a different broken file it might not be more broken, but definately voiding the warranty (not that there was one to begin with :))
<PotentialUser-22>Hello guix! I am writing a package definition and use "url-fetch" in "method" procedure. However, when I run "guix build -f alps.scm -K" the following error arises: guix build: error: invalid character `~' in name `alps_20220304~r7871.orig.tar.gz.drv'. Why?
<nckx>I understand the feeling, it would have been nice if Nix had been designed with the database as a mere cache, but it's the other way 'round as rekado has since typed. The store just contains all those pesky bits. I've restored that file from backups about 20 times now (but that's because I'm a special boy).
<nckx>You *could* write a ‘guix fsck’ type utility that creates a skeleton database that's enough to limp back into working territory, but I'm not aware of such code.
<michal_atlas>You could delete the database and store and `guix init` onto it, which would essentially be a reinstall, that would regenerate all the files, since you already seem to have it mounted somewhere and acessible
<nckx>bdju: Again, make very sure to skip any automated partitioning. I'd use the manual installation procedure because it's what I'm used to..
<bdju>ugh this keyboard sucks I keep slipping on to enter
<bdju>I usually use guided install, only did manual before guided was a thing I think
<nckx>Then it's literally as following the manual installation instructions, mounting your ‘broken’ system under /mnt and ending with ‘guix system init /backup/my/system.scm /mnt’ from the installer image.
<nckx>bdju: So yes, it's mostly true that you'll be able to reproduce your system with nothing but your system.scm, manifest, and a back-up of /home (and anything else not managed by Guix), but what rekado meant above was that this involves blowing away the old /gnu and downloading/building a new copy of the OS. The many GiB which you already have in /gnu has become useless without a DB.
<nckx>bdju: If you're around in the EU evening, I'll gladly guide your hand, but many people here will be just as helpful.
<bdju>cool. thanks. I may or may not be around then, kind of awake odd hours recently (in the US but already been up several hours)
<nckx>Re: myself, Matrix: There was a security vulnerability that required restarting the bridge. Allegedly.
<podiki[m]>Hilton Chain: indeed, doesn't seem to be working right now
<bdju>guix system 1.4.0 installer, if I go to docs with alt-f2 then try to go back to the install tty with alt-f1 it sends me to the start of the install screen again, asking me to pick which type of install
<bdju>also the "latest" iso download link on the site is broken
<Kabouik_>Can I guix pull only my private channel to save time?
<grim`>Now that I think of it. Maybe it should be a new output of `appmenu-gtk-module'. The current package we have does not include the bin output. And the thing I'm packaging is basically the same + the bin output
<bdju>nckx: I'm in the installer with the guix system init command running. will that be able to wipe out the old /gnu/store I had or was I supposed to do that manually first?
<bdju>did du -sh /mnt/gnu after the init finished and hit an io error on a file so probably still has the old stuff. whoops. hopefully I can just wipe out the dir and init again
<bdju>ugh I've got files it can't rm due to io error
<bdju>and now I got read-only file system again. FML
<WorldsEndless[m]> This might be a simple syntax error. Anyone know what's happening here?
<grim`>I'm trying to package one little theme. But the error I'm getting is not making any sense. I try to build the package within `guix shell -D <package> --pure --container` and it does the steps without any problem. But the build daemon issues `failed with status 2`
<grim`>does anyone know how could I further troubleshoot this?
<grim`>podiki[m]: this is the package paste.debian.net/1287479
<podiki[m]> [grim](https://matrix.to/#/@grim:libera.chat): yes, you can source the environment variables file and that should be the same as the build environment (roughly, i'd assume there are differences being still a regular user, but it sets up important paths)
<grim`>podiki[m] sourcing the `environment-variables` the script runs well X)
<grim`>the thing is that I have a few other packages already made from the same author and the script runs fine even on the build daemon. But this one is really pulling my hairs
<michal_atlas>Hi, out of curiosity, is it stated anywhere in the manual that you can't use parameters in some records such as the operating-system? If not, do you think it might be a good idea to perhaps make a note of it somewhere?
<Grimpper[m]>Thanks podiki for the link to matrix. I didn't know this could be bridged :)
<podiki[m]>Grimpper: unfortunately the bridge (well plumbing now) is unreliable at times :(
<podiki[m]>I think you need to look at the shell/lib-install.sh script (if i got it right) to see what is going on there; build environment does not have internet access for instance
<nckx>bdju: I don't think trying to re-use this file system is a good idea, for reasons unrelated to Guix. If it's so corrupted you can't rm things, I strongly recommend copying your user data and creating a new btrfs.
<podiki[m]>(e.g. things trying to check network time, install dependencies...make sure none of that is happening)
<Grimpper[m]>podiki: yes. Using the `guix shell` environment I've filled the dependencies it was trying to download. And at least the shell does not complain. I thought the --container flag removed internet
<podiki[m]>--container should indeed remove network, unless specified as an additional option
<Grimpper[m]>podiki: This is the output I get by running everything by hand paste.debian.net/1287484
<Grimpper[m]>Ohh. I see something. On the container it does not issue an error but also won't install anything
<podiki[m]>not sure. would be nice to get the output of the bash script, not sure how to redirect that in the build environment
<podiki[m]>that's a good hint. and if you include network access?
<Grimpper[m]>Not doing anything anyways. But there is something very funky about this script. Outside the container it does very weird things with the terminal. Like outputs 4 multicolor dots that are moving. Like a load animation. That simply does not happen on the container
<podiki[m]>yeah, wants some nice (or "nice") UI for someone installing by calling the script rather than packagers
<podiki[m]>Grimpper: maybe look at make-release.sh or if there are any CI scripts for the package
<podiki[m]>Grimpper: likely you need to do a more manual install, taking parts of the bash script/doing the same in the package definition; i would think just copying the art is enough for build/install but i don't know the details here of what is being "built" and what is "source"
<Grimpper[m]>yeah. Thanks for the hints podiki! I will see how I can do it manually.
<podiki[m]>i already looked at arch and no help there; how they build releases (the make-release script) is where i would start, seems it calls just some functions of the install script
<luke-jr>any possibility I could pay someone to put together a straightforward walkthrough to bootstrap a Guix VM (compatible with other Guix systems) without any specific binaries (not even a minimal seed), but instead using already-trusted binaries one can easily get on Gentoo?
<gnucode>luke-jr: definitely don't pay me...but what are you trying to do? bootstrap a guix vm via gentoo?
<sneek>samplet, antipode says: #57573 (disarchive bug report, with reproducer!)
<dthompson>would be quite an undertaking to replace guix's bootstrap binaries with something else
<stikonas>dthompson: indeed, but that's what luke-jr wants to do. And also keep output hashes
<luke-jr>dthompson: replacing them with something else would break compatibility IIRC
<stikonas>so my guess was that you need to do 2 stage bootstrap
<samplet>The bootstrap seeds are getting simpler by the year... but they’re still complicated. :(
<stikonas>replace guix bootstrap binaries with your version, build guix, then try to use it to reproduce guix bootstrap binaries
<stikonas>and then do 2nd bootstrap with those binaries
<samplet>But why would you care about (binary) compatibility if you’re committing to build everything from source?
<luke-jr>samplet: the enitre purpose of Guix for me, is to verify reproducible builds
<stikonas>samplet: well, it simply depends on how much convenience you need, you can go down to two KiB or so to bootstrap everything, including the kernel
<luke-jr>samplet: and produce builds others can verifyu
<dthompson>but you need to start from the set of bootstrap binaries
<samplet>luke-jr: Ah okay. In that case, you would have to generate the bootstrap binaries from Gentoo like stikonas said. The ‘(guix packages bootstrap)’ module has most of what you need, if you are good at reading Guix packages.
<luke-jr>dthompson: that could work, if I can compile those binaries from source myself first ;)
<dthompson>the reason they are bootstrap binaries is because you won't be able to do that (at least not without a lot of work)
<luke-jr>samplet: not especially, though I could struggle through it
<stikonas>samplet,luke-jr but guix packages bootstrap depends on those binaries in the first place
<stikonas>so you first need to use your own static builds of them
<stikonas>which is why I was thinking that it is two stage process
<stikonas>1st stage would hopefully produce binaries with the same file hash but different guix output hash
<luke-jr>maybe close enough I can observe only internal paths are different? :|
<stikonas>they shouldn't care what bash was used to run guix build...
<stikonas>well, you should be able to use the same paths as guix uses...
<samplet>I think the answer is “hopefully”, actually. I wouldn’t be surprised if reproducibility was tested when they were made (I wasn’t there, though).
<dthompson>the bootstrap binaries are exempt from reproducibility because they are taken for granted.
<dthompson>the long term project is to eliminate them entirely, which is very very cool but the work so far has taken years and will take years more.
<samplet>But Guix can generate its own bootstrap binaries. When those definitions were written, I’m guessing they (Ludo and whoever was there) tested for reproducibility. (Again, dunno, just speculating.)
<stikonas>dthompson: you still need something to run package manager, don't you?
<stikonas>you can of course do bootstrap without guix (and this has been done) and then you only need 1 tiny binary
<geri>i can create a reliable shortcut to accessing it then)
<vagrantc>most distros basically just have hidden bootstrap binaries lost to time ... what is amazing about guix (and i presume nixos?) is that the bootstrap binaries are explicit and clearly documented ... and because it is explicit and documented, it can actually be fixed
<stikonas>samplet: this does indeed read a bit like 10 years ago
<stikonas>though in general I found that most software simply builds reproducibly with little (or no) extra effort
<stikonas>if you start from a small handwritten seed, so no compiler blob is involved
<janneke>stikonas: i believe that before the reproducible builds effort started by debian, only about 1 in 4 packages would build reproducible
<stikonas>hmm, interesting, I had no problems building reproducibly old gnu software from 1990-ies or 200x...
<stikonas>and patching out non-reproducible stuff seemed to me more of an exception rather than the rule
<stikonas>but perhaps a lot can be attributed to binutils no timestamps in archives change...
<Sofi>Does GNU Shepherd/Guix have any service isolation capabilities similar to SystemD? For example ProtectSystem, ProtectDevices, PrivateTmp. Also tooling like cgroups are things that I am not sure how to translate to a Guix based system.
<ChocolettePalett>> By default, the shell session or command runs in an augmented environment, where the new packages are added to search path environment variables such as PATH. You can, instead, choose to create an isolated environment containing nothing but the packages you asked for. Passing the --pure option clears environment variable definitions found in the parent environment14; passing --container goes one step further by spawning a container
<janneke>stikonas: yeah, having binutils produce reproducible binaries surely helps a lot
<Sofi>samplet: Thanks, do you know if its a priority for Guix/Shepherd, or if this is more a fun project from the author/speaker?
<haugh>I wouldn't wait around for Shepherd to copy PoetteringOS's scope. Guix is based on getting containerization out of the software pool. If you need containers for software designed to run in them, install a containerization layer.
<haugh>That second sentence is regrettably spicy; what I mean is that the Store is used to provide multiple software versions wherein other systems depend on cgroups/chroot
<samplet>Sofi: My guess is that the blog post was supposed to generate excitement so that people would poke at the idea. It never really happened though (to my recollection).
<lispmacs[work]>so, gnome-team branch has it, but no build in progress for master (?)
<elpogo>from the manual: "Any user can update their Guix copy using guix pull, and the effect is limited to the user who ran guix pull. For instance, when user root runs guix pull, this has no effect on the version of Guix that user alice sees, and vice versa." if alice updates their guix before root, is it not possible that alice's version of guix will be connecting to an older/incompatible version of the guix-dameon ?
<elpogo>is the communication protocol between guix and guix-daemon documented somewhere?
<nckx>Mostly the latter, but when a protocol change must happen, the former :)
<nckx>To clarify: the daemon does see updates, but the protocol is basically ‘done’.
<elpogo>good to know. i'll keep using debian-bookworm's version of guix-daemon until it no longer works with the current guix. will there be a graceful failure/message if there's a breaking change?
<nckx>There are two reasons for the daemon seeing very little development: (1) it's in C++, and AFAIK nobody here likes C++, and (2) the daemon doesn't actually do much beyond implement a very basic store model. The protocol is very simple, everything interesting happens at a higher (Scheme code) level.
<ekaitz>nckx: there have been efforts to port it to guile right? :)
<nckx>elpogo: The probability of a security fix is much higher than an incompatible protocol, so keep an eye on ‘guix pull’ news items :) Updating the daemon yearly or so is probably fine.
<nckx>ekaitz: Yep, but I'm not aware of any recent work ☹
<elpogo>ok. if it's a security issue i hope i can count on debian's security team pushing an update as well
<elpogo>btw, the guix-daemon socket at /var/guix/daemon-socket/socket is writable by everyone. is modifying permissions on that socket file the recommended way to limit which users can install to guix ?
<elpogo>actually, i recall now. i did try guix in 2018 or so in a google cloud vm, but it was bringing the machine to a crawl because it didn't have enough memory. haven't hit that problem yet this time around.
<nckx>The first VPS I tried to convert to Guix System had 256 MiB of RAM. That was… actually I used it for a surprisingly long time (>1y).
<elpogo>is all the network activity done by guix-daemon, or is the guix command also connecting to the internet to fetch source/substitutes? i'm trying to figure out if putting the guix-daemon in a vpn network namespace is sufficient, or if i should ensure every invocation of the guix command is also done from that namespace
<GNUtoo>hi, I am unsure what to do with openssl-1.1 and libressl: if I do guix lint email@example.com and guix lint libressl, it shows some CVE. Should I (1) bugreport (2) send patches to update them through the normal procedure (openssl-1.1 has a lot of reverse dependencies, libreSSL has less). Are they OK because guix lint only looks at versions but not patches?
<nckx>elpogo: Sources & toots are fetched by (subprocesses of subproccesses) of the daemon, but at least ‘guix pull’ would very much like to have some of that tasty network access. As do more niche things like ‘guix lint -c cve’.
<nckx>GNUtoo: Do you mean that it's a false positive?
<GNUtoo>"This patch removes the explicit reference to the 'perl' binary"
<poselyqualityles>to run shepherd on a foreign distro, i'm using the $xdg_config_home/shepherd/init.scm approach. can I then use predefined services from guix channel gnu/services modules? examples i've found so far appear to define new shepherd services either directly in init.scm or under /init.d/. since i already have a user to hold the profile would it be better to just go ahead and use guix home (or does that not work outside of guix system)?
<ulfvonbelow>do the enter and exit thunks of dynamic-wind still cause continuation barriers?
<GNUtoo>nckx: for LibreSSL I've sent the patch to bug #64982
<futurile>Q: if you `guix pull` there's the possibility that Substitutes haven't been built yet. Is there any command to pull in a way that avoids that - say pull from 24 hours back? Or anyone have a way of doing it?
<itd>sneek: later tell rekado: please restart the irc logging bot.