<buenouanq>for the efi boot it has a double picture of the 100% Freedom GNU/Linux-libre logo at the top <yoosty>just saw the announcement about Guix-HPC <marusich>buenouanq, I think that might be a question for linux-libre? <marusich>I'm sorry, I thought you meant "libreboot" when you said "linux-libre". <marusich>If you are using libreboot, though, maybe libreboot is somehow related. I recall seeing a similar "double picture" on my libreboot machine. <marusich>I left it as is because all I really cared about was that it could boot. <marusich>I had always assumed it was Libreboot putting this picture in at boot time, but honestly I'm not sure. <marusich>I ordered it from Ministry of Freedom for a reasonable price; it came pre-installed, and upgrading it since then has been fairly painless. <buenouanq>part of my problem is that the image appears twice for no reason <buenouanq>I know this is a silly thing to be concerned with (;-___-) <marusich>Eh, it's aesthetics, and aesthetics are sometimes worth caring about. <marusich>If it isn't coming from Libreboot, then it's probably something GuixSD is explicitly setting up. I'd look around in the bootloader-related code for hints. <lfam>marusich, buenouanq: To start debugging, see %boot-logo-patch in 'gnu/packages/linux.scm' <lfam>That's where we download the picture <buenouanq>I'm prolly not going to actually do anything. <buenouanq>I just post my guix related thoughts as they come. <lfam>No worries, but now you where to start :) <lfam>Strange that it would appear twice, for sure <lfam>Also somewhat amazing that Linux or something in the bootloader appears to include a PPM parser <lfam>But, I guess that's how you get pictures at boot :) <marusich>So, buenouanq, if it is incorrectly showing up twice, this might be a potential bug of interest to the linux-libre devs. First, you might consider asking them if (1) the patch is actually part of linux-libre and (2) it's intended that it shows up twice. Perhaps the authors could help you understand more. :) <marusich>If you didn't kill it, then perhaps the OOM killer did. <marusich>Check /var/log/messages for words like "oom" and "oom kill"; also check to see if your memory pressure is high using tools like "free" <marusich>Sometimes, on low memory machines, running commands that cause Guix to build things don't work because there isn't enough memory. If the OOM killer decides to kill a build process, it's no good. ***atw` is now known as atw
<marusich>buenouanq, you need to configure the system to mount the swap. <marusich>If you haven't taken the steps to do that, then it's not automatic. <marusich>See the "swap" discussion in: (guix) operating-system Reference <buenouanq>well even with the swap on it's halting in the same place <buenouanq>I've also installed GuixSD on this machine in the same way before and not had this problem... <marusich>I'd start by determining what killed the process; hopefully there are messages in /var/log/messages that will make that fact clear. <marusich>From there, you can investigate as to why the process was killed. <marusich>If it was the OOM killer, then the immediate cause would ostensibly be that your system ran out of memory...which can happen for a lot of reasons, I'm afraid. For example, if you have a million tabs open in Icecat, it's possible that memory pressure would be great enough to cause the OOM killer to kill a totally unrelated process, such as a build process for guix pull, or the guix process itself. <marusich>You can see if you're swapping heavily with vmstat and free. If you are, you might consider adding more main memory. It's entirely possible that when you installed GuixSD earlier and did not notice any issues, you simply happened to not be doing anything that was memory intensive. <marusich>I suppose adding more swap space might also help, but I'm not too familiar with how the OOM killer works in detail, so I don't know if that would actually help in that case. <buenouanq>this is on a macbook, so I assuming adding more memory isn't an option <buenouanq>and I currently have nothing else (except gnome/xorg) running <marusich>Well, adding more swap should be fairly straightforward, so you might try that. You can also look into tuning the "swappiness" of the Linux-libre kernel; I don't know if that's related to OOM killer behavior though. <buenouanq>it still hasn't moved beyond compiling... 75.3%, but it is using the swap now <marusich>So, I'd suggest verifying first whether or not the OOM killer was actually killing the process. Then, if it was, maybe look into ways to alleviate that problem. <marusich>While it's running, you can also have some fun watching top to see what's using memory. <buenouanq>marusich: /var/log/messages | tail has 3 things of interest: <buenouanq>Out of memory: Kill process 1593 (guile) score 661 or sacrifice child <buenouanq>Killed process 1593 (guile) total-nm:1425360kb [...] <buenouanq>oom_reaper: reaped process 1593 (guile), [...] <lfam>buenouanq: It ran out of memory with 6 gigabytes of swap? <buenouanq>no, I discovered that my swaps have not been turning on automatically like I assumed they did. <buenouanq>it's on now, but still hasn't progressed beyond the same place <lfam>That's about 2 GB, anyways <lfam>Yeah, it's an unfortunate bug but, currently, `guix pull` needs ~3 GB <lfam>Those larger modules are what use all the RAM <buenouanq>but now that the swap is on it should be able to work though right? <lfam>Yes, although it will be slower than using RAM <lfam>I realized my comment about "larger modules" is confusing (I began a message about them earlier but stopped). The (gnu packages python) module is ~16000 lines of code, with lots of stuff going on inside. Compiling that module is where most people notice this issue <buenouanq>lfam: how is that going to work out for SoCs and small things in the future? <ryanwatkins>Anybody know how one might npm install -g using guix? <lfam>buenouanq: The issue needs to be fixed in Guile, since the memory use is really too high for many systems, including lots of ARM devices that we aim to support <marusich>ryanwatkins, if you mean "How do I use NPM, installed with Guix, to install stuff?" I think the answer *should* be: first install npm ("guix package -i npm" or whatever the package name is), followed by "the usual" npm stuff. <marusich>I don't use npm, but in theory if you want to use a package manager like npm, you ought to be able to do so, even if you have installed it using Guix. It's entirely possible that it might not work, though, for example if npm tries to modify things that are in the store... <buenouanq>using other package managers alongside/underneath guix should be discouraged <ryanwatkins>marusich: nono that is correct but when you do a global install of an npm package it tries to write to some given /gnu/store/.../node_modules and fails <buenouanq>instead, guix packages of whatever you're wanting to add should be made <marusich>ryanwatkins, if npm is trying to modify stuff in the store, then it won't work unless somebody changes either npm or the way it's packaged (or both) to make it possible for it to do its job without modifying files in the store. <lfam>I didn't follow too closely when this was previously discussed, but I think the issue with packaging things from NPM is that the NPM dependency graph is full of cycles and software without source code <marusich>But, like buenouanq, it would probably be better to invest effort in an npm-build-system, and in packaging npm packages with Guix using that build system. <marusich>lfam, and yeah if it seems intractable, then perhaps it would be worth looking into whether or not npm can be made to work on guix, even if we don't have a build system for it (yet) <lfam>IIRC, those issues sort of rule out including those things in Guix for now. Even if one packaged them privately (punting on the issue of source code being unavailable), the cycles are a problem <lfam>Yeah, it's definitely a packaging bug that NPM tries to write to the store <ryanwatkins>lfam: I would be fine if it wrote to some given local folder I provide <lfam>I'm not familiar with node or NPM, so I'm not sure :/ <lfam>Those search-path things usually have more to do with how Guix builds the package rather than the behaviour of the software provided by the package <buenouanq>even with the swap on it gets to 75.3% and everything freezes... <lfam>buenouanq: As I mentioned before, it will be very slow while using swap <lfam>Your disk is several orders of magnitude slower than RAM, and `guix pull` also has to contend with everything else your system might need to use the disk for <buenouanq>I ran guix pull before installing and it did not halt like this. <buenouanq>somehow something to do with being root maybe? <lfam>Each user has their own `guix pull`, so perhaps the user who didn't have this issue was using an older version of Guix from before we switched to Guile 2.2 (the version that introduced this issue) <buenouanq>does the 13.0 install image not use Guile 2.2?... <marusich>It's a shot in the dark, but you could also try doing "guix pull" from a specific Git commit (from around the time that you think the "guix pull" command previously worked OK). How to do this is described in the manual: (guix) Invoking guix pull <lfam>0.13.0 is when we introduced Guile 2.2, but perhaps the installer was still using Guile 2.0. I don't know for sure <buenouanq>I'm just going to stop trying on this machine until it's been fixed I guess. <marusich>buenouanq, the long iteration team really makes it painful to troubleshoot...I know :( <buenouanq>Cause it's not simply `slow' it screeches to a hault. <lfam>It would finish eventually. I use swap on a system with only 1 GB RAM, and it takes several hours <lfam>Well, I did that once. Now I work from Git on that system instead <buenouanq>I just need a working ssh and browser on this machine anyway. <lfam>With Git, you still have to pay the memory price, but maybe not every time <lfam>I don't know how the progress indicator works, but I suspect it's per-file. So if the process spends a lot of time on the same file, it would show the same number for a long time. <lfam>Right, so the number will stop, but things are still happening as Guix compiles that one large file <lfam>Or, as Guile compiles it <lfam>After it completes that file, the number would change <lfam>Anyways, I understand not wanting to deal with it. I did it once on that 1 GB machine and haven't since <ryanwatkins>Given that guix still has yet a way to figure out the npm sitch, for now would doing a guix package -i nix and using nix be a way temporarily? <lfam>Perhaps! I've never tried it, but I know that Nix came up with a workaround for these issues <lfam>A workaround, although not exactly a solution ;) <marusich>Nice. Install a package manager to install a package manager so you can install packages... lol <marusich>Hilarious, but if it works, I suppose that's good. :-) <lfam>Isn't this a wonderful world that we've built? :) <buenouanq>just make sure you then install guix with npm to complete the circle <buenouanq>this is the only thing that will make what you're trying to do acceptable <buenouanq>happy_gnu[m]: there's currently a bug in guile that requires at least 3GB of memory to build everything <buenouanq>mine discovered it had run out and killed itself well before 3 hours though <buenouanq>and then depending on how slow your machine is... <buenouanq>I suggest first installing a very minimal OS config (no desktop environment or anything) - Then you can build it up with a system reconfigure after you're up and running. <buenouanq>Question: Installing fonts gives me `Cannot find your hotkey definition file.' [nonfatal]errors <buenouanq>should take less than an hour for a whole DE and everything for sure <buenouanq>needs someone to adopt it and give it some love <buenouanq>lol that's another thing we talked deeply about today <buenouanq>keymap where? console is different from slim is different from whichever DE <buenouanq>to quickly just do it temporarily you can run $ loadkeys dvorak <happy_gnu[m]>I don't want to be typing loadkes dovark-es every time I boot <buenouanq>adding all of that will change the console and login manager <buenouanq>Gnome has to be done from within Gnome"s own settings for some reason. <buenouanq>and that mess at the bottom is how you add a config to xorg <buenouanq>the (list 10-evdev.conf) can be more than one thing <buenouanq>you could define a bunch of separete files and add them all <buenouanq>how that's done should really be cleaned up somehow though <buenouanq>the list would just be (list file-a file-b etc) <jherrlin>the first one is NTP, i got some good help yesterday but started to dig more into the issue and found what i think another way that fits me better <jherrlin>=guix system: error: service 'ntpd' requires 'networking', which is not provided by any service= <jherrlin>does anyone know how to resolve this problem? <buenouanq>I'm not sure what the most minimal setup would be for this - I've always just had %desktop-services which provide networking <buenouanq>oh wait jherrlin, if you're doing slim what you're missing is the %desktop-services <buenouanq>make that section like what I've posted above <buenouanq>and comment out %base-services because you can't have both for some reason <roptat>buenouanq: you can't have both because %desktop-services includes %base-services, so you would have duplicate services <roptat>and I would be interested in how you can fix the keyboard layout issue :) <roptat>I already use (console-keymap-service "fr-bepo") for the console, but it doesn't affect the X session <roptat>jherrlin: 'networking' is provided by many different services. You can use static-networking-service or dhcp-client-service for instance <buenouanq>roptat: If possible, it would make the most sense for duplicate service declarations to either be ignored or rewrite previous ones. <buenouanq>within X, keymaps have to be changed via however your DE requires <buenouanq>in Gnome this is under the Region & Language settings <roptat>within X I can use setxkbmap, but not in slim <buenouanq>this really should be added to the manual somewhere <civodul>i think we should have a global keyboard layout thing that changes both X11 and the console <buenouanq>and it should be a single line, not that whole mess <buenouanq>there's slim too is the issue, you have to change it 3 times, each one differently <buenouanq>(console-keymap-service "dvorak") is the way to model this if possible <buenouanq>could just be like (global-keymap-service "dvorak") and take care of everything <civodul>we probably need to revamp the Xorg service for a start <civodul>OTOH, maybe GDM offers a simpler way to achieve this, dunno <buenouanq>deprecate xorg and usher in the new beautiful era of wayland :3 <efraim>that reminds me, I need to figure out how to build enlightenment with wayland support without rebuilding mesa or xorg-server <jherrlin>hey, sorry for being afk, had to take care of some stuff <jherrlin>i will try to use =static-networkin-service= <efraim>jherrlin: don't feel bad, I idle here 24/7 when I'm not actively here <buenouanq>how very generous of you to consider this support <jherrlin>=(gnu services static-networking-service)= was not working <jherrlin>ice-9/boot-9.scm:2795:6: In procedure resolve-interface: <jherrlin>ice-9/boot-9.scm:2795:6: no code for module (gnu services static-networking-service) <pmikkelsen>Is anyone working on updating our haskell packages or should i maybe give it a go? <roptat>static-networking-service is a procedure <roptat>it's in (gnu services networking) <jherrlin>okey, i know what a procedure is, but how to use it here is hard for me <jherrlin>roptat when i added to =(dhcp-client-service)= procedure to =services= is reconfigured without error. <jherrlin>will try to reboot the system and see if if works <roptat>you can replace dhcp-client-service with static-networking-service <civodul>pmikkelsen: re Haskell, i think you can give it a go, these packages are getting outdated! <civodul>pmikkelsen: BTW, congrats on meson-build-system! <jherrlin>hmmm, after rebooting the system either NTP or keyboard layouts would work <civodul>pmikkelsen: i'll try to comment on the patches later today <civodul>jherrlin: my suggestion would be to try out your new config with 'guix system vm' rather than reconfigure + reboot <pmikkelsen>civodul: Okay, haskell it is then, and don't expect the meson-build-system to be the best code ever, as I am not very experienced yet :) <efraim>pmikkelsen: I haven't ever touched our haskell packages, I hear there is a "stable branch" or something, I think it was strongly suggested on the mailing list at some point to target that <pmikkelsen>There is something called stackage which is a project keeping a list of packages that works together, and they have a LTS version. I am planning to target that, as it will also same me alot of time debugging build errors :) <brendyn>With the default gnome desktop configuration, is there a default xsession file somewhere that is used if you don't have one in your home dir? <efraim>sneek: later tell ng0 do you remember which package needed cpputest for the test suite? <efraim>ah i have a typo in the commit message for weechat <efraim>thats the one I got mad at, (system* "sh" "autogen.sh") failed me there <efraim>I dont remember exactly what happened, but it was easier to switch it to cmake than to work out the order of phases for patching files <efraim>maybe i needed to patch version.sh or something also <Steap>ACTION loves working with RPM <Steap>it seems overly complex (though not as much as *.deb) <Steap>people at work were talking about "devops" and how "everything should be code" <Steap>the day they see Nix/Guix, they'll probably ditch RPM <thomasd>by the way, it seems the package list on the Guix webiste hasn't been updated since August 26. Is that supposed to happen automatically? <civodul>(aka. i broke the damn thing on hydra.gnu.org) <civodul>there's even a nested problem, which is that Guile 2.2 eats our hardware <Steap>thomasd: I doubt Red Hat will really move away from RPM :D <thomasd>civodul: in what sense is Guile “eating hardware”? <civodul>you know there's this memory consumption issue with the compiler <civodul>apparently that's causing evaluations on poor hydra.gnu.org to be slower <thomasd>is that because building derivations also requires the Scheme code in them to be compiled? <civodul>no, just the code that computes derivations (not the code that builds them) <civodul>but it's really a bug somewhere in Guile's compiler and/or VM <thomasd>aka Guix itself? that only needs to be built once for each new evaluation, no? <civodul>this is using way more memory and CPU than it should <civodul>i've been profiling and reading code to get a better understanding of all this <thomasd>Still, if my poor old laptop can pull it off, I didn't expect it to be a problem for the almighty Hydra <civodul>turns out your laptop is likely more powerful than hydra.gnu.org :-) <thomasd>I'll ask the people at work to donate it when it gets replaced ;-) <civodul>berlin.guixsd.org can cope with it quite happily <roptat>guix pull asks for a bit more than 1.5 GB of RAM to complete <thomasd>yes, I also think the current state is not ideal, even on this very powerful laptop of mine <thomasd>but I'm optimistic for the future :D <civodul>i'm optimistic too, but the current state is terrible <jonsger>Steap: do you know if RPM has something similiar to "guix environment" <roptat>that's 1 GB more than what I have on my VM, so I compile it elsewhere and scp it to the VM <Steap>jonsger: there are "isolated environments" just like Debian has <Steap>and the fact that it's something added "on top" of the existing system makes it so hard to use <Steap>Guix is "simple" in that regard <Steap>not sure whether you can actually use this as "guix environment" when I think about it <jonsger>yeah we use here vagrant and all that stuff. but if you used "guix environment" once you won't miss it <civodul>jonsger: you mean "guix environment" worked poorly for you? <jonsger>civodul: no, it's quite nice. But if some software haven't a guix package you can't use it <civodul>i thought "you won't miss it" meant "guix environment is so bad that you won't miss it" <jonsger>oh yes. my english was broken there :P <jonsger>:) we have software you don't want to package for guix... <Steap>ACTION has been working on an updated version of tox-guix <thomasd>(jonsger: you can still use "guix environment --ad-hoc" and list all dependencies yourself. Though at that point, you can just write a package yourself) <jonsger>thomasd: just in the git repo of the software or how? <civodul>jonsger: and there's GUIX_PACKAGE_PATH for private packages <jonsger>civodul: yeah, I didn't get it into a stage where it builds successful... <Steap>civodul: does not work as well as it should :D <thomasd>jonsger: i just mean at the command line, when you want to set up an environment for your work, type “guix environment --ad-hoc dependency1 dependency2 ...”. Of course that requires that packages exist for your dependencies. <jonsger>thomasd: when I'm in the packaging process I don't need "guix environment" or? "./pre-inst-env" is enough. You have to figure out step by step the dependencies <thomasd>jonsger: I thought you wanted to use guix environment for software that isn't packaged in Guix. But I think I misunderstood you. <jonsger>how do I get bundler to build native extensions? <jonsger>which guix package contains "linux/limits.h"? <davexunit>I've never used linux-libre-headers directly when making ruby environments <davexunit>you just need the basic compilation tools that gcc-toolchain provides, pkg-config, and the shared libraries that the ruby native extensions need to link against <efraim>Looking at the grub manual, rEFInd and the debian packages the easiest option still is OSX -> rEFInd -> GuixSD. <efraim>Or maybe refind gets its own partition marked bootable and grub-efi just goes in /boot <civodul>i probably won't be able to make it this year <civodul>it's a really friendly and productive event <m-o>civodul: really interesting link thanks, hope i'll find time to unbury (guix user). <ng0>could someone point me to further reading material on the nar and .nar files and fileformat in general? <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, efraim says: do you remember which package needed cpputest for the test suite? <efraim>ng0: civodul pointed out it was weechat <ng0>sneek: later tell efraim: weechat. but I did not succeed, failed <ng0>efraim: why do we need a Mate service? <efraim>ng0: don't we have a GNOME and xfce service of some sort? <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, ng0 says: weechat. but I did not succeed, failed <ng0>well I have "mate" in the packages list <ng0>what I need to gather from narinfo for now is just a short human readable description. like "normalized archive something." next line: "the long descriptive line for narinfo, example: 'duration of a videostram'" <ng0>ie: what would you like to read in libextractor for it <ng0>if there's no long text, it can just be "narinfo" "narinfo" or "narinfo" "normalized archive info(?)" <ng0>efraim: a service probably makes sense if we don't want to add every Mate related package to "mate" meta? <ng0>and if there's some dbus'ing etc we would need to do <efraim>I'll take a look at the other DE services, I don't think I've ever examined them closely <ng0>.narinfo contains hashes and some more info. is this the only meta-type we need or is "nar" an additional type? <ng0>let me rewrite the question <ng0>I want to add "narinfo" to libextractor to resolve an TODO in gnunet-guile. I don't know very much about nar at the moment, but I assume we have to add it in addition to narinfo, or am I wrong? <ng0>I think: two files which are connected but with different content, so -> add "nar" as "normalized archive" and add "narinfo" as "normalized archive infofile" <efraim>I assumed 'nar' is the archive and 'narinfo' was information about the nar inside the archive <efraim>That it is 'n....something archive' <ng0>so narinfo as: "narinfo", "file containing information contained in a normalized archive (nar)" if that isn't too long? <ng0>There are even longer lines, so it's okay <ng0>s/contained/related to <ng0>or better:file containing information about contents of a normalized archive (nar) <ng0>civodul: sounds good, the bad part is that it's tuesday to thursday and no public or other kind of holidays/breaks in my federal state. <efraim>ng0: looks good to me, although I'm still not fully sure about nars and narinfo <ng0>okay. me neither, but it's a start. descriptions can be adjusted <ng0>efraim: xfce + gnome service are polkit related for specific applications in it <ng0>so it *could* be that we need it <happy_gnu[m]>I was reading that is better to compile than to use hydra.gnu.org for privacy <happy_gnu[m]>but is there a benefit on performance when I compile? as far as I know there is better performance when compiling than use binaries but I don't really know about that <marusich>I'm doing well. As for your question, if a package builds reproducibly, there will be no difference in performance (of the built software) because it is identical, byte for byte, to what was built on Hydra. <marusich>It will take much longer to build the software locally than to download a substitute from a substitute server such as Hydra. <marusich>As for trust, basically, if you believe that the Hydra server and its operators are safe to use, then you can be confident that any substitute from Hydra which passes authentication and is used by Guix is "the same" as what you would have gotten if you had built the software locally. <marusich>By "the same," I mean extensionally equivalent: even if the software is not identical byte for byte with what you might have built locally (which can happen if the build is not deterministic), it is identical in the sense that its behavior should be the same (because it was built from the same source that you would have used). <marusich>The short answer is: No, software compiled locally will not perform better (or worse) than software compiled on Hydra; they should behave the same. <marusich>I suppose building locally is better for privacy in the sense that you do not have to trust Hydra, but since you are already trusting the Guix devs not to provide you with a tainted version of Guix, I don't think you gain a lot of additional privacy/security by choosing not to trust Hydra. <happy_gnu[m]>anyway the installation was compiling since yesterday :/ <happy_gnu[m]>someone told me that there is a problem with the new version with guile 2.2 and suggested to give more ram to the VM <happy_gnu[m]>and as the link I shared suggested that is better to compile I am compiling everything <happy_gnu[m]>which I had talked to you before marusich I would have used binaries :/ <marusich>In practice, I have found that it can take around 8-12 hours, in the worst case, to compile some things without substitutes on my laptop (CPU is 2 cores: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz) with 8 GB of RAM. Substitutes make a huge difference; they bring the total time for me down to minutes. <marusich>happy_gnu[m], you can always try out "guix challenge" to have fun checking whether or not your local builds match what Hydra is offering. If you find something that is not reproducible, it's probably a bug in the packaged software that should be reported. <happy_gnu[m]>when somone asks Sussman about some function and he answers something like "it doesn't matter how it works, all you need to know is that it does what I just said" <joshuaBPMan>Hello, I'm unable to successfully run sudo guix pull; guix is complaining that I do not have guile-git. I can successfully run sudo guix; But running sudo guix pull and I get an error that says that guix new needs guile-git...? I have a git repo of guix as well. <joshuaBPMan>but that only updates my user profile. How do I update my root profile? <joshuaBPMan>is root profile the same thing as the system profile? <happy_gnu[m]>hi dustyweb I will try to package for guix now as you told me to :) <buenouanq>joshuaBPMan: I'm actually unsure which using sudo with guix would try to do... <joshuaBPMan>ohhh. So maybe I need to run reconfigure to update the system profile? <Apteryx>Is anyone else wondering what are those new "Click to reveal hidden elements" and "remove buttons" buttons in latest Icecat? <bavier`>Apteryx: the latest icecat comes with some more privacy addons installed by default <bavier`>Apteryx: one of the new addons displays those buttons when it detects hidden html elements <Apteryx>bavier`: Thanks for explaining where it comes from! <bavier`>Apteryx: np, I also haven't quite figured out exactly what it does <Apteryx>Eh, looks like they are going down the path of adding a free JS extension to patch any popular sites which doesn't work with the LibreJS plugin. <bavier`>I just booted the 0.13.0 VM image in qemu; I invoke qemu with '-net user' et al, but it seems like the image doesn't have dhcp installed. <Apteryx>I now have a Rock and Roll McDonald's addon... hmm. <Apteryx>I'll try to poke my bank about LibreJS and see how it goes ;) <Apteryx>It's a cooperative, so I'm hoping the response can be positive. <joshuaBPMan>Hello, I'm unable to run sudo guix system reconfigure /etc/config.scm <joshuaBPMan>The error I'm getting now is profile contains conflicting entries for bash out <cbaines>joshuaBPMan, that is a bit confusing. I would have thought that errors relating to profiles would just be for guix package commands, and not guix system reconfigure <joshuaBPMan>I'm doing a guix pull right now. Then I'll try reconfiguring. <cbaines>joshuaBPMan, could you share you're system configuration also? <cbaines>it could be something to do with how the system profile is configured in there, or it could possibly be a bug in guix somewhere... <cbaines>ok, so you have lots of things in (packages ... including bash <cbaines>nothing is wrong with that, but, if any of the other packages propagate bash, this could be causing the error <joshuaBPMan>yeah...I do have lots of packages in my config. I just hate having to reinstall everything after a reconfigure. I suppose I could use a manifest file. <cbaines>if you are on a slightly older version of guix, you might be missing the more informative error messages <cbaines>hopefully this is the case, as from looking at the code, it guix should say what is causing the error <cbaines>joshuaBPMan, user profiles will still be there after reconfigure <cbaines>obviously, if you reinstall, then they'll be empty <joshuaBPMan>cbaines: what? Everytime after I run reconfigure, my user profile "joshua" is empty. I have always had to reinstall everything... 