<NieDzejkob>mbakke: you may also bother me if rekado's not around ;) <mbakke>NieDzejkob: good to know :-) I think I should learn myself a haskell soon, I played around with Elm a little and enjoyed it <NieDzejkob>have fun! I also started somewhat recently, so I could be useful to you as someone who hasn't been cursed with knowledge yet... if you hurry <NieDzejkob>the rest of us only pushed commits on the branch, technically creating work for his <NieDzejkob>how can I .include the pulseaudio config file from /gnu/store/.../etc/default.pa without hardcoding the path? <NieDzejkob>argh, I would be done now if they used guile >:( ***ezzzc9 is now known as ezzzc
<mbakke>NieDzejkob: does /etc/pulse/default.pa work for you? <NieDzejkob>oh, maybe I should add a pulseaudio-service-type? <mbakke>NieDzejkob: ah yes, you'd need that <mbakke>NieDzejkob: if you go that route, might as well put your custom configuration straight into the service configuration :-) <NieDzejkob>hmm. I'll let you know how that goes tomorrow. I'll settle for a hacky workaround for now <clodeindustrie>I have two questions, should I run `guix system init config.scm /mnt` with sudo? Shoud I run in particular anything with sudo when it comes to guix? <clodeindustrie>and well actually that's 3 questions, when running that command, the process crashes when trying to build glibc-2.26.6.drv how would one go at debugging something like this? or what are people's way of dealing with crashes when building? ***terpri_ is now known as terpri
<roptat>clodeindustrie, these instructions are for guix 1.0.1, I suppose you used 1.1.0 instead? <roptat>you probably want to enable substitutes if you didn't, as it will allow you to get packages without having to build them <roptat>for sudo: in general you don't need to run guix with any priviledge, because it has its daemon <roptat>but when installing or reconfiguring the system, you need to use root priviledges. You have to use sudo with "guix system init" and "guix system reconfigure" <roptat>you could think in terms of multi-user: reconfiguring or installing a new operating system is not a task a simple user should be allowed to do, because it impacts other users as well <roptat>whereas installing a package, or building something has no impact on other users, so it's safe to do as normal user <roptat>going to bed, I hope I could help a bit <jsoo>i'm looking at the bpf tools that seem to have become popular recently. i keep getting errors when building bcc <jsoo>well i do have the wrong version of the supporting libbpf library. i will see if that helps <jsoo>thanks for listening, guix. it helps a lot <marusich>Is there a way to tell Automake to print out the test results in real-time, or somehow show more verbose progress, when running a command like "make check TESTS=tests/lint"? <marusich>It runs and emits no output for a long time (minutes), and then finishes. Then the output is available in test-suite.log. That's nice, but it'd be nice also if it printed some progress. ***ramajd[m] is now known as Reza[m]
***wxie1 is now known as wxie
<leoprikler>perhaps you can tail -f the log file for the test, e.g. tests/lint.log <marusich>leoprikler, not a bad idea. I guess I should have thought of that. I'll try it out next time <marusich>Hmm, it seems that kinda/sorta works. There are still very long pauses (minutes). <leoprikler>that's probably because the output is not flushed that often <leoprikler>I had a similar problem in one of my own libraries, so explicitly flush after each line <leoprikler>(this is semi-important, because there computation can take hours just to get to that line) <Baerwin>Anyone here who might help me, please? I tried mounting NFS file-system under guixSD I managed to get an entry in fs-tab with the config but when I try to actually mount it with mount -a I get an error saying to use mount.nfs instead of mount -t nfs. When done manually it works. I'd like to automatically mount it however, any ideas? <Baerwin>I don't actually modify fstab manually I have a little something like this: <guix-vits>jsoo: "...: error: ‘BPF_TRACE_FENTRY’ undeclared (first use in this function); did you mean ‘BPF_PROBE_ENTRY’?" --- did you tried with parrallel build switched off? <Baerwin>just a small excerpt from the config and that seems to work, but mounting itself gives the error <Baerwin>I do get that but I have the same entry on my nixos setup and that can be mounted no problem <direbanana>Hello all, I understood this is the place to come to for some help with Guix (also for noobs). Is that correct? ***rekado_ is now known as rekado
<direbanana>I installed GNU guix two weeks ago. It's not on my main partition, but a secondary one to toy around with. Since the grub on my main partition somehow does not recognize the Guix partition, I boot into the grub on my Guix partition using a grub rescue stick. From that Guix grub menu, I choose the generation I want to boot. <direbanana>This worked fine the last time I tried (two weeks ago), but today it fails at the point where I choose what to boot in the Guix grub menu. Whichever option I choose, I get <direbanana>That is where I am stuck, as I don't understand the bits of advice my internet search has yielded. (They are mostly meant for situations that don't seem to apply to me.) <rekado>direbanana: I’m not very familiar with grub. I hope someone else here can help. <rain>direbanana: what file systems are involved and which device is grub installed to? <leoprikler>a quick grep shows our grub modules reference those functions <direbanana>rain: my main and my guix partition both use ext4, if that is what you mean. I understand a mini grub is installed on the boot sector and points to a real grub. In my case the mini grub points to the one on my main partition, which is aware of the Ubuntu installation on that main partition, but not of the Guix installation on the Guix partition. The Guix partition also has a grub of its own. <direbanana>leoprikler: I'm afraid I don't understand your answer. I barely know what grub modules are. Do you mean that Guix has some of its own grub modules with extra functionality? I searched the Guix documentation and didn't find any mentioning of it. <rain>direbanana: that seems rather involved o_o is installing GRUB that way even supported? <leoprikler>I don't think it's "extra" features – I think it's a linkage problrm <direbanana>rain: Involved is an accurate description. To boot into Guix, I have to insert the grub rescue stick and manually set the grub prefix and root to the Guix partition, then do insmod normal and normal. However I never considered it /not/ to be a possibility. Do you know a better way of setting up this dual boot? <NieDzejkob>direbanana: I'd let Guix control the bootloader and make it recognize the Ubuntu partition as an option <leoprikler>then try to first get guix booting without the rescue stick <direbanana>NieDzejkob: I tried that at some point. Running grub_mkconfig in either Ubuntu or Guix will not make it recognize the other installation. <leoprikler>you have to add the ubuntu entry to your config.scm <NieDzejkob>yeah, see menu-entries in (guix)Bootloader Configuration <clodeindustrie>hi, `guix pull` is currently crashing for me, does this mean that something is being built on one of my channel? <NieDzejkob>clodeindustrie: define crashing. segfault? exception? <NieDzejkob>and yes, trying to pull with only the default channel would be a good idea <clodeindustrie>I'll have a try but I feel like this is coming from the default one <Bryophyllum>I'd spent quite a lot of time trying to come up with a way to *declaratively* define my aliases in the Configuration System: I had read gnu services source code in search of real-world examples, had extensively looked through the manual, but I was unsuccessful getting anywhere. Is extending Guix with a (subjectively) complicated service module the only way at the moment? Is there a subjectively easier way? I'm a signle "git com <Bryophyllum>mit" away from deploying Guix on my production machine, but the inability to configure aliases declaratively is what holding me up. I'd prefer not to manage my user account .bashrc by hand, but, at the same time, I can't afford to put off migrating to Guix for longer to give myself more time to learn Guix. <direbanana>leoprikler, NieDzjejkob: Ubuntu is already in my menu-entries. It appears as an option in the grub menu on the Guix partition, but gives the symbol not found error. Also I don't think I can let Guix take control of grub. The only way I know to get boot sector grub to point to the Guix partition('s grub) is by performing some commands within the Guix partition, into which I cannot boot at the moment. <guix-vits>Bryophyllum: Do You want an declarative /etc/skel? To all new users get some predefined aliases? <NieDzejkob>I use the approach of a dotfiles repo that also contains the guix configuration <NieDzejkob>Bryophyllum: you could use special-files-service-type, I think <rain>direbanana: there is a dirty workaround if you can't boot from grub. boot into Ubuntu and kexec into Guix. i used to do that from Arch. (for complicated reasons related to firmware bugs) <leoprikler>so you're now getting to guix grub directly and it still fails? <direbanana>leoprikler, NieDzjejkob, rain: To break the vicious cycle, I would have to boot into Guix from the grub on my Ubuntu partition. That might work, but I don't know how to get that grub to recognize the Guix installation. <guix-vits>NieDzejkob: Hi. Do you know, by chanse, from where the default /etc/bashrc comes from? <Bryophyllum>NieDzejkob: I don't see how this service would be useful in my case, but thanks for your input <leoprikler>i don't think guix' grub is that different from ubuntus <NieDzejkob>Bryophyllum: you could use it to define the contents of /etc/bashrc <direbanana>leoprikel: no, not directly. I don't know how to get boot sector grub to point to the Guix partition without already being in the Guix partition. <NieDzejkob>guix-vits: a quick grep suggests gnu/system.scm, line 767 <NieDzejkob>ah, looks like I used an older checkout of the repo <guix-vits>Thanks. (i'm only came to NEWS.txt for "* Changes in 0.8.2 (since 0.8.1)" so far) <rain>direbanana: i don't think that's how that works. the partition you install grub to shouldn't matter. but where you install it from does matter. i've had problems on Arch when i accidentally installed grub from the live system instead of chrooting into the installed one. <rain>what you probably want is to unify the config files. <rain>but i'm largely guessing here. <Bryophyllum>niedzejkob: according to the description, special-files-service-type creates special files, such as "/bin/sh" . I fail to see how to put this service to use in my usecase <NieDzejkob>hmm, I was thinking you could use it to create /etc/bashrc, but that would conflict with the file that's already there <NieDzejkob>I wonder how etc-service-type handles it when it gets two files with the same name... <direbanana>rain: How strongly do you recommend the kexec option, then? I looked at the man page and Arch wiki. It seems pretty dangerous, right? <Bryophyllum>niedzejkob: Exactly. I'm afraid that a rewrite of the code responsible for generating the default bashrc is required in order to allow users to extend the file with their own code. <rain>direbanana: i wouldn't say dangerous, but it takes a bit of know-how. for me it was as simple as reading the /boot/grub.cfg file from the guix partition, finding the kernel path and the kernel arguments, loading the kernel with the kexec command, loading the arguments with the same command, and running sudo systemd kexec. <rain>direbanana: well, depending on your setup it might be more dangerous. maybe some drivers will burn your computer. idk. <rain>direbanana: but systemd kexec is supposed to handle this pretty nicely. it properly shuts everything down. <janneke>hmm, i cannot seem to find where to increase increase the size for the installed-extlinux-os test, i keep hitting guix system: warning: at least 1376.8 MB needed but only 1241.1 MB available in /mnt <NieDzejkob>I'm thinking we could remove bashrc from the default etc-service and instead create a bashrc-service-type that would extend etc-service-type with a bashrc it generated *janneke goes to read the code, rather that just bumping *-size <NieDzejkob>clodeindustrie: could you send a short note about this confusing error message to bug-guix@gnu.org? <direbanana>rain: The operation you describe does seem within my capabilities. But I am pretty scared of harming my Ubuntu installation. <rain>direbanana: i don't think running kexec will result in any permanent modifications. <rain>the kexec command loads everything into memory. it doesn't change your bootloader settings. <Bryophyllum>niedzejkob: My exact thought. Though, from the perspective of fresh Guix blood I am, I have no idea how to implement that, without causing merge conflicts in etc-service-type. <mbakke>uuugh there are a gazillion merge conflicts on core-updates due to the cherry-picked merge a while back <mbakke>it's tempting to use '-X theirs' <rain>is there someone who could help me with some cross-gcc shenanigans? (maybe in PMs so as not to flood the main channel) <rain>i'm trying to get the GCC 10 based devkitARM working but GCC 10 doesn't seem to be tested for embedded stuff. <mbakke>in hindsight, it would have been better to reset the branch, but too late now <janneke>mbakke: what happened, that makes that it's too late? <Bryophyllum>niedzejkob: Now when I'm thinking of what I said, I've come to realize that it may be feasible to define the default contents of the bashrc file in /etc as a %variable that along with user changes is appended to our bashrc-service-type file-like object. I hope that what I'm saying makes sense. I've never participated in designing anything before, let alone writing a program. <mbakke>janneke: a while back 104 commits from master were cherry-picked to core-updates by mistake (they meant to do a merge), and there have since been a few other commits to core-updates, which we would "lose" by resetting the branch now <mbakke>they can of course be cherry-picked, but it rewrites the signatures, and resetting branches makes it difficult to audit changes <mbakke>so I think we just have to accept the extra merge conflicts the upcoming core-updates round <janneke>ah okay -- yeah i didn't think of signatures <janneke>just imagined that the conflicts you're hitting now could be less (or the same with a nicer history) <mbakke>there would be approximately zero merge conflicts if it weren't for the cherry-picks <mbakke>FWIW 'git merge -X theirs' worked flawlessly, I'm now auditing each of the actual core-updates changes to make sure that no conflicts were resolved wrongly <bricewge1>NieDzejkob, Bryophyllum: Having a specific service for bash system config would be easier to configure for sure. <bricewge1>But better still will to get rid of files in /etc (if possible). <NieDzejkob>Bryophyllum: I'm having trouble testing this at the moment, but maybe you could use (modify-services) to grab the configuration of etc-service-type and append something to the bashrc entry? <mbakke>bah, fbd2d7c84307df00e558f722ec692247034db46e, was un-done, but I don't care enough to fix it :P <bricewge1>NieDzejkob: We could have a procedure to be used in 'user-account-shell' fields that generate a bash that never look in /etc and instead load the config passed by that procedure. <mbakke>NieDzejkob: i'll let nckx have his e51101ecda83c85b0ed9ca98dc7d9606f00dc0ac :P mainly to avoid future conflicts in that area <mbakke>also, I already made the merge commit to investigate the 'git show' diff <direbanana>rain: I tried the kexec plan. Sadly it's not working. I found the kernel image and the initramdisk in the gnu store, and within Ubuntu loaded and executed it. It simply reboots my computer. <mbakke>that seems to be the only "bad" merge, which is OK <mbakke>it's not visible in 'git show <merge-commit>' though, scary stuff *mbakke should learn how to use smerge-mode instead of relying on 'git merge -X theirs' <direbanana>rain: I'm not sure how IRC works, but in case you didn't notice while you were away: I replied to your previous advice about kexec. <direbanana>I quote myself: "I tried the kexec plan. Sadly it's not working. I found the <direbanana> kernel image and the initramdisk in the gnu store, and within <direbanana> Ubuntu loaded and executed it. It simply reboots my computer." <rain>direbanana: did you also add the proper kernel command line arguments? <direbanana>I think so. There are few examples from which to derive the syntax. <direbanana>I'll paste the exact contents of my grub.cfg and the command I executed to a paste serviec. <janneke>mbakke: you did it...yeah smerge is kinda nice -- but if the --theirs axe works that's much quicker <direbanana>rain: And the commands I tried while on Ubuntu are the following (both failed). I mounted my Guix partition in "/media/pintrix/guix-root". paste.debian.net/hidden/3446218a <rain>direbanana: some of the arguments are wrong <rain>direbanana: leave the kernel arguments as they are. remember, you are booting into a new kernel. the current one's mountpoints are meaningless to it. <Bryophyllum>bricewge1: May you elaborate on the motivation for moving system configuration files out of /etc? I'm curious <rain>rain: oh, wait, the second version seems ok... <rain>yup, the one on line 3 seems fine. and then you sudo systemctl kexec? <direbanana>That's the first thing I saw on Arch wiki. I forgot about the other way. I'll try that now. <rain>direbanana: kexec -e didn't work for me either when i tried it. only the systemctl way. <direbanana>Interesting. I find out I don't have "systemctl" installed. Which is strange, since I do think I am using systemd (Ubuntu 14.04). <Bryophyllum>niedzejkob: without the extension proposed in the issue linked by bricewge1, (modify-services) won't work in our case (basically repeating what bricewge1 said since you could've overlooked their message) <rain>direbanana: according to wikipedia "Ubuntu 15.04 used systemd instead of Upstart by default." <rain>direbanana: not sure if that means that's the first one. anyways, i gotta go. i hope you figure this thing out. <rain>direbanana: no prob bob ^u^ <rekado>within the next hour I’m going to shut off ci.guix.gnu.org, move the disks to a new server, and connect the uplink to a new network card. <rekado>let’s hope we will see better download speeds then <alextee[m]>anyone know how you can define the default xdg-open app for directories? on gnome it's supposed to open the file browser but it opens the disk analyzer here <leoprikler>either way, it should be using your mime configuration <leoprikler>thing is, mime associations in guix are a bit weird <alextee[m]>oh it uses nautilus now, maybe it got fixed somehow <alextee[m]>xdg-mime query default inode/directory -> org.gnome.Nautilus.desktop <alextee[m]>idunno, last time i tried it it was before i upgraded guix <leoprikler>so it didn't work, you guix upgraded and it worked? <bricewge1>Does 'substitute*' support latin-1 encoding? <leoprikler>if you can, try patching the input file to utf-8 <leoprikler>or does that not work, because it must be in latin-1? <rekado>bricewge1: wrap it in (with-fluids ((%default-port-encoding "ISO-8859-1")) …) <alextee[m]><leoprikler "so it didn't work, you guix upgr"> leoprikler: yeah it looks like that's what happened. <alextee[m]>xdg-open on directories before was opening the directory in the disk analyzer instead of in nautilus <bricewge1>rekado: It worked, thanks. I'll need to look into with-fluids, I saw some reference to fluids in the doc already but it looks like wizardry to me <NieDzejkob>fluids are basically global variables done right *janneke closes two hurd bug reports <rekado>ci.guix.gnu.org will go down in a few minutes <guix-vits>janneke: is `herd status` and `guix xyz` will be available soon on hurd? <guix-vits>or ``“guix build --target=i586-pc-gnu”, copy the software ...'' <janneke>if you add "(service hurd-vm-service-type)" to your system configuration <janneke>then you can just ssh -p 20022 root@localhost into your childhurd <janneke>and have herd status, guix build ... <janneke>well, you have to be a bit careful with what you put on the dots after build <janneke>actually, that's where the real work will start <janneke>yeah, "someone" came up with that crazy idea last week <guix-vits>i do slightly remember i'd read the conversation. <janneke>and you may have to specify a larger disk-image in the service description if you really want to do some build work, etc. <rekado>swapped the disks, let’s see if the new server can detect the external storage <rekado>server initialization takes a long time… <rekado>it gets stuck trying to mount the external storage <rekado>probably need to map the new HBA card on the storage <janneke>bah, if only someone would make computers easier <rekado>management of this *only* works through a Windows machine with a terribly confusing proprietary Dell GUI… <rekado>booted it but now need to set up the IP addresses as the NIC names have changed <nixfreak>you can install cargo though by guix install rust:cargo <rekado>I hope this actually improves download speeds <guix-vits>rekado: "substitute: guix substitute: error: TLS error in procedure 'handshake': The TLS connection was non-properly terminated." <- just in case, probably my bad. <nixfreak>I'm trying to install this rustup update nightlyrustup target add wasm32-unknown-unknown --toolchain nightly <rekado>I’d be happy to hear some speed check results downloading from ci.guix.gnu.org <NieDzejkob>nixfreak: I'm working on getting nightly Rusts working on Guix, I've got a hacky solution <travankor>is ci.guix.gnu.org/api/queue?nr=1000 supposed to be down <NieDzejkob>2. Add (service special-files-service-type `(("/lib64" ,(file-append glibc "/lib")))) to your configuration <NieDzejkob>that should make the binaries downloaded with rustup work <cbaines>travankor, once Curiass is updated on ci.guix.gnu.org, that API endpoint should work ***apteryx_ is now known as apteryx
<cbaines>and this seems independent on where I'm testing from <cbaines>hmm, I'm getting faster speeds now... I guess that's good :) <apteryx>rekado: what was the latest changes that helped with the speeds? I missed the earlier conversation, sorry. <NieDzejkob>sneek: later tell nixfreak: I built rustup with cargo build --release, though I don't recall what version of rustc I used for that <NieDzejkob>sneek: later tell nixfreak: (I have some patches for updating rustc that I haven't yet upstreamed) <rekado>cbaines: I did “guix pull” and reconfigure; do I need to do something else to get the latest cuirass? <cbaines>rekado, I'm unsure, is the berlin configuration fixed to a specific commit, or just a branch? <cbaines>I think I remember someone saying it used the latest revision from master <rekado>apteryx: yes, hardware. Madalin and I took the disks from the old server behind berlin.guix.gnu.org and put them into one of the new 2U build servers; added a new HBA card for good measure (so that we can switch back to the old server without much difficulty), connected the external storage, registered that HBA card with the storage (via Windows!), and rewired the network cables. <rekado>I can’t say for sure that the old server’s NIC is broken (it could also be something else wrong with the chipset), but berlin.guix.gnu.org is now on a new server with new 10G NIC. <rekado>this suggests hardware problems with the old server <rekado>glad to see that some of you are getting higher download speeds now <rekado>I may have to reboot the server again next week to swap HBA cables, but I think we can leave it this way <apteryx>rekado: very nice! Thanks for sharing the story. <apteryx>I'm also able to max my meager bandwith here at times, which is something new! <cbaines>rekado, the other way to check if the change I have in mind has been applied is check in the cuirass database, if you look at the schema for the Outputs table (.schema Outputs), you should see an index for the derivation column. <cbaines>jonsger, is that in terms of speeds? <jonsger>download of an individual starts fast (6MB/s) and then stops almost at the end for some seconds <jonsger>maybe the caches are still cold/empty <Bryophyllum>Maxs out at 8MB/s for me. The average download speed is around 4-5MB/s <vagrantc>my download rates have been slow today, but the hit rate on substitutes has been good <bdju>just hit my first non-substitute since starting updates several minutes ago. guess gimp-2.10.20 wasn't built yet <cbaines>jonsger, the speeds seemed pretty consistent to me <nixfreak>so basically you have to compile rust-nightly-src first using cargo build --relase then run rustup.init.sh build --release <sneek>Welcome back nixfreak, you have 2 messages! <sneek>nixfreak, NieDzejkob says: I built rustup with cargo build --release, though I don't recall what version of rustc I used for that <sneek>nixfreak, NieDzejkob says: (I have some patches for updating rustc that I haven't yet upstreamed) <rekado>vagrantc: “today” should be very different experiences depending on whether you downloaded before or after the move to the new server. <NieDzejkob>nixfreak: that's not what I've tried, but you'll probably want ./x.py instead ***terpri__ is now known as terpri
<nixfreak>yeah cause I can't compile the rustup because it doesn't see rustc as nightly channel <civodul>rekado: so... berlin is now the new server? <NieDzejkob>nixfreak: what error message are you getting, exactly? <rekado>it still uses the old disks, not the SSDs <nixfreak>FileNotFoundError: [Errno 2] No such file or directory: '/home/nixfreak/build/rustc-nightly-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo' <rekado>I wasn’t comfortable just installing the berlin config on a new server, because of all that state that I might forget <civodul>yeah there might be state here and there that we care about <NieDzejkob>I was referring to this -> <nixfreak> yeah cause I can't compile the rustup because it doesn't see rustc as nightly channel ***terpri_ is now known as terpri
<rekado>civodul: we also took the opportunity to add a fiber channel card, so that in the future we can migrate the store or the caches to larger external storage <NieDzejkob>also, that error message is probably because of the downloaded binaries <NieDzejkob>you need the special-file-service-type snippet I posted to run those <NieDzejkob>that puts ld.so and libc in the expected FHS locations <nixfreak>NieDzejkob I do have that in my /etc/config.scm *Bryophyllum will be right back <nixfreak>(list (service enlightenment-desktop-service-type) <nixfreak> (service special-files-service-type `(("/lib64" ,(file-append glibc "/lib")))) <vagrantc>rekado: i'll take the wild guess it was after, given that you said it was down ... and then back up, and then i downloaded substitutes :) <wdkrnls>Can someone help me track down why I can't get tab completion for Guix inside of Emacs? <wdkrnls>Instead I see: "Error in evaluating guile expression: ice-9/boot-9.scm:1669:16: In procedure raise-exception" <wdkrnls>error: help-string: unbound variable <nckx>(Even I won't maintain the morning fiction at 23:00 local time.) <nckx>mbakke: Eh, briefly considered inheritance but don't see the point? I'm fine with either, but… push something to master once in a while. 😛 You'll live. <nckx>I noticed. Thanks as always, onwards to c-u. <nckx>Something something mesa. <janneke>hmm, opened a bug where i could just as well opened a patch *janneke looks at any code change as a bug :-) <mroh>civodul: thank you for adjusting and reviewing erc-status-sidebar! *mbakke reluctantly pushes to master <mbakke>I can already feel the bug reports coming in due to broken 'iputils' man pages, but they are fixed on 'core-updates' with 6268aa31849fa2bcd6594a3ef75260d5d9d21705... <mbakke>mroh: that sounded familiar...looks like I completely lost your patch in my messy queue, sorry about that! <mroh>mbakke: no worries at all, you had much more important stuff to do! thanks for the staging merge, btw! <Bryophyllum>NieDzejkob: About that bashrc service, where do I start writing the service? Can you guide me? Let's say I cloned the git repo, authenticated my checkout, and wrote the service; how do I point Guix to my local git copy so that it uses my service (assuming it's incorporated into system.scm, where bashrc is currently generated)? <mbakke>Bryophyllum: there is a './pre-inst-env' that you can use after configuring and building the git checkout <mbakke>Bryophyllum: i.e. './pre-inst-env guix system reconfigure ...'