IRC channel logs


back to list of logs

<rekado>pkill9: what package are you trying to replace?
<quiliro>rekado: thank you :-)
<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>rekado: ogre
<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
<Elephant454>Ah, ok. Got it 🙂
<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
<Elephant454>system vm"
<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: This is just an old runnig gag
<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
<brendyyn>computer stuff.
<Elephant454>Absolutely 😊
<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
<archetyp>as posible ;-)
<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.
<Elephant454>See you guys around 😊
<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>rekado: How do I go about doing that?
<Elephant454>Oh... I'm on "guix system (GNU Guix) 0.15.0-2.8bbb79c"
<Elephant454>That explains some issues I've been having.
<Elephant454>I have Guix installed on Arch Linux, and I was under the impression that "guix pull" would update itself
<rekado>it does
<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->Elephant454: it is different
<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?
<Elephant454>Yes 🙂
<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 😊
<archetyp>Bye for now
<Elephant454>See you around, archetyp 👋🙂
<Elephant454>Goodnight, everyone 🙂
<plasma41>Who has successfully installed GuixSD from the 0.16.0 i686 installation ISO?
<rekado>plasma41: welcome!
<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>pkill9: excellent!
<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>the 0.15.0 image should work.
<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>oh, that’s not good.
<rekado>in our tests we got farther.
<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> ERROR: In procedure scm-error:
<plasma41>failed to resolve partition "31393730-3031-3031-3139-313631383738"
<plasma41>rekado: Then I'm dropped into Guile
<plasma41>rekado: Any ideas?
<espectalll[m]>Making some progress with GuixSD boot
<espectalll[m]>I was having issues because having GuixSD media during boot freezed my Mac
<espectalll[m]>Like, just by having it inserted the computer would freeze
<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]>*by using
<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?
<espectalll[m]>plasma41: Windows isn't tho
*plasma41 looks forward to the day when I can run Rufus on ReactOS.
<plasma41>ReactOS w/ a full USB stack, ahoy!
*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?
<espectalll[m]>GuixSD 0.16 on a Core 2 Duo iMac with EFI 1.1
<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>Just had to use rEFInd
<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>my lexer actually
<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]>alright, so I don't think GuixSD can boot up
<espectalll[m]>waiting for partition "31393730-3031-3031-3139-313631383738"
<espectalll[m]>failed to resolve partition "31393730-3031-3031-3139-313631383738"
<espectalll[m]>and then Guile shows up
<espectalll[m]>Do I really need to keep the partition table as-is?
<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>works for me
<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>finally dropped ffmpeg-2.8
*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>rekado, lfam: thanks!
*janneke ran ntpdate and now i'm fine
<lfam>Great :)
<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?
<samplet>lfam: Yes.
<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>Sorry, that should be “as”.
<taylan>ah, makes sense, thanks
<samplet>Hmm. It appears I’m wrong. It doesn’t work with “gcc-toolchain”.
<espectalll[m]>OK, it seems like I got the partition UUID right
<espectalll[m]>Does the initrd come with FAT drivers?
<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
<samplet>(I was curious.)
<taylan>I'll install it, but thanks :-)
<espectalll[m]>Uhm so
<espectalll[m]>why does the GuixSD image contain two partitions with the same UUID?
<espectalll[m]>Actually three
<espectalll[m]>What does each partition do?
<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>Oh... duh
<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>was about to ask, thanks
<joshuaBPMan>does guix support xfs filesystems yet?
<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>s/present in both/present with both/
<espectalll[m]>plasma41: did you use Rufus for recording the image?
<plasma41>espectalll[m]: Are you burning the ISO to DVD or making a bootable USB disk?
<espectalll[m]>USB stick ofc
<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>I burned to DVD using the growisofs command listed in
<espectalll[m]>Huh, then the partition table should be intact
<espectalll[m]>although tbh it's broken already so ¯\_(ツ)_/¯
<espectalll[m]>(tfw using a Matrix bridge)
<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
<espectalll[m]>At least I think so
<espectalll[m]>The image seems to work on a VM and on a Surface just fine
<plasma41>The vm image, you mean?
<rekado>Laalf: you can see the cuirass configuration we’re using for berlin in the maintenance git repository.
<espectalll[m]>No, the ISO image
<rekado>Laalf: “autoclean” is “guix gc”
<espectalll[m]>I like to go my own way
*rekado —> zzZZ
<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
<Laalf>ah right i found it
<espectalll[m]>Maybe try to burn a different DVD
<espectalll[m]>Check which speed is it being burned on, maybe slower helps?
<espectalll[m]>plasma41: can't suggest much else
<espectalll[m]>I'm still trying to figure out how to boot it on my computer
<espectalll[m]>But with an USB
<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]>May be, who knows
<espectalll[m]>Also just installed GuixSD on a VM as a test
<espectalll[m]>Screwed up GRUB setup
<espectalll[m]>`/gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/sbin/grub-install: error: /gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/lib/grub/i386-pc/ doesn't exist. Please specify --target or --directory.
<espectalll[m]>guix system: error: failed to install bootloader /gnu/store/ggiq6y4wniqgpc8yn7s0c9hf94xm597v-bootloader-installer`
<espectalll[m]>At least I can choose to use BIOS instead since it's a VM