<jonsger>it's nice to have qgis packaged, although I should give the package some love :P <doncatnip>damn .. just wanna quickly package some rust app and bam 800 lines scm dependencies and no end in sight -.- <nckx>Rust, Go, fast, choose 1. <Romulus>Still waiting for a modern graphics card to run on Guix. <doncatnip>It looked like AMD were the good guys for the longest time .. nouveau and such .. but their Ryzen APUs are just nasty .. a real shame ***stikonas_ is now known as stikonas
<atomsk298[m]>Hello, I am having an issue with my installation, as network manager refuses to connect to wifi despite providing it the correct password <jsoo>sneek: later tell lfam: bpf in linux-libre-5.9 looks good :) <sneek>lfam, jsoo says: bpf in linux-libre-5.9 looks good :) <jsoo>I need to write some docs on bpf. Would that be a cookbook topic? <leoprikler>doncatnip: apparently that's only for the blobbed kernel tho, not so much if libre is a concern for you <drakonis>jsoo: bpf has a variety of official docs tho <jsoo>True there are a couple steps required to enable it on the guix system though <jsoo>You need the linux-libre-with-bpf kernel <jsoo>Ah. It used to require a separate base file-systems but it looks like debugfs is enabled in %base-file-systems now <vagrantc>wow. more "this packages" and "allows to" since i last checked. <doncatnip>leoprikler: thats what i meant .. of course it runs fine on linux, but i was hoping that amd would open up completely since that was the tendency that they have shown a few years ago <drakonis>i wonder what's the point of maintaining an separate package for ebpf <jsoo>vagrantc: sorry! What's the right way? <jsoo>I think part of the confusion comes from the lint for descriptions not to start with the package name <atomsk298>Hello, Im having an issue with my install. Im trying to connect to wifi with nmtui, but I keep getting an error saying secrets were required but not provided. What might be causing this? <jsoo>rekado: hi :) do you know much about how to setup the GHC_PACKAGE_PATH in the haskell-build-system? I seem to be missing installed libs after the refactor <jsoo>rather, the packages are installed under $out/lib instead of under $GHC_PACKAGE_PATH <vagrantc>jsoo: somewhat depends on the context, but usually "This packages" -> "This package" <vagrantc>probably most of my commits to guix are typo corrections :) <jsoo>i see. Well I do use "This package" (singular). It still feels so unsatisfactory as a description though <jsoo>allows to seems like a good place for active voice about the action of the package. I tried to start using that after seeing your commits <vagrantc>i suspect there's some linguistic thing for non-native speakers regarding pluralizing that phrase <jsoo>Totally. No judgement there <vagrantc>but i'm not making any huge editorial decisions, just fixing blatant typos and grammer :) <vagrantc>i've apparently fixed only a little over 50 occurences of "This packages" <vagrantc>really something that could be catch with a basic lint checker <vagrantc>in fact, that's how i find it, when i build guix packages for debian, my standard workflow runs lintian on the resulting packages :) <vagrantc>seems all the tests that use bootstrap binaries need to check network-available first <vagrantc>wheee... accumulating a bunch of patches to disable tests when networking isn't available... <guixy_>How can I check what graphics driver xorg is using? <guixy_>I want to use integrated Intel HD graphics. What command should I run and what output should I expect? <apteryx>perhaps a simple thing to do: lsmod | grep video <apteryx>it'll show you which video driver is in use <apteryx>also in /var/log/Xorg.0.log, you should see which driver is being loaded. On my system: "703.373] (II) Loading /gnu/store/...-xf86-video-nouveau-1.0.16/lib/xorg/modules/drivers/nouveau_drv.so" <guixy_>I don't see /gnu/store/...-xf86-video-intel/lib/xorg/modules/drivers/intel_drv.so <lfam>Before I go down the rabbit hole... does anyone have an example of a Guix package that expects the packager to provide a copy of the sqlite3.c "amalgamated" source file? <bavier[m]1>lfam: the source of our sqlite package has the "amalgamated" sqlite3.c in the top-level directory. I don't know right now of another package that uses it. <lfam>Thanks bavier[m]1. Yeah, I'm currently writing a phase to unpack the tarball and copy the file over <lfam>I looked at the handwritten Makefile and decided this would be easier <lfam>It's easier for me to write package definitions than Make <lfam>I didn't even check the license yet <lfam>I don't think it's free, now that I look at it <lfam>It's frustrating. I see a similar pattern in radio-related software as in other domains: the underlying support code and toolkits are free, but the applications are not <lfam>Even for gratis stuff like this <bavier[m]1>I've felt frustrated with some of the retro-computing stuff. A lot of stuff I've found is "source-available" so it's hard to do much with it. <lfam>It doesn't seem to have helped these programs much... having to copy files around and write a custom installer <lfam>I noticed Guillaume pushing a lot of commits to (gnu packages radio) <bavier[m]1>maybe a few other people then. I think it was jackhill I spoke to before about some radio things <lfam>It would be awesome to have a Guix-based mesh radio appliance that you would plug a radio into and seamlessly join a net ***amfl_ is now known as amfl
<apteryx>few, I think I nailed the problem where generating system disk images with the grub-efi-bootloader would fail <jackhill>bavier[m]1, lfam: yes, I'm interested in radio things. I come from the amateur radio side of things, but am interested in other applications as well. <jackhill>My experience is that radio amateurs seem to be split on caring about software freedom and other friendly software practices :) I hope to help improve that in the future. ***amfl_ is now known as amfl
***amfl_ is now known as amfl
<jgart[m]>is there currently a way to show the package definition source of a guix package from the command line by just calling it globally? Something like `guix package --show-source stapler` for example <lfam>There is `guix edit stapler`, but that's not quite the same <vits-test>atomsk298: Did U tried to delete the configuration and start anew with nmtui? <jgart[m]><lfam "There is `guix edit stapler`, bu"> I would like a tool that I could pipe guix package definitions into. Is there a way to currently convert a guix package definition to a nix expression? <jgart[m]>or can the derivations produced by guix be built and output into a `/nix` store? <apteryx>has anyone experience running the disk images produced by Guix with QEMU/GNOME Boxes? <apteryx>ah, that's documented in the manual :-) <vits-test>apteryx: do U system supports kvm? It may be the reason for Boxes not working (if it enabled by default, IDK). <xelxebar>apteryx: What is breaking? Are you able to run qemu directly? <Minall>Hello Guix Community!... I'm trying to install guix manually, since for me, the GUI is bugged... However, I'm getting an error 'Wrong type argument i position 1' when tring to init my config.scm... The problem is inside filesystems (I've debugging), and I'm using the config.scm example as a base> https://termbin.com/0zdh <vits-test>Minall: `guix system init my-os-config.scm /mnt` ? <Minall>vits-test: Yes, guix system init /mnt/etc/config.scm /mnt <vits-test>Minall: backtrace show that error is in #<procedure keyboard-layout (name #:optional variant #:key model options)> <vits-test>Minall: seem to me, U're not defined the second keyboard-layout: (keyboard-layout keyboard-layout) <vits-test>Minall: example from manual: (keyboard-layout (keyboard-layout "us" "altgr-intl")) <Minall>That's right... Thanks vits-test!, I defined it and now my new system is on place... Sorry for the noob question. I guess I had read more backtraces on other languages, but not guile <Minall>Thanks, Finally I will get Guix running... <Minall>BTW, I installed guix before in the laptop I'm installing guix right now, and... My laptop is Free, I mean, the wifi and graphics work with free drivers <Minall>So, the before installer, accepted my wifi and ethernet... And I could installed without a problem with the GUI <Minall>However, with this new installed, the ethernet is not recognized and, my wifi is started with soft block, and when I try to access one AP it stops at 'Connecting to AP, please wait...' No more messages <vits-test>troubles with GUI installer are coming and go away, it's some sort of local tradition. <Minall>Thus I had to install it manually, and use WPA_Supplicant... I assume this is not normal lol <Minall>vits-test: Welp, I hope this problem is atleast read by some people here so, we know it happened, maybe it may help in the futur <vits-test>installer not worked for me either. Also aarch64 has no installer other than "first use DISTRO_NAME, install `guix` on it, then `guix init`." <vits-test>But there more troubles to defeat, like Rust/Java packages, new Kernel versions, etc. So some mad filantrope(s) works on GUI installer from time to time. <vits-test>Minall: almost forget: GNU Hurd also being worked on by folks. <vits-test>xelxebar: pshsh.. Officier apteryx down.. suspects: Gnome Boxes, and qemu.. repeat.. Officier down.. pshsh *xelxebar gathers reinforcements <xelxebar>jgart[m]: check out copy-build-system. Maybe it has what you want? <xelxebar>Actually, you might be able to get away with trivial-build-system. <xelxebar>Grepping through the repo, it looks like gnu/packages/certs.scm uses trivial-build-system. These packages probably do stuff similar to what you want. <xelxebar>FWIW, you can check out Section 8.4, Build Systems, in the manual. <xelxebar>I just happen to know that these definitions sit under guix/build-system/, so peeked in there and found copy.scm which sounded applicable. <leoprikler>I think the problem is actually getting the origin/hash to be stable. <leoprikler>I'm not sure if SWH deals with singular perl scripts <xelxebar>Lol. Trying to do a guix pull, I kept doing a git pull and really confused myself. <nckx>xelxebar: I have the opposite problem and regularly guix rebase. <nckx>(Brain: but you're rebasing guix!) <iyzsong>i confused by guix/git several times too, you're not alone. <civodul>maybe we should do something similar to the "sl" command for when you type "guix rebase" or similar <leoprikler>I think `guix pull --rebase` is more realistic than `guix rebase` on its own, but yeah <nckx>I have literally never used git pull --rebase in my life. <nckx>guix throw && git fetch. <nckx>TBH, a happy ASCII gnu running to fetch your package would be a better sl-like easter egg than ‘moo’. <nckx>Any talented ASCII artists available before April? <iyzsong>well well.. how about 'guix update', update the 'guix' command by replace it in its profile, i think this way get rid of '~/.config/guix/current' and it's more simple.. <leoprikler>you still need to store that profile somewhere tho <leoprikler>though my personal preference would probably be ~/.guix-profiles/{guix,default,...} <iyzsong>yeah, but i can reuse the exist '~/.guix-profile'. why we need a seperated profile for 'guix'? <jgart[m]><xelxebar "jgart: check out copy-build-syst"> thanks! I'll take a look :) <xelxebar>Looks like it fails to start on my system <nckx>xelxebar: Listens on (some? all? I forget) non-VT terminals like serial consoles to present a log-in prompt. <xelxebar>nckx: Cheers. Grepping through the entire repo for the symbol 'term-auto' finds nothing, so I was at a loss of where to look for more info. <nckx>Yeah, it's a constructed string, like the term-{tty1,tty2,...} ones. <nckx>Try grepping for '"auto"'. <nckx>xelxebar: gnu/services/base.scm <civodul>dannym: i'm looking at the nfs-server-test, which fails, and a couple of things look fishy; like why are the port-fowarding lines commented out? <xelxebar>nckx: Yeah, I figured something like that. Thanks for saving me the work of hunting it down! <xelxebar>For someone running a guix system, does your shepherd show a running service for something sound-related? alsa/pule etc? <cbaines>xelxebar, mine doesn't. I'm not sure alsa is a service in the shepherd sense, and Pulseaudio is autostarted by default I think. <xelxebar>Even though alsa-service-type is in services, for some reason I do not see pulse running. <cbaines>Guix services don't directly map to shepherd services, that's just one interaction with the system which a service can have <cbaines>xelxebar, are you using Pulseaudio, or not? <xelxebar>cbaines: I am using alsa-service-type with its defaults, which I am lead to believe uses pulseaudio. <cbaines>xelxebar, OK, and are you using Gnome, or a different desktop environment? <xelxebar>cbaines: Yeah, I was just curious if alsa-service-type should be starting some related shepherd service. Thanks for the clarity, though :) <xelxebar>cbaines: No desktop environment. I am manually invoking xinit. <xelxebar>Ah. I see, this looks to just be creating /etc/asound.conf, which I do see realized. <cbaines>emys, I've just had a quick look, and it looks OK generally. "@code{<git-reference>}" is mentioned in the documentation you're adding, which looks like a copy/paste error, but it looks fine apart from that <nckx>emys: The patch itself looks OK to me too (s/mercurial/Mercurial/ in prose). Which use case does it enable, or bug fix? <nckx>The ‘separate-store-os’ (and surely others) fail to build cunit. Can anyone reproduce that? <nckx>Actually it fails to download the source? Hm. *nckx pushes 4-year-old hibernation patch. <zimoun>nckx: about git/guix pull/rebase, I have a git subcommand doing ’-C ~/.cache/guix/checkout/pj…wq’ and I do “git guix <git-command>” as fetch, rebase, etc. And I think the perfect fit is “guix git <subcommand>” for plumbing Git-related Guix repo. If I have read correctly. <cbaines>I've got access to two Fosshost machines to install Guix on to, which is exciting! <cbaines>However, I'm currently stuck on what ip commands to type in to the installer system to setup the IP address and gateway... <cbaines>Wooo! I finally muddled through it... <xelxebar>Fosshost! I didn't know about these guys! <cbaines>My initial plan is to hook them up to the Guix Build Coordinator instance I've been running to build patches, but that's not necessarily a long term plan <nckx>zimoun: I'm not advocating for guix aliases if that's what you mean. Never have. Your -C workflow is interesting though. Does it save much time compared to (my/classic) cd ~/guix && git do-stuff && guix pull? <civodul>are they also going to be used to run BBB? <cbaines>there's a 3rd VM for that, which I can see through the web interface I'm logged in to <nckx>cbaines: Ooh, what're the two others for? <zimoun>nckx: “git -C ~/guix do-stuff“ is equilavent to (your/classic) “cd ~/guix && git do-stuff“. But ‘guix pull’ uses the Git repo under ~/.cache/guix/checkouts/pj…wq, did you tweak it to use instead ~/guix? <cbaines>nckx, well, anything "we" as the project want them for really. The initial approach I was taking was setting them up to build packages for patches. <jlicht>RE the recently upstreamed hibernation patches; is it safe to hibernate after a `guix system reconfigure' /w kernel updates? <zimoun>nckx: the plan with the Outreachy ‘guix git log’ is to add a “simple” Git sub-command doing the plumbing, as an experimental proof-of-concept. <zimoun>civodul: yes Fosshost will be used to run the BBB. <nckx>zimoun: I work in (and pull from) file:///home/nckx/guix, so ~/.cache/guix/checkouts is only updated by guix (pull), never by hand. <nckx>Does your 'flow save a guix pull? <zimoun>it is experimental because it is easy to break <nckx>What happens when you ‘guix pull’? <nckx>But it doesn't clobber your work in ~/.cache/guix/checkouts/foo? <nckx>That's what scares me: storing your ‘valuable’ work in ~/.cache and the potential for guix to (rightfully) say ‘that's my zone, Imma clobber it because it doesn't match what I expect’. <nckx>In fact it's so scary that I suspect I misunderstand what you're actually doing 😉 <nckx>cbaines: That's wonderful. <zimoun>well, maybe I miss the aim. I have also a “~/src/guix/” with different branches checkout and I use ./pre-inst-env <nckx>I use pre-inst-env to quickly test packages while I'm editing them, but I use guix pull + several file:/// channels to actually install packages & reconfigure my System. <zimoun>however, I use “git guix pull” which only pulls ~/.cache/guix/checkouts but avoid to compile a lot of derivations, or “git guix log” or “git guix show”. The point is as simple user, I do not need another checkout since there is already one. <nckx>I have two nckx channels with custom packages, kernels & the like, without which my system won't boot. <nckx>zimoun: Could you share your git alias configuration? I'd like to try it out. <cbaines>Is there a way to start the graphical installer when SSH'ed in to the installer OS? <civodul>cbaines: i think if you run "herd status" you should see the installer somewhere <civodul>you can check its command line in /proc, stop it, and then start it by hand in your console <cbaines>I found some -installer store item in the store, and tried running it <cbaines>ah, damm, even though I've got networking working, whatever the installer expects to work, doesn't <civodul>like it doesn't see your network devices? <cbaines>I don't know, eth0 exists, and it's now connected, but DHCP doesn't seem to be a thing on these machines <cbaines>maybe the installer doens't like DHCP not working <nckx>jlicht: The kernel wasn't touched (always supported hibernation, so no update required). The changes are to the initrd, so if that's up to date it should all work. <cbaines>this is also the installer for the current release <zimoun>civodul: I am not scaling very well and I have not done so much about the NEWS these days. Did you do? And I am a bit lost about the next steps <nckx>jlicht: Otherwise, no change to the previous behaviour, which was probably ‘hibernate successfully but throw away the image as if there were a power cut’ because we didn't know how to resume. I don't actually know, I've been using this patch for 4 years. <civodul>zimoun: yes, i pushed a preliminary NEWS file and i'm working it on and off <civodul>i also started thinking about the blog post for the web site <civodul>and also about ideas for a "roadmap" kind of talk for the Guix Days <civodul>cbaines: yeah i think the installer expects DHCP <civodul>but there's a secret trick you can use to skip the networking stuff <civodul>cbaines: create a file called /tmp/installer-assume-online :-) <civodul>make sure to get networking up and running beforehand <cbaines>civodul, ooh, exciting, I've got to the next screen now! <zimoun>civodul: so if I pull, I have your last NEWS files, right? So if I add stuff in, I send then the patch via guix-pacthes, right? <civodul>zimoun: yes, in the 'version-1.2.0' branch <civodul>if you send changes, make sure to ping me here :-) <jlicht>nckx: so the only thing you shouldn't do is have hibernation enabled, reconfigure to an OS _without_ hibernation support -> hibernate -> boot <jlicht>as that is how I trashed one of my first GuixSD installation <zimoun>cool! I was looking at. I fetch. :-) ***amiloradovsky1 is now known as amiloradovsky
<cbaines>I used fosshost1 and fosshost2 as the hostnames for the two new machines from fosshost, shall I edit the knot config to add .guix.gnu.org domains for them? <cbaines>Once I've sorted out some initial config, I can try and move the config in to maintenance.git as well <nckx>sneek: later tell jlicht: Right. Reverting to a broken generation will still be broken. Going forward, resuming a hibernated system from an older generating with hibernation support will be pointless (because the old kernel+initrd is completely discarded in favour of the hibernated kernel+user space), but should work. <nckx>sneek: later ask jlicht: Please let me know what works for you and more importantly what doesn't. <vagrantc>does it make sense to have NEWS mention things that fixed regressions in-between releases? <vagrantc>e.g. the issue was not present in previous release, and not present in upcoming release... <nckx>(Plus, that's a loooong list.) <vagrantc>i just noticed that, since it was broken last month, and fixed recently <vagrantc>well, being the reporter, i happened to be more acutely aware of it :) <vagrantc>but i suspect others are present as well... <nckx>civodul: Does it make sense to cherry-pick b9abb30 to 1.2? *nckx super biased in favour & all, but should be very low risk & it's a fun if overdue bullet point. OTOH, we've had few complaints over the years. <civodul>vagrantc: ah right, if this issue wasn't present in 1.1.0, we shouldn't mention it <civodul>so i guess i should remove it, right? <vagrantc>that one for sure ... was curious about the time-travel with pre-guile 3.0 too *vagrantc forgets when the switch to guile 3 happened <civodul>well, there've been different stages of switching <vagrantc>oh, time-travel was introduced in this release ... so obviously it couldn't be a change :) <civodul>nckx: it's super cool, rather safe-looking, but i'd tend to keep it for master <civodul>vagrantc: time-machine was introduce in 1.1.0, but "time travel" goes back to 0.15.0 *vagrantc notes that time-machine can also be used for interdimensional travel unrelated to linear time <vagrantc>you know, the parallel universes of core-updates, master, version-X.Y.Z <civodul>what i meant is that "guix pull" in 0.15.0 could already move to a different commit, etc. <vagrantc>right! time-machine just facilitated the process <zimoun>civodul: is it possible to tag the older commit accessible with time-machine? <minall_>Hello Guix Community!... Any tutorial on how to set exwm on GuixSystem?, and, If I delete xorg services and gnome services, I will have just a terminal right? <civodul>uh, just today a second "guix gc" fired on berlin while the first one wasn't running <cbaines>I don't quite follow about the berlin gc thing, does that just mean it's close to running out of space? <nckx>civodul: hibernation: Okido. gc: Does that mean what I think it means? (lost work) <vits-test>minall_: w/o manager like gdm, sddm, or slim it may be a bit hard to set up a graphic session with X. It's much easier with sway. Literally `sway` from console, but it need elogind-service. ***grumble is now known as \x2D
<apteryx>vits-test, xelxebar thank you; I think part of the problem was that it was 2 a.m. ;-) <apteryx>the other part is my inexperience with 'guix system disk-image' with regards to what flags should be provided to boot with QEMU when using a bootloader installed to the EFI partition. Mathieu shared a command line: "qemu-system-x86_64 -m 1024 -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin -hda disk.img". *jonsger had prepared the openSUSE packages for the upcoming 1.2.0 release :) <mbakke>civodul: oh my, have you been able to assess the damage from the double GC job? <mbakke>is Guillaume (glv) available on IRC? <civodul>mbakke: no damage other than the fact that we spent most of the day GC'ing <civodul>cbaines: so yes, it does "gc -F3T" once a day and "gc -F1500G" 12h later <civodul>normally the second one is a no-op because there's enough free space by then <civodul>but in this case we consumed more than our "quota" in 12h, hence the 2nd gc <civodul>vagrantc: what are the prospects of getting 1.2 in Debian? :-) <pineapples>Are there plans to re-work the bootloader installation procedures so that they're not invoked when a bootloader package hasn't been updated? <pineapples>When I came to think about it, isn't writing to NVRAM on every guix reconfiguration on EFI machines shortening the lifespan of the on-board flash memory of the user's system? <nckx>pineapples: How do you reliably detect that? <nckx>pineapples: I've wondered the same thing, although I doubt it's significant. <pineapples>Another thing that comes to my mind is that the user's boot preference is overridden, too <nckx>pineapples: That can be fixed (and probably should). <nckx>There must be a way to ask GRUB/efibootmgr not to make it the default? <pineapples>So far I've been maintaining a custom grub installation procedure that appends the --no-nvram flag to grub-install. This is less than ideal, but hey, there's the doubtful benefit of not making unnecessary writes to my system's NVRAM <nckx>...as you noted in the mean time. <nckx>pineapples: It shouldn't be the default, but an (nvram #f) option makes sense if you want to submit a patch. <nckx>pineapples: But GRUB updates so immensely infrequently that (installer #~(const #t)) works just fine in practice. <pineapples>nckx: Unfortunately, neither the (nvram #f) option nor (installer #~(const #t)) are ideal. If the user needs to reinstall Guix System, their system configuration will not be usable as is (guix system init will not install a bootloader in case each of those is employed). At the very least learning Guix when not to write to NVRAM would be the second best solution after the one where a check whether the package has been updated is <nckx>pineapples: How do you reliably detect that? <pineapples>Well. For appending the --no-nvram flag: check if the user initializes a fresh system from the live installation environment or reconfigures an existing installation, and only append the flag if the former is the case. For detecting if the grub package has been updated: I have no idea what internal changes would the bootloader code have to undergo to be able to detect if a bootloader package has been updated since the last time <nckx>pineapples: OK. Whether the same system is installed with ‘guix system init’ vs. ‘guix system reconfigure’ should definitely not change the behaviour. <pineapples>nckx: I'm not in the position to disagree. Thank you for your time! I hope you didn't find this discussion aggravating. I'm trying to come up with ways how to improve Guix and make it on a par with NixOS, without all the needed Scheme hacking skills ^^' <nckx>pineapples: I don't disagree but the proposal and implemention go hand in hand. And the NVRAM issue and GRUB version detection are unrelated IIUC. <mbakke>pineapples: do you know how Nix solves the NVRAM issue? <nckx>ArneBab: Thanks for that! I asked about the ‘why’ earlier. The code itself LGTM but the bug # itself is a bit opaque without a rationale. If you support this change, it would help to add one to the thread. <nckx>That's the noise I make when I read Perl too. <pineapples>nckx: Dn, as far as I'm concerned, I'm not even a Scheme hacker to begin with haha <nckx>I'm too tired to read Perl & will do so tomorrow 😉 Good night. <civodul>ouch, that has me willing to go to bed, too <nckx>(‘state file’ confirms my suspicions and makes me hmm, but I'll be less judgmental after a good night's sleep 😉) o/ <mbakke>pineapples: oh, so it reads a state file that consists of the GRUB derivation as well as boot parameters, and only installs if the computed state is different from the stored state <ArneBab>nckx: I posted a rationale now — thank you for prodding! <pineapples>mbakke: Correct!... Or so I think –– I've never touched any Perl code before, but I trust nckx's reckoning. Also, pardon the lack of a mention, I was about to ping you :( <pineapples>Hmm. Okay. There's a state file of sorts involved in the process <mbakke>pineapples: feel free to file a 'wishlist' bug about this, mentioning your concerns and ideally also a link to the Nixpkgs solution for inspiration <vagrantc>civodul: working on getting 1.2 ready for debian ... having very different results with the test suites depending on which machine i build it on <vagrantc>but it builds ... haven't tested it in a while <vagrantc>also tricky as there's an issue with guile-gnutls on guile 2.2 vs. guile 3.0 ... but i've prepared all the other relevent debian packages to work with either guile version 