IRC channel logs
2023-07-31.log
back to list of logs
<podiki[m]>i updated kitty o 0.21.2 though that is a few years old; seems the best we can do right now (docs use sphinx and now themes which need node to build, fetching hundreds of packages) <podiki[m]>i see termite is revived; alacritty is stuck in rust packaging update difficulties? <psyclimb>i have a love/hate relationship and fascination with guix system <apteryx>nckx: I've found the problem to be caused by policy files having moved from /etc/dbus-1 to /share/dbus-1 not being exposed by the elogind-dbus-shepherd-sync wrapper <Caesar>psyclimb: Any relationship has ups and downs. Just try not to get obsessed. <apteryx>psyclimb: feedback on what you consider arcane that could be improved would be welcome to #guix-devel <apteryx>yay, elogind test is now passing with its latest 252.9 version <jx0>hey all 0/ hope everyone's having a good day/night <apteryx>ACTION is enjoying the soothing sound of rain <efraim>podiki[m]: alacritty is actually caught up ATM <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 <fries>do y'all have to package every npm module? <fries>well, that the node packages use <fries>i wonder how much it would take to make one <fries>like, every npm package should have a package.json file? <fries>anyways V i am trying to build your java app <fries>downloading the iced tea jdk.. <fries>did you get this error, also i wonder how matrix images transfer over to irc <fries>all though, generally, what is ice-9/boot-9.scm <fries>is that where the modules get merged or something <fries>really provide an accurate line number where the error happened <fries>looking at the error, mainly the #f part <fries>maybe line 1901 is problematic <V><fries> anyways V i am trying to build your java app <fries>i was talking about a different person <bdju>if btrfs scrub shows some bad files in /gnu/store, can I delete them or how would I sort that out? <bdju>I can uninstall/reinstall files later but currently not booted into guix system, just have the filesystem mounted on another pc <efraim>bdju: you'll want 'sudo guix gc --verify=repair,contents' when you're booted into guix system <efraim>the daemon keeps track of what files are in the store so you can't just delete them and expect everything to be ok <bdju>efraim: would that be instead of deleting the files then? <bdju>and does stuff in the ~/.local whatever guix cache thing matter? had some bad stuff there too <efraim>bdju: yeah, that'd be instead of manually deleting files in /gnu/store <efraim>anything in ~/.local or ~/.cache you can get rid of without issues for guix <bdju>efraim: is it safe to replace the broken /gnu/store files with empty files that are the same name? <bdju>still would do the gc thing later <bdju>trying to get past a thing choking on errors <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 :)) <rekado>weâre still suffering from timeouts on ci.guix.gnu.org <rekado>this affects the issues.guix.gnu.org sync with debbugs, and we still canât clone the guix git repo on it <rekado>Iâll *again* ask for help on the open ticket with the network team <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? <next4th>PotentialUser-22: You can add (file-name (string-append "alps-" version ".tar.gz")) to origin to make it happy.. <efraim>^^ that was going to be my suggestion <xelxebar>nckx: Sanity checking intel-xed against their docker def. I have no idea why `xed -e` is throwing errors. <next4th>our 'xed -e push eax' works, but 'xed -64 -e push rax' does not, maybe need update to a newer version.. <xelxebar>I see. `mov eax, ecx` throws another error, so I got confused. Apparently it doesn't want commas between the operands, just spaces. <xelxebar>For now just running with `guix shell --with-commit=intel-xed=v2023.07.09 intel-xed` <next4th>oh, forget that cool thing, thx. though my connection to github is random broken a lot :-\ <PotentialUser-22>Sorry, it appears to be working, but in fact it isn't even with addition of file-name. The error is the same. <Altadil>PotentialUser-22: Are you using Tor Browser ? It seems it cannot access issues.guix.gnu.org anymore for some unknown reason. But the website itself is up and I can reach it without Tor. <PotentialUser-22>Yes I use Tor. I cannot acces issues.guix.gnu.org directly from Russia either. <ChocolettePalett>@[PotentialUser-85] there is a wishlist, you could try adding your entry there: <ekaitz>hi after a reconfigure my config started to fail <ekaitz>first it says swapon "/dev/sda3" invalid argument <ekaitz>and also if i reboot to the new config some programs don't find dbus <apteryx>my biggest GC so far: "guix gc: 1âŻ745âŻ406,44 Mo freed"; completed in 307 minutes <bdju>> error: reading from file: Input/output error <bdju>is this expected when doing the guix gc repair stuff efraim? <bdju>> error: executing SQLite query: database disk image is malformed <bdju>this gives me a bad feeling. can that be fixed without a reinstall? <bdju>I have already replaced the drive but wasn't able to fix every bad file before copying the data over <bdju>done a million things, but it's btrfs so technically can't fsck <bdju>but yeah 3 days or more into all this <bdju>btrfs check, scrub, etc. manually deleting some bad files it found. but it was all taking too long and was starting to not make as much progress so just copied to a new drive <rekado>then you copied the corrupted database over to a new drive <bdju>yeah, so can I regenerate it or something? <bdju>what.... literally why not <bdju>I have my config.scm and manifest that should be the source of sorts for it <rekado>the database is the source of truth <bdju>I really really really hate (re)installing guix system. only done it two or three times I think and I avoid it like the plague... <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 <bdju>kind of an eternal beginner with guix so not sure I can manage that <bdju>I have the new SSD with the old data in the machine now and am booted into the system. was messing with a data dump of the old drive on another computer earlier <nckx>If you managed to install Guix there's little more to it than repeating the manual installation procedure. <nckx>*install Guix System before <bdju>would rather not lose the contents of my home directory. hmm <nckx>You'd skip the âwipe your disksâ part đ <bdju>wait, so I can use the normal installer and not lose my personal data? <nckx>(Re)installing Guix only touches /gnu and /var/guix AFAIK. <bdju>holy cow that's pretty neat if true <nckx>Then /etc etc. (heh) are populated at boot. <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>Sorry, sneakily IRC'ing. <bdju>alright may give that a go later then <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 rekâado meâant 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. <bdju>alright I think I get it <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? <efraim>the quick way is to add --commit=XXX, where XXX is the current guix commit that you've already pulled to <Kabouik_>I just found --url which seems to be what I want too <Kabouik_>Should have better checked the help, sorry. <nckx>Note that it'll still build âa guixâ though. No way around that. <jackhill>I `sudo reboot` hanging after stopping service user-file-systems a known issue? Seem to happen to me fairly regularly. I have to use Alt-PrintScreen-B to get past it. <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? <WorldsEndless[m]> ;; (program (file-append xlock "/run/setuid-programs")))) ;; error: xlock: unbound variable <WorldsEndless[m]>what should I be doing instead of xlock to get things happy? For comparison, <WorldsEndless[m]>(screen-locker-service xlockmore "xlock") ;; works, but is deprecated. Wants -type, but this fails <grim`>guys do we have any way to inspect a shell script error thrown by the build daemon? <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? <pjals_fox>you dont want to go into the rabbithole of finding out what status codes coresspond to comprehensible explanations <grim`>this is the output of `install` phase: <grim`>`command "./install.sh" "--dest" "/gnu/store/djbkw22lk4apsrvkbys8iz4v60b3aws9-whitesur-gtk-themes-2023-06-30/share/themes" "--theme" "all" failed with status 2` <grim`>I wish it was a friendly `127` ;( <WorldsEndless[m]>I hate magic numbers... also, wish I understood more about guix and themes vs bash scripts <grim`>What really bothers me is that It only fails for the build daemon... In a pure shell it works... <grim`>The bash manual says: `All builtins return an exit status of 2 to indicate incorrect usage, generally invalid options or missing arguments.` <grim`>Anyone knows if the bash executed by the built daemon is different from the one executed by a guix shell? <podiki[m]>could be permission denied too (based on a quick search) <grim`>podiki[m]: a pure container have more permissions than the daemon? <podiki[m]>sorry, don't know the details of the build environment; you can build with the option -K to keep the build files including environment variables you can source <podiki[m]>for instance, the build environment will be limited where it can write, but a pure shell will be less limited I think <podiki[m]>if you share (via a paste site) the package definition, that could help. or if you haven't already, compare to similar theme packages <grim`>I'm using the -K option but perhaps I'm not doing what I'm supposed. Should I just source the environment? <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]>Grimpper: are you the user formerly known as grim`? <podiki[m]>i added whitesur-icon-theme to the end of the file and did guix build -f <file> <podiki[m]>and can you paste the full build log when you do that and it fails? <Grimpper[m]>podiki: avery pastbin I try complains about the size? Do you guys use one that allows larger files? <podiki[m]>probably since there are so many files in icon themes; just the last bit of the log then <podiki[m]>the only thing I can imagine is something else going on with your guix_package_path, but i don't see how that would do anything here <podiki[m]>are you sure you are building the same thing? your log is about "whitesur-gtk-themes" not "whitesur-icon-theme" which was in the package def you shared <Grimpper[m]>This is the one that fails: paste.debian.net/1287483 <Grimpper[m]>They are very similar minus the source. This is why i confused them. Sorry for that <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]>i'm not familiar enough with bash scripts and build environment to know more <podiki[m]>could very well be some easier fix or complicated :( <Grimpper[m]>yeah. Me neither. I had it packaged with just a tar ball. But since yesterday they told me to try to build all packages I submit from source... <Grimpper[m]>I need to pass it because uses which to find sudo and later when sees it has all the dependencies continues without using neither... <old>I have build error of package texlive-font-maps <old>based on latest commit 55e89da207b95230e5f2a8176acd9cc9b43971ff <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? <luke-jr>I dug out a 2006 hard drive and compiled up to modern Gentoo from that. I just want a Guix VM also, without adding trusted binaries into the mix <luke-jr>I expect I could get through it eventually, but it would probably be much faster for someone familiar with Guix <gnucode>luke-jr: do you have guix installed on your gentoo system? <gnucode>probably "guix system vm" won't work... <gnucode>you could always just do run guix system. :) <stikonas>gnucode: well, luke-jr can't run guix system without building it first <stikonas>luke-jr's goal was not to use binary blobs <stikonas>and having guix system introduces quite a few, so you need a way to rebuild them first <samplet>luke-jr: I donât know if it would be easier to punch a hole in the build environment to use tools from the host or rebuild Guixâs bootstrap seeds. <sneek>Welcome back samplet, you have 1 message! <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>if I start with non-standard seed binaries like stikonas suggested, will the non-standard Guix system be able to produce the real seeds needed? or will those hash differently too? <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 <stikonas>but then you won't have package manager until later in the bootstrap process <stikonas>perhaps even if it is not reproducible, differences in bootstrap guile might be minimal... (paths or timestamps) <dthompson>I'd have to go looking at what we're bootstrapping with, but gensym wasn't reproducible once upon a time so it could potentially be a lot more than that stuff <samplet>dthompson: There are lots of potential issues, sure. I just honestly donât know whether they were addressed at the time or if they punted. <stikonas>there is another option to fix that, replace guix bootstrap binaries with the ones that have well defined bootstrap path... <stikonas>I mean in guix itself, not in luke-jr's run <luke-jr>anyway, I was hoping someone would be open to being paid to sort through the difficulties and document how to do it :) <samplet>(N.B., I meant the â(gnu packages bootstrap)â module.) <dthompson>my understanding is that there isn't a way to do it. it will require the completion of the effort to reduce the binary seed to a single handwritten executable. <luke-jr>dthompson: if a single handwritten executable can do it, so could a full trusted system with fewer steps :/ <dthompson>I don't like the idea of a "full trusted sytem" <dthompson>the point is kind of to eliminate trusted systems <geri>hey, where to does guix pull actually pull the guix repo? <dthompson>every distro's bootstrap binaries are a trusted system. I don't see what makes gentoo more trusted than guix in this regard. <geri>oh yeah, i know where *from*, i just wanna browse it locally without having to re-clone the repo <geri>how is the hash calculated for the channel? <geri>or more like, is it consistent across installs? <samplet>Oh shoot, I did it twice! Itâs the â(gnu packages make-bootstrap)â module. <geri>here the guix repo is called `pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq' <geri>guess if someone checks theirs we can know semi reliably :D <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>well, even if it is not reproducible like some suspected, one can fix make-bootstrap to make reproducible bootstrap binaries <stikonas>and then replace bootstrap binaries with the new ones <geri>does someone fr use "reproducible" as their IRC nickname <luke-jr>dthompson: my trusted binaries date back to early 2000s <geri>is there any reason to carry them around as binaries instead of source code? <gnucode>luke-jr: how did you build gentoo from source? Is it fairly easy to do? <luke-jr>gnucode: Gentoo is source-based; initially, I did use binaries, back in 2006 <luke-jr>(when I had to reinstall, I dug out the 2006-era hard drive and started again from that) <gnucode>luke-jr: why did you bring you re-use the old binaries? Just curious. Sounds like a lot of work. Does gentoo make you compile everything from source during the install phase? <gnucode>why did you you re-use the old binaries?* <geri>luke-jr: nvm that, i just misunderstood smth <luke-jr>gnucode: to reduce the timeframe I'm trusting as much as I could; 2006 was the oldest I still had a safe copy of <luke-jr>it also puts it before Bitcoin, and long before I became a target of attacks <gnucode>luke-jr: oh...you're the author of bitcoin-knots? <gnucode>my friend really likes that software. I've been helping him with his talos II. It is really impressive how many targets you have ported that software too. Kudos! <luke-jr>and yes, Gentoo has an installation handbook to hand-install, building everything from source (via the pkg manager) <luke-jr>gnucode: Knots is basically the only thing I use Guix for (to build the official binaries) XD <geri>i used gentoo for a little less than a year, it's nice and stable but compiling *everything* from source is rather time consuming <luke-jr>(most of that work was by dongcarl tho) <geri>feel like guix is best of both worlds <geri>i mean, i compiled overtime <luke-jr>with a good CPU, it's usually done in a few minutes <geri>my only complaint is that chromium is trash and compiles for as long as the rest of my system <luke-jr>occasionally a few hours eg if all KDE is updated <geri>i had chromium compiling here all night actually - cancelled and substitutes came in by the evening <geri>that's one thing i never wish to come back <luke-jr>currently only using another binary system for a browser; I don't trust it enough for my main workstation <luke-jr>geri: problem is there's no way to verify substitutes match the source, except if you compile yourself <geri>maybe a silly question, but why do you use gentoo and not guix without substitutes? <geri>full source bootstrap sounds like something right up your valley <luke-jr>aside from the current issue I'm facing with getting Guix going again... mainly USE flags and /etc/portage/patches <geri>can't you add patches by overriding package definition? <luke-jr>maybe, but it's pretty simple to just drop a patch file in :p <geri>i love gentoo's release cycle <geri>"stable rolling release" <gnucode>luke-jr: may I ask why gentoo is your distro of choice? <geri>so far i understood it as trust issues :D <luke-jr>[16:28] <luke-jr> aside from the current issue I'm facing with getting Guix going again... mainly USE flags and /etc/portage/patches <podiki[m]>There's a with-patch transformation too, can do it from cli or manifest then <geri>is it possible to set an env var in a manifest file <geri>luke-jr: do you audit all the code for every project you use before compiling it? <geri>honestly that sounds impossible to do <luke-jr>but I know anyone could have audited it ;) <geri>i wanna learn code auditing some time <geri>itd be nice to actually be 100% sure this random software from the internet isnt being creepy <stikonas>there is just too much software to audit everything personally <stikonas>you have to trust that others also looked at it <geri>yeah, i think 100% is impossible <geri>but 100% in a particular project is fine depending on a project <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. <samplet>Itâs probably a little dated by now.... <ChocolettePalett>I guess one can use "guix shell --container" or smth, there are some examples on the "guix shell" documentation page <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]>hi, I was a little confused trying to figure how to track when substitute is available for icecat-minimal, since I don't have the required 64GB ram on my system <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 ? <nckx>It could happen, but that would be a bug. <nckx>The incompatibility would be accidental and would be fixed. <nckx>It's quite (maybe even most) common that the guix command doesn't match the running guix-daemon. <elpogo>is that because the protocol tries to keep track of versions and be backward compatible, or is it that guix-daemon is always never updated? <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>this whole ecosystem is so cool. i'm a little disappointed i didn't get into it sooner <elpogo>who'd have thought you can have an initrd in guile <nckx>It's still very monolithic, making it more flexible would be nice. <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 ? <nckx>Oh, and a usable REPL at boot. <nckx>elpogo: I guess so. I don't know if there *is* a recommended way to limit that đ <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). <nckx>2015 or so. No way I'd do so today. <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 openssl@1.1 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>like is guix lint usually reliable? <GNUtoo>And what to do if it shows some CVEs? <nckx>Eh. There's a lot of translation in which to get lost. <nckx>GNUtoo: Fix them if true â either by updating the package, adding (patches âŚ), or one of those + a graft â or hide them if false. <nckx>GNUtoo: If I return this evening I'll look at openssl@1.1. If it's a false positive, it's as easy as adding a lint-hidden-cve property. <nckx>But don't hesitate to look yourself, the more opinions the better. <nckx>And I don't say that often. <GNUtoo>I can try to look at libressl, it has no patches, and few reverse dependenices so it's easier for me <GNUtoo>openssl 1.1 has openssl-1.1-c-rehash-in.patch only <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 <gotham>I am trying to create a guix package for /sonic-pi/ <iyzsong>um, okay, it's still building by qa status.. <gotham>Is it possible to create this package on a Arch-Linux machine, with guix package manager? Or, is it necessary to package it on a GuixOS machine? <iyzsong>gotham: using guix on ArchLinux (or other) is fine too <gotham>Thanks for the info @iyzsong. Will proceed confidently now :) <adamnr>Hi Guix, the archive logs look like they have stopped logging <attila_lendvai>i'm having trouble home reconfiguring due to "updmap [ERROR]: Did you run mktexlsr?". am i alone with this? (i'm already in contact with the patch author, waiting for a fix) <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. 
