IRC channel logs
2023-07-20.log
back to list of logs
<RavenJoad>The reason I went with the X route is because these wrapped programs should show up in the system profile, so that the real commands called point to the right config file. <RavenJoad>And I cannot use wrap-program because apcupsd's configuration file cannot be provided as an environment variable, only a command line arg. <linj>Could anyone do me a favour by posting the output of guix size emacs-minimal? <linj>I am interested in building a minimal Emacs and emacs-minimal seems to be the one I am looking for. <RavenJoad>linj: On Guix commit 6a91d4b, "guix size emacs-minimal" yields a total size of 213.9MiB. That includes glibc, gcc, core utils, and other helpers. 110.6MiB of that is Emacs itself. <RavenJoad>So my current error is due to having a (list (program-file) (program-file)) as a source in a package definition, which Guix does not like. Is such a thing even possible? <lilyp>Your source should be a single file, have you thought about directory unions? <PurpleSym>jgart: I don’t think we have agreed on a timeline for merging python-team yet. As I wrote, I’m currently working on some changes to pyproject-build-system that I would like to get merged too. <adanska>Hi guys! I'm trying to use guix shell with a little one-liner bash script; im just getting the ncurses package in so i can use `clear'. This is what I'm trying to run: "guix shell ncurses sensors -- while true; do sensors; sleep 1; clear; done". It's giving a "syntax error near unexpected token `do'". However, when I run the script after invoking "guix shell ncurses sensors" it runs perfectly. Is it due to some behaviour of bash and using the `--' flag with <rekado>adanska: you can only have one command after “--”. The ; separates commands, so only the “while true” is part of the shell command. <rekado>BTW: you could use “watch” instead of a while loop <rekado>“watch” is part of the procps package <adanska>so if i put a ; after the guix shell commmand it would work? i'll try that as well as the 'watch' command. thanks! <adanska>ah, didnt work :( is there a way to do one liner bash scripts like this using guix shell? <rekado>yes, you’d have to launch “bash” or “sh” with “-c” and pass the script as a string <rekado>e.g. guix shell ncurses lm-sensors -- bash -c 'while true; do sensors; sleep 1; clear; done' <rekado>personally, I’d do “guix shell procps lm-sensors -- watch -n1 sensors”, though <adanska>yeah, ive just tried using 'watch' and its perfect for what i wanted. thanks for teaching me! <efraim>gcc-2.95 failed in 'build even when I downgraded glibc to 2.33, I might need to poke the sources themselves to see if I can get it to build :/ <rekado>I just wanted to update python-rich <abrenon>I keep hitting what I think is the same locale/encoding issue over and over <abrenon>I had it deploying a haskell code of mine on a Debian server where I have installed guix, I had it generating docker containers, and now I'm facing it anew when trying to guix pack to deploy on a HPC server where I have no rights but to run executables <abrenon>I tried remembering what had done the trick the previous time but either I forgot something or I'm still too confused about the issue and haven't understood what could make it work <janneke>civodul, jpoiret: the hurd-team branch just shrunk to a mere 16 commits! <abrenon>I generated a custom glibc for en_US.UTF-8 (the only locale available on the host) and included that in the pack with gcc-toolchain and ghc, I set LANG=en_US.UTF-8 in my profile <abrenon>found the locale directory in the packed gnu/store and exported GUIX_LOCPATH to this value <abrenon>but from a haskell program hGetEncoding still returns ASCII… and then haskell chokes on the utf-8 characters <abrenon>is the glibc package itself required in addition to gcc-toolchain ? (I'm pretty sure I remember last time with the container gcc-toolchain was enough) <janneke>ACTION locally reverted cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60 "gnu: patman: Add python-u-boot-pylib to inputs." and two more u-boot commits to have make make-go succeed <janneke>i'm not sure which of the three commits has a problem yet <janneke>it seems to be just cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60, still checking <janneke>okay, cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60~ builds <janneke>then, rebasing on cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60 (without make clean-go) builds... <janneke>ACTION tries removing some .go files, but everything still builds; so trying a make clean-go build <janneke>hmm, cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60 seems to build fine after a make clean-go <janneke>ACTION was sure they did that on their hurd branch too, when compilation failed, but must have been seeing ghosts <ChocolettePalett>I added so many free software packages to my GNU/Guix home environment configuration file that it has been updating for the whole day, and it seems like it's going to continue updating during the night as well :) <ChocolettePalett>As a former Gentoo user, I find it very enjoyable and satisfying to have the same experience across different GNU/Linux distros. <ulfvonbe`>there are some dynamic sections that readelf can find the string table for but (guix build gremlin) can't, it appears that readelf finds it because it first looks for a section of type SHT_STRTAB named ".dynstr", and only after that processes the dynamic section. Not sure whether that's a "readelf going above and beyond to comprehend a warped elf file" thing or a "(guix build gremlin) isn't as capable" thing. <ulfvonbe`>ldd also fails to give me any useful output, so it might just be a messed up file <pjals>Is there a Porkbun DNS credential plugin for Certbot on Guix? I can't find one. <pjals>I tried to package it, but I failed. <pjals_posm>Whoops, ment to send it on this account, oh well. <RavenJoad>lilyp: I had not. But I am thinking about this a little more now, and I also need to include a script to start and halt the machine. I am not sure if I want to build that script with the package or when the service is built. <PotentialUser-82>Haven't known about guix for an hour and y'all got me feeling like a whole hackerman, using IRC and such... <ulfvonbe`>what's a good way to hunt down extremely unhelpful error messages? For example, I try running 'make' after rebasing and it says "error: mesa: unbound variable" and nothing else. <ulfvonbe`>no backtrace, no line numbers, no file name, nothing <zamfofex>ulfvonbe`: Perhaps ‘grep -r mesa | less’ or something along those lines. <zamfofex>PotentialUser-82: Welcome! Where have you heard about Guix? <yasht>Hello guix, is the git package broken currently? <apteryx>uh, 'sudo parted -m' hangs and can't be killed <zamfofex>PotentialUser-82: Not sure if you saw my message, but welcome! Where have you heard about Guix? <PotentialUser-82>zamfofex: I saw it, got disconnected right as I sent my reply I guess. I went down a rabbit hole learning about emacs. Always heard about the editor, never knew what it was. From there I went, "Well what's this Lisp thing?" and here I am, trying to figure out how to chase the Lisp machine dream as a Linux Mint user. <yasht>nckx: I'm getting an error about an unbound-variable called crust-pine64-plus when I try to install git. <gabber>PotentialUser-82: you got side-tracked quite a bit, for most of guix runs on more main-stream x86 and load-and-store architecture :) but nice to see others following similar rabbits down their holes <nckx>As a user, the resulting Guix System is a boring old Unix system. But you do get to write something that looks like Lisp if you contribute! So you know what to do. <gabber>yasht: what happens if you do `guix show crust-pine64-plus`? <ulfvonbe`>zamfofex: a mere 495 matches, how hard could it be? <PotentialUser-82>gabber: I'm still hanging on to the ledge of that hole, so to speak, no worries, I might leave soon! ...on the other hand, I'm formatting a USB and dusting off an old beater laptop so who knows what will happen. <zamfofex>ulfvonbe`: Maybe try to look only into the files you actually changed. <nckx>yasht: I can't reproduce that. Have you pulled before trying again? If so, which Guix commit is this? <PotentialUser-82>Kinda scared of the whole "hey your hardware might make installing this system a no-go anyway, womp womp" thing. But we're about to find out, I guess <gabber>PotentialUser-82: as long as you remember to use substitutes it's a rather refreshing experience imho <PotentialUser-82>gabber: I'll definitely remember to do that. Once you tell me what "substitutes" are... <zamfofex>PotentialUser-82: You can try installing Guix as a package manager on top of any GNU/Linux distro (and indeed non‐GNU Linux distros too) to see if you like it first. <abrenon>retrying my luck since the chan seems a little more active now: locale errors when running guix-packed haskell package on a foreign distro (Debian), what am I missing ? <nckx>PotentialUser-82: Pre-built binary packages that are transparently ‘substituted’ for local builds. <abrenon>(I packed a glibc-locale, set GUIX_LOCPATH, set LANG…) <zamfofex>PotentialUser-82: Guix code describes only how to build packages from source. Substitutes are downloadable package binaries that Guix can use to not have to buld every package locally. <PotentialUser-82>nckx: Ok, *definitely* good I asked, because I thought gabber meant "other distros" ie., dual-boot something to give you a break lol <yasht>gabber: I get the same error "crust-pine64-plus: unbound-variable" <nckx>PotentialUser-82: Well, as much as I love Guix, it is not a polished, finished, bug-free (hah) end-user product, so maybe you'll do that too :) <nckx>ACTION tries a proper ‘guix pull’. <abrenon>PotentialUser-82: no, substitutes are the pre-built binary packages available (so you don't waste all your CPU time compiling stuff to install anything) <PotentialUser-82>zamfofex: This part kinda confuses me, and even though I've just learned what "RTFM" means, I'll still ask - what's the relatively non-techie way to describe how guix is a OS AND a package manager? <abrenon>— not that I mean it's a wast of time compiling stuff, I've seen the enthusiastic intersection with the Gentoo community which I do not mean to anger at all 👋 <zamfofex>PotentialUser-82: Guix System is a distro featuring Guix as the package manager, but it also has some other niceties such as being able to handle system‐wide packages and configuration with Guix itself. <PotentialUser-82>nckx: Really selling me on this thing, bud... Jokes aside, I might put an "easy" system on the beater, use guix as a package manager, and hope I graduate to the big leagues sooner rather than later <PotentialUser-82>zamfofex: So, fair to say guix as a package manager is the training wheels to guix the system? <zamfofex>PotentialUser-82: If you have multiple computers, you could try installing Guix System on it, and if it doesn’t work out, you can always install something else instead. <zamfofex>“installing Guix system on one of them”, I mean. <abrenon>I'd say they are rather separated: guix-the-package-manager is just one component of guix-the-system, which happens to be available to other systems <nckx>The dream of Guix is to have a library of software packages, written as Scheme recipes, *and* a configuration framework around them that can build a full system (or user configuration, think dotfiles etc.) using them. Like most distro's Guix System is ‘just’ the Guix package manager, package library, and some ‘extra code’ to create a bootable system. However, that ‘extra code’ is also written in Scheme and hence much more tightly integrated. <abrenon>it's not "harder" or "simpler", just doesn't do the same stuff <PotentialUser-82>abrenon: So it's better to just jump into guix-the-system and work it out, if that's my end goal <nckx>Yeah, it's not a magical new kind of package-manager-that's-also-a-distro, although both the package manager and distro have some nifty design features that others don't. <abrenon>I'm not saying that either, in the end the best is what you're most comfortable with <zamfofex>The “they are integrated” part is a bit undersold here, I feel. You can configure the system using the same language and the same packages available in the package manager, which I think is neat. <abrenon>but I've been using both straight away when I started with guix and haven't had any major crisis to lament <zamfofex>PotentialUser-82: Using Guix as a package manager on a foreign distro exists for a reason! Some people might find it useful or interesting, but don’t want to (or can’t) migrate to Guix System proper. <nckx>zamfofex: Oh, my ‘much more tightly’ was meant as a sell. <abrenon>now when it comes to tweaking, I'd say that tinkering with packages might be a little easier to start (mainly because usually only one file is concerned at a time) <PotentialUser-82>zamfofex: For the "can't" bit, is the limiting factor hardware, or not knowing Lisp/Scheme? <nckx>zamfofex: It's a killer feature compared to other distro's, just not a totally alien beast. <zamfofex>PotentialUser-82: It depends sometimes, though I never had big problems regarding hardware support. But I meant more so things like “you have many files that are difficult to backup” or “you have a set up you can’t disrupt (e.g. a server)”, or that changing distros would be prohibitively difficult else. <yasht>Installing Git works when I use the b275069 commit. <yasht>I'll try to narrow it down to the exact commit. <PotentialUser-82>zamfofex: As long as the wifi firmware on my beater works, I'm good. Not leaving Mint as my home for a *while*, but I've wanted to get more tech-y for a bit, now. I'll make the USB and skim the manual, let's see what happens <abrenon>another example I can think of is when you share a machine in a lab and you have admin access and can install a package manager but other people still use some poorly packaged software which would be tedious to port to guix <zamfofex>PotentialUser-82: with the laptop I started using Guix, wi‐fi worked transparently. With this all‐in‐one I’m using currently, I wasn’t as lucky. (But that was the only issue I really ran into.) <nckx>Argh. I just spent an unreasonable amount of time finding out that copy-build-system silently ignores cross-compilation. <gabber>WDYM copy-build-system ignores... how would it honor cross-compilation if it just copies files? <podiki[m]>with tex-live updated time for the mesa-updates branch I think! there's been a graft of mesa (for some driver build updates) on master <abrenon>well isn't copy-build-system for architecture-independent files like scripts ? <podiki[m]>how should I make sure everything is built before merging? should i just merge master into mesa-updates and then let that build? then can merge to master or just cherry pick the 2 commits from mesa-updates? <nckx>gabber: It does more, like patch shebangs. Which is nice & helpful but was originally more of a build-time hack, hence uses build-time architecture. <nckx>So you end up installing a script with a build-native interpreter & no obvious way to fix that. <nckx>Because this-package-input & #:key inputs both return the ‘native’ version, silently. <podiki[m]>thoughts on this plan? merge master into mesa-updates and see what the rebuilds looklike (from texlive updates); if it is a few thousand already I might as well do the ungraft of mesa and throwing some other updates like libdrm <podiki[m]>(otherwise I would do those new patches since mesa-updates was originally built for the next mesa update round) <podiki[m]>for the merge of mesa-updates to master, I could just cherry pick those commits anyway for a nicer history but keeping substitutes, correct? <RavenJoad>For apcupsd, the package builds the daemon, which then relies on scripts to handle computer operations. Because Guix is unsupported, we need to add a start/halt script ourselves. I think that script should be part of the service so users can customize the scripts. Does that make sense? <nckx>Yes. If it doesn't enforce a language (i.e., exec "bash" "script.sh") it could be a Guile snippet. <nckx>The default could even be parameterised so the average user needn't copy/edit it. Just (emergency-script (default-emergency-script #:address "admin@foo.com")). Or so. <RavenJoad>From what I have seen, the scripts are allowed to be pretty free-form. So we may be able to use Guile, I'm not sure yet. The Debian halt.in script uses sh and calls the apccontrol script. <RavenJoad>nckx: Perhaps it would be smarter to use the entire apcupsd package as a source for the apcupsd-wrapped package, then use a custom build system to copy things around and create the necessary scripts? <apteryx>it's caused by the u-boot update apparently: (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f)) <mfg[m]>since when does guix pull issue a GC warning? haven't seen it befoer <gabber>apteryx: user yasht reported the same error (they had locally) earlier <old>is it possible that the time-machine is limited in time? <old>I'm trying to have en environment where automake is in 1.12.X <old>Commit is dated from 2012 <old>I get this error: guix time-machine: error: open-file: No such file or directory: "/home/old/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/build-aux/build-self.scm" <apteryx>old: can't travel past July 10th 2018 <apteryx>I sent a patch recently documenting that, you may want to review it <apteryx>(it also prints a useful message error) <old>do you have a lin to the patch? I'm interested to know why this limit? <old>I suppose something fundamental was broke <apteryx>time-machine uses the inferiors mechanism, introduced at that time <old>Would it be possible to do two time-machine then? <old>One to July 10th 2018, from there a second to 2012? <apteryx>bah, commit 2/2 didn't make it it seems <janneke>apteryx: /me has been seeing the same problem crust-pine64-plus undefined when trying to add a guix version commit on hurd-team, and building guix <zamfofex>old: Maybe you can use ‘--with-version’ instead. <janneke>i have been unsucessfully trying to find how or why it breaks tho <RavenJoad>So my idea of using a second wrapper package in the service might not be possible. SYSCONFDIR gets embedded in the original binaries and points to the original store item, instead of the one that could contain our custom halt/start scripts. <old>zamfofex: I tried. however, automake is not trivial to package I found <old>anyway, I do not mind <distopico> QQ, there is anymeta- package in guix that include base packages <distopico> such as coreutils, less, man-pages etc? is to work in an --pure <mfg[m]>does someone know why latex creates a directory called { inside the current directory? It seems this is some kind of cache, but shouldn't it be under $HOME/.cache/smth... then? <RavenJoad>mfg[m]: From my experience with LaTeX, if it is a cache, then it was likely generated by something you are using in your document. <mfg[m]>RavenJoad: it really is a cache, but the file name seems weird to me, at least the first paths, which are just the store path, but somehow split across subdirectories. https://paste.debian.net/1286454/ <mfg[m]>also this is with a document that jsut has some \lipsum[] so i'm unable to spot something special that may generate this. Maybe it's normal lualatex behavior tho <latex>ACTION perks their ears at the mentions of latex <latex>Maybe this username actually sucks <juliana[m]>distopico: you can add `-e '(@ (gnu system) %base-packages)'` though that may provide more than you need <juliana[m]>I don't think there's a meta-package that's equivalent to the %base-packages variable, though <pjals_fox>wait, guix has meta-packages? what's the point, we have package lists <apteryx>janneke: in my case so far it only affects guix-past <apteryx>but it's probably something funky related to top level variables and a cycle... but I don't see where <pjals_fox>i think we have gcc-toolchain, but that does other things than just be a meta-package <janneke>in short: "./pre-inst-env guix build guix" fails on hurd-team, that has a new guix (temporary) release commit <janneke>but when i make a guix version/release commit on master, guix builds fine <apteryx>do you mean you you ran 'make update-guix-package' on that branch, and this is triggering the problem you see? <mfg[m]><latex> "Maybe this username actually..." <- sry, writing it correctly as LaTeX, doesn't ping you i suppose? <janneke>without an updated guix package, guix doesn't build for the hurd <apteryx>janneke: I opened #64745 for tracking it <apteryx>I suspect it's caused by ed5dc3a25d858a394bb7db937a51d866c3cdc6ed <janneke>ACTION hoped to find some more information and add it there, but bisecting isn't really fast :-/ <janneke>git show ed5dc3a25d858a394bb7db937a51d866c3cdc6ed <janneke>ah, right; i was focussing on cf1216d8763adf3c5e9d79d7abd2c5ecc8861d60; what you say makes more sense <janneke>ACTION goes to revert ed5dc3a25d858a394bb7db937a51d866c3cdc6ed on hurd-team before doing 'make update-guix-package', just to (see if they can) build a fresh vm <janneke>it seems that "tests/grafts.scm" hangs on x86_64... <janneke>(while building guix build guix, no progress after gnu-maintenance and after an hour or so the /tmp/guix-build-guix... directory has vanished) <latex>I don't want to go through all the nickserv hoops again <nckx>Most clients will still ping you despite the _ anyway. <nckx>RavenJoad: A hard-coded /gnu/store/…apcupsd…/etc isn't too great anyway. If upstream insists on hard-coding, /etc is better. <pjals_fox>isnt /etc only for sensitive or "dynamic" stuff? <nckx>RavenJoad: But please say that apcupsd supports some way to point it to a different directory at run time. There are services that simply create global files in /etc, and that blows. <mfg[m]>it's also for system-wide config files <nckx>I'm just saying that /etc is better than /gnu/store/${the_package}/etc, not that it's glorious. <nckx>/gnu/store/${the_package}/etc is a dead end. <nckx>/etc is just a global mess. <distopico>`gnome`, `lxqt` etc are meta-packages in someway <pjals_fox>i wonder why there isnt a /gnu/store/.../secrets/ or the like (thats probably a horrible idea) <apteryx>janneke: tests/grafts.scm passes for me <RavenJoad>nckx: So SYSCONFDIR=/gnu/store/...-apcupsd-.../etc/apcupsd is what gets embedded. The big things in that dir are scripts to handle UPS events. I can point to the config file and the PID file at run-time, but that is it. I have also set some configure flags to point things at Guix-y locations. But that is all the customization there is. <janneke>ACTION goes to try guix build guix without offloading <RavenJoad>mfg[m]: The trailing } on {gnu/store/...-profile/share/texmf-dist} feels suspect in this case. <RavenJoad>History is messy, but it should "just work"™ <mfg[m]>RavenJoad: indeed, i wonder how i could find out why exactly it gets created like this... I have no clue though. I could also just ignore it, maybe it's irrelevant <nckx>RavenJoad: I'd set --sysconfdir=/etc and install to #$output/etc (by manually invoking ‘make install’ with the right variable, or whatever). <nckx>Oh, missed your github link. Thanks. <nckx>I'll see if I spot a better solution later. <RavenJoad>nckx: That is exactly what I am doing right now. There are two parts to this: 1. Have programs in #$output/sbin get wrapped by the service to always point to the service-type's generated config. 2. Get the "You have to manually install apcupsd boot script and halt script for clean emergency shutdown" to work nicely. <RavenJoad>Especially if the user can add extras to those two scripts. <RavenJoad>Another thing, I am not sure if the boot and halt scripts are 100% necessary, since the apccontrol script has a doshutdown target which calls ${SHUTDOWN} which is shepherd's shutdown. <RavenJoad>Especially because the script in platforms/unknown/halt seems fairly shepherd shutdown-y to me. <ulfvonbe`>I'm looking at (shepherd service) and I can't help but notice that it seems like no attempt is currently made to prevent a child process e.g. produced by fork+exec-command from inheriting non-shepherd / "user" file descriptors <ulfvonbe`>for example, if I have a service constructor that creates a pipe for communicating with a child process during initialization using #:extra-ports, and then it switches to a different task that also runs a service constructor, and the second service constructor spawns a process, it will inherit the file descriptor for that pipe, no? <ulfvonbe`>there used to be an fd-closing loop within the child process prior to the exec, but it was removed some time back since shepherd's internal fds all use O_CLOEXEC <apteryx>old: the time-machine patch erroring on too old commits: #64746 <vagrantc>and if not ... do i submit a new bug to guix-patches ? can i move a bug-guix to guix-patches? <zamfofex>sneek: later tell old: If you haven’t seen it yet, check this out: <https://paste.debian.net/plain/1286453> (It should work on latest Guix!) Just: ‘guix shell -f automake.scm’ (where ‘automake.scm’ is that file downloaded on your file system) <vagrantc>well, i just sent the patch to the bug for now ... <ulfvonbe`>what's the proper way to test shepherd guile code independently? <ulfvonbe`>seems like there's a whole lot of runtime environment scaffolding <ulfvonbe`>also, I think the way the EXTRA-PORTS parameter is used in EXEC-COMMAND in (shepherd service) is flawed: consider what happens when ports corresponding to fds (6 5 4 3) are passed, in that order. You end up with the new value of fds 3,4,5,6 being the original value of fds 6,5,5,6 <apteryx>do we have a core-updates branch as of today? <apteryx>otherwise, where should a cups-filters update go? <nckx>We *have* one because I created one more or less by accident. <nckx>Hmm, I think it's missing commits. <nckx>Refresh how? Do the patches there no longer apply? These are sitting at the top of my ~/guix as we speak. <nckx>Everything pre-hiatus is a bit of a fog… :-/ <vagrantc>nckx: i was taking your pre-hiatus self at it's word in that you needed to rebase them :) <nckx>vagrantc: I have this vague but persistent feeling that I wrote more. If only I could find out what. I can resend the current patches, though, sure. <vagrantc>let's see if i can apply them, and that would settle the question :) <nckx>‘fatal: base commit should be the ancestor of revision list’ is what. <nckx>Something about ‘useAutoBase = whenAble’ confuses git. Explicit ‘--base=’ worked. <apteryx>nckx: I think we'll need a core-updates branch anyway <nckx>Good, free iproute update. <apteryx>otherwise where would all the low level things be bunched together <nckx>I could do my shrug emoji again. <apteryx>doesn't make sense to update thousands of packages to bump bash <jlicht>always good to see my (guix) patches to bump node-lts are followed by yet another version bump by the node folks within 48 hours :) <jlicht>hi nckx! Good to see you around as well <apteryx>janneke: were you able to get passed the crust unbound variable problem by reverting the commit? <apteryx>trying to build core-updates branch, I get: guix build: error: gcry_md_hash_buffer: Function not implemented <nckx>guix build: error: corrupt input while restoring archive from #<closed: file 7cd8d8db1e70> <nckx>Second time this happens tonight. <nckx>Aah, mystery solved. guix build: error: executing SQLite query: database disk image is malformed <janneke>apteryx: haven't reported yet, because i still don't have a guix package <janneke>after reverting, make update-guix-package, ./pre-inst-env guix build guix, i get (on x86_64): <janneke>ACTION added a 'HACK' commit disabling those tests, make update-guix-package, rebuild ... <squeaktoy>I can't do a chroot becasue then I lose internet connection <nckx>It writes a new system to /gnu (and /var/guix) and anything left over there from the old system will be GC'd later. Everything else will be untouched. It depends on you whether that is ‘destructive’. <nckx>I don't think it's a good idea to do it on a *running* Guix System, although I've never tried. <nckx>I'd use the Guix installer image in your case. <ulfvonbe`>well hey, those tests fail for me too. Except store-roots.scm, but that's because I modified it to not throw errors if the file it tries deleting doesn't exist and to expect the empty list <ulfvonbe`>re: guix init, the only effect it has on the host system is adding stuff to the store and possibly some bootloader stuff <ulfvonbe`>if you use efi, it may try setting some efi variables, even if the host system doesn't use efi <ulfvonbe`>other than that all modifications are under the install prefix, typically /mnt <nckx>The salient point is that it's limited to /mnt/gnu and /mnt/var/guix, though. <ulfvonbe`>my current system came into being when I ran 'guix init' targeting an attached hard drive from an ubuntu system <nckx>Since your statement could be taken as ‘anything under /mnt is in danger’, which it isn't. <ulfvonbe`>well, the process of building stuff will also add things to your host store (/gnu and /var/guix), but yeah <nckx>True, but that should be strictly additive. <vagrantc>nckx: thanks for rebasing those patches, they apply for me now ... haven't yet tested... <gnucode>nckx did you develop the privledged-programs patches? <nckx>Throw yer criticism over 'ere.