<rekado>pkill9: what package are you trying to replace? <demotri>quiliro: micmac, cool! I was in a lecture about it and it is also on my list, but I didn't get to it yet. Would be nice to have it within Guix. <pkill9>so i dunno why it started rebuilding boost <pkill9>ogre is a game engine, so very high level <pkill9>i probably did something wrong, lol <Elephant454>I'm a little bit confused on the concept of creating a vm using Guix. What is the difference between "guix system vm example.scm" and "guix system vm-image"? What do the "boot-loader" and "file-system" fields to in the context of these? <Elephant454>I'm trying to create a clean throw-away environment for testing Emacs, StumpWM, etc configs (on a clean install with a clean home directory), and I'm trying to figure out the best Guix faculty to go about doing that. đ <brendyyn>Elephant454: vm creates all the required packages in the store, and an .sh script ready to launch the qemu vm, where it uses all the files in your host /gnu/store. <brendyyn>Elephant454: vm-image creates an actual image that could be put on to a thumb drive with `cat' and booted in to <brendyyn>... but could also be booted with qemu, but in that case all it's packages are embedded in that image file, rather than being a in the /gnu/store file system. <Elephant454>brendyyn: That makes sense. đ I'm still a little confused, on a couple other related things, though. I'm trying to think how to best combine questions so as to ask the least necessary... <Elephant454>brendyyn: Is the vm-image mutable? Does it contain a filesystem that gets modified if it is on a medium that allows that (like if it's being booted with QEMU from the guix store)? <brendyyn>Elephant454: IRC is not so formal, you can just ask what you want. Sometimes I just talk to myself in here when I'm trying to solve something that is stressing me, and maybe someone else chooses to help me <brendyyn>Elephant454: I'm not sure, I guess you could copy the image out of the store and that would be the case. It is a qcow2 image with an ext4 file system by default, So I think you could <Elephant454>My only real consistent IRC experience is in the Arch Linux channel asking for help, and there you essentially have to have the question you have so well researched you essentially answer it yourself. đ
<Elephant454>Alright, that makes sense. That's consistent with the bits and pieces I've seen. I wasn't sure if the image was immutable, because I've seen other QEMU images need to be layered on top of in order to save changes, but I guess that isn't the case with qcow? <Elephant454>The main thing that was tripping me up was what the "file-systems" and "bootloader" entries in the "operating-system" function should be in this context. Are these actual locations of where the bootloader and some form of persistent storage should be, or are these virtual and created inside a virtual filesystem made for the vm? I was wondering if I have to find a place to store for myself, or if a virtual place is created by "guix <brendyyn>have you looked at the output of guix system vm? <Elephant454>I just managed to get it to start building, but it failed because I haven't updated in a while, I guess? I'm doing a new pull now. <Elephant454>I set my boot loader device as "/dev/sdz" for now and my file systems as just "%base-file-systems", and I got it starting now, at least. đ <brendyyn>I don't really know much about it to be honest ***rekado_ is now known as rekado
<rekado>archetyp: âWhen will GNU Hurd be finished? Next year!â â The Hurd is already in a usable state. <Elephant454>That's alright đ This has already been helpful just for the sake of trying to walk through this. <archetyp>rekado: yes, Hurd is already in a usable state, but not v1.0 <brendyyn>That's why I think there is a pragmatic aspect and humanistic aspect to IRC. I will try to do as much as I can on my own before asking questions, but sometimes i just want to talk to another person. I think in the last several years I've met only 1 person in meatspace that has heard of GNU, and 0 people that actually run GNU/Linux, so the internet is my only source of interaction when I'm hacking and learning <rekado>archetyp: I suppose weâll have to wait for Guix 1.0 before a mass migration of Guix developers to hack on the Hurd ;) <archetyp>rekado: I hope that GuixSD for the EOMA68 Libre Tea Computer Card is comming fast <rekado>Iâd like that too. I also preordered years ago. <Elephant454>So it turns out that I can't build the vm because I'm 404ing when downloading linux-libre? I'll have to look into that later. <rekado>what version of Guix are you using? <Elephant454>rekado: I believe I'm using 0.16, but I should double check just to be certain <Elephant454>Oh... I'm on "guix system (GNU Guix) 0.15.0-2.8bbb79c" <Elephant454>I have Guix installed on Arch Linux, and I was under the impression that "guix pull" would update itself <rekado>but youâll have to actually use it <rekado>it installs the new version in ~/.config/guix/current/bin <rekado>check the output of âwhich guixâ to see which guix you are actually using. <Elephant454>Which guix as root returns "/root/.guix-profile/bin/guix" <Elephant454>And normal user returns the same thing: "/home/elephant/.guix-profile/bin/guix" <Elephant454>Is this different from the version in .config/guix/current/bin? <wigust->~/.guix-profile/bin/guix doesn't come from guix pull <rekado>Elephant454: this indicates that you did âguix package -i guixâ at some point. <rekado>when doing this you will always get an older version of guix installed than the one used to install packages. <rekado>because Guix cannot possibly carry a more recent version of the Guix package itsel. <Elephant454>Alright, so I removed it, and now it's back to using /usr/bin/guix <rekado>Elephant454: do you have the directory .config/guix/current/bin? <rekado>Then please use Guix as â~/.config/guix/current/bin/guixâ or add â~/.config/guix/current/binâ first in the PATH variable. <archetyp>rekado: I also preordered on 5. November this year. ;-) <Elephant454>rekado: Awesome! Which points to the right place now, I'm getting a commit id as the version, and I can do 0.16 specific commands đ <plasma41>Who has successfully installed GuixSD from the 0.16.0 i686 installation ISO? <rekado>plasma41: itâs possible that the ISO is actually broken for i686. <pkill9>rekado: i got the package-input-rewriting to work, i was misunderstanding g_bor's example <rekado>plasma41: do you only have an i686 machine? <plasma41>rekado: If the i686 ISO is broken then that should be noted on the download page. Do you know if the 0.15.0 i686 ISO works? <rekado>it is not clear that it is actually broken. <rekado>but we suspect that thereâs a bug in xorriso that truncated files on the i686 image. <rekado>do you get an error message using the i686 image for 0.16.0? <rekado>we know that the image can be booted successfully <plasma41>rekado: When booting the disc, after grub I get several messages that the system is waiting for a partition, but it times out and drops me into a scheme interpreter. <rekado>this means that the disk partition isnât found via the expected name. <plasma41>The line "waiting for partition '31393730-3031-3031-3139-313631383738' to appear..." appears on the terminal about once every second. <plasma41>rekado: After that has happened enough times to fill the screen, the terminal displays the lines <plasma41>failed to resolve partition "31393730-3031-3031-3139-313631383738" <espectalll[m]>I was having issues because having GuixSD media during boot freezed my Mac <espectalll[m]>I'm getting it to work, however, by using Rufus' (please forgive me Stallman) ISO mode with MBR partitioning... where I can only get to the GRUB boot mode but using BIOS compatibility mode <espectalll[m]>Rufus did throw into me a warning about some missing 300kb on the image, would be interesting to check <plasma41>espectalll[m]: Rufus is GPLv3+. No forgiveness from Stallman needed. <espectalll[m]>Has anyone had to deal with a similar issue or is aware of (potential) issues with the creation of GuixSD images? *plasma41 looks forward to the day when I can run Rufus on ReactOS. *espectalll[m] looks forward to the day when ReactOS isn't needed because the world has been enlightened by GuixSD <plasma41>espectalll[m]: Which version and arch of GuixSD are you trying to install? <efraim>Unfortunately most of us with Macs cheated in some way while installing GuixSD <efraim>I installed it over debian, others took out the drive and installed it from another machine <buenouanq>I had an aluminum Macbook from 2008 that took GuixSD no problem. <buenouanq>It has since bricked itself, which believe to be completely unrelated... <nckx>For your own protection from all that scary freedom. <roptat>I have some troubles with my parser... <roptat>I defined an id to be composed of some symbols, including "-", "<" and ">". That is because "->" "-" or ":-" for instance are valid function names <roptat>but at the same time, in some other context, I need to match "<image></image>" as an xml pattern or "-1" as a literal <roptat>I think the lexer is confused because I implicitely defined "<" and ">" as symbols for the xml pattern, so a standalon "<" is matched to that symbol instead of an id <rekado>youâre doing this in Java, no? Isnât there some builtin XML parser? <roptat>maybe, but I don't want to parse xml, I want to parse scala <roptat>you can use literal xml in scala <roptat>for instance "val foo = <bar></bar>" is a valid scala expression <plasma41>rekado: I just burned the x86_64 ISO to a DVD and tried to install using it on the same hardware. I face the exact same issue as with the i686 version. The hardware is an old dual-core x86_64 box. <espectalll[m]>waiting for partition "31393730-3031-3031-3139-313631383738" <espectalll[m]>failed to resolve partition "31393730-3031-3031-3139-313631383738" <espectalll[m]>Because I feel that's the reason why my Mac freezes when a dd-recorded drive is in <lfam>efraim: I've been out of the loop â do you know if anyone has looked into upgrading Qt to 5.11.3? It's a bug-fix release <efraim>lfam: I just noticed it a few days ago, I assume it's going to be a drop-in replacement <efraim>i haven't looked at 5.12 yet, but after being burned by 5.11.0 i'm not anxious to jump on 5.12.0 <lfam>Yeah, I'd hope that 5.11.3 would be easy <lfam>Do you know if we can do this kind of upgrade "directly" or would it need a graft? <efraim>i normally upgrade qt directly, it just takes a long time to build everything <lfam>I'm going to open a bug ticket to track work on this, okay? <efraim>'guix refresh -l qt qtbase' says 471, quite a bit over our 300-ish now <efraim>only 4 of them are from qt itself *efraim wanders off for a while <lfam>Okay, I just opened the bug <lfam>I'm curious what he meant about ffmpeg-2.8... I'd be happy to remove that package <janneke>weird, my time is off but ntp is running <janneke>do we have `ntpdate' packaged to do a manual reset? <rekado>janneke: if your time is off by a lot you need to tell the ntp service that itâs okay to correct large differences. <rekado>ântpdateâ is part of the ntp package <lfam>janneke: The command-line argument to ntpd would be '--panicgate'. It's in GuixSD's ntpd service as 'allow-large-adjustment? <lfam>I think the threshold is 1000 seconds *janneke ran ntpdate and now i'm fine <janneke>samplet: I renamed gitlab/janneke/gash.git to gash-historical and renamed janneke/geesh.git to gash.git <samplet>janneke: Cool. I am taking a little Gash break to do some Guix house-keeping, but will return to it soon. <lfam>Hm, new nettle release 3.4.1 fixing some side-channels <janneke>samplet: that's great -- i took a holiday and worked on mes.M2, now returning to guix scheme-only bootstrap <janneke>that's all still pretty experimental anyway, but i expect much and fast progress now <lfam>samplet: Are you behind the GDM work? <lfam>Cool, thanks a lot for working on that! It's been on a lot of people's wishlists for a while :) <samplet>Mine too. (Insert clichĂ© about scratching itches here.) :) <lfam>Ah, I see that nettle is already on the staging branch <taylan>what might I be doing wrong here? <taylan>bash-4.4$ /gnu/store/ginr...-gcc-5.5.0/bin/gcc test3.c <taylan>gcc: error trying to exec 'as': execvp: No such file or directory <espectalll[m]>Hey, any suggestions on how to tell initrd which partition is GuixSD on? <espectalll[m]>I think I provided the wrong UUID, but at the very least the label should be valid, and according to the docs I can just pass that as an argument for --root <samplet>taylan: IIRC, GCC does not keep a reference to binutils, so it cannot find âarâ. The âgcc-toolchainâ package should work, though. <samplet>Hmm. It appears Iâm wrong. It doesnât work with âgcc-toolchainâ. <samplet>taylan: You should probably use âgcc-toolchainâ from a profile or from âguix environmentâ. However, the following works if you really need to run it from the store. <samplet>LIBRARY_PATH=/gnu/store/...-gcc-toolchain-8.2.0/lib PATH=/gnu/store/...-ld-wrapper-0/bin:/gnu/store/...-binutils-2.31.1/bin /gnu/store/...-gcc-toolchain-8.2.0/bin/gcc <espectalll[m]>why does the GuixSD image contain two partitions with the same UUID? <taylan>is there a 'guix package -d' equivalent to 'guix system'? <lfam>taylan: `guix system` takes a -d argument <lfam>According to --help, anyways <taylan>lfam: "-d, --derivation return the derivation of the given system" <lfam>Is that what you were looking for? <taylan>nope, 'guix package -d' stands for --delete-generations <lfam>I was thinking of `guix build -d` <lfam>No, unfortunately it isn't implemented yet. <lfam>You have to manually delete the generations in (IIRC) `/var/guix/profiles` and then run `guix gc` <lfam>There is a long-standing WIP patch on guix-patches or guix-devel somewhere <taylan>hmm, guix gc freed about 24G of space, hope I didn't delete one symlink too many :D <taylan>quite possible that I had several outdated whole systems there though <lfam>If they span multiple 'core-updates' cycles they can be quite large <espectalll[m]>Guys, it's the UUID duplication thing that makes my Mac unable to boot <espectalll[m]>Why is that used? Should I just report it through the mailing list? <rekado>espectalll[m]: feel free to send mail to guix-devel to discuss this. I donât know why there would be UUID duplication. <plasma41>espectalll[m]: I'm experiencing the exact same 'waiting for partition "31393730-3031-3031-3139-313631383738"' problem as you. I tried both i686 and x86_64 versions of the 0.16.0 install ISO. Problem is present in both. <plasma41>espectalll[m]: Are you burning the ISO to DVD or making a bootable USB disk? <Laalf>hello. does someone have a config for cuirass for me? i dont have a lot of space and i am scared it would fill my ssd in no time. cuirass-service-type says nothing about autoclean if i see that right <plasma41>espectalll[m]: And do you experience the "waiting for partition" issue with the Rufus-created USB stick? <espectalll[m]>Yeah, basically because it makes its own partition table and the image's GRUB has specific UUIDs configured into it <rekado>Laalf: you can see the cuirass configuration weâre using for berlin in the maintenance git repository. <rekado>Laalf: âautocleanâ is âguix gcâ <plasma41>espectalll[m]: So, do you have a work-around for the 'waiting for partition' issue? <Laalf>rekado: can you send me a link to that? i dont think i know where the maintenance repo is <espectalll[m]>Check which speed is it being burned on, maybe slower helps? <espectalll[m]>I'm still trying to figure out how to boot it on my computer <plasma41>espectalll[m]: Curiouser and curiouser: I just tried booting both my burned i686 and x86_64 install DVDs on another computer and both booted all the way to a root prompt without any issue. <plasma41>espectalll[m]: I wonder if issue somehow resides in the DVD drive hardware *plasma41 grabs a nearby stack of five spare DVD drives and begins testing. <espectalll[m]>`/gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/sbin/grub-install: error: /gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. <espectalll[m]>guix system: error: failed to install bootloader /gnu/store/ggiq6y4wniqgpc8yn7s0c9hf94xm597v-bootloader-installer`