IRC channel logs


back to list of logs

<kyamashita>Oh boy! A duplicate use-module form in web.scm!
<Apteryx>python-urwid keeps biting me. Ugh.
<Apteryx>I'm currently investigating and will probably open a bug an issue on their github tracker.
<kyamashita>brendyn: Someone is suggesting static linking *everything*. That can't be good.
<kyamashita>But what if I don't want to upgrade my System Docker instance for whatever reason?
<kyamashita>It seems like there's a larger issue to be solved here. This distro seems like a "subpatch".
<serieux>Is it possible to install GuixSD on a separate partition via chroot?
<marusich>I'm not sure what you mean. Can you clarify what your goal is?
<marusich>Do you intend to dual boot GuixSD?
<serieux>marusich yes
<serieux>I'm currently running Arch Linux. I'm wondering if it is possible to install GuixSD on another partition, similar to debootstrap
<marusich>I've heard of people dual-booting. I don't do it myself, though. I believe it's possible; check out the section "(guix) GRUB Configuration" in the manual. It describes how to add custom boot menu entries.
<serieux>marusich: do you know how debootstrap works?
<marusich>I don't. I don't know if you can dual boot in the same way as that; but dual booting is in theory possible.
<serieux>I'll wait for someone to respond who knows what I mean.
<serieux>But thank you. That was one question I had, whether it was possible to dual boot.
<serieux>it seems like it should be possible. it's basically the same way it is installed from the GuixSD image. I would probably need to install guix on my current Arch Linux system in order to do so
<marusich>I read the man page; I am not sure if it's possible to run a GuixSD system in a chroot, but I know it is possible to run a GuixSD system in a VM. Maybe you already knew that; the details are in "(guix) Invoking guix system".
<marusich>It is also possible to run a GuixSD system in a container. See the same section of the manual. Perhaps that is similar enough to running in a chroot?
<marusich>For any of those mechanisms, you would first need to install Guix onto your Arch Linux system.
<marusich>That's all the info I have; hopefully it's helpful. Maybe somebody else can comment further.
<serieux>marusich, what I want to do is this: format another partition on my hard drive for GuixSD. Then I would mount that partition at /mnt. Then I would run 'guix system init /mnt/etc/config.scm /mnt' from my Arch Linux system.
<serieux>The thing is I think I need herd to run 'herd start cow-store /mnt' to initialize the partition for GuixSD
<marusich>I think that's an installation-image-specific thing.
<serieux>and herd is specific to GuixSD. But anyway, I don't necessarily need this; I was just wondering if it is possible.
<marusich>I think you can just run "guix system init", point it at a directory, and you'll get the files initialized there. So if you're not running the GuixSD installation image, you don't need to use the cow-store thing. I think.
<serieux>I have no issue with using the install image
<serieux>but doesn't 'herd start cow-store /mnt' set up things like /gnu/store and the default configuration template?
<marusich>I don't think so; I'm not 100% sure about it, but my understanding is that the cow-store service just makes it so writes to the store will be persisted to disk.
<marusich>So, I believe you could probably run 'guix system init' (taking care to pass --no-grub) from your Arch system to populate the /mnt directory (on which you have mounted a file system you made earlier on the partition you want to use), and it will deposit all the GuixSD system files there.
<marusich>To boot into the system, you would probably need to modify whatever bootloader configuration file your Arch system normally uses; I don't know how Arch sets that stuff up.
<marusich>Even if you can boot into the GuixSD system you've installed on that partition, I don't know how safe it would be to run 'guix system' commands like 'guix system reconfigure' from within the booted system. I think that, if you are not careful, it would be possible to accidentally overwrite your Arch system's bootloader (installed, presumably, on /dev/sda or the like) with a new one managed by GuixSD. That would probably not be a great
<marusich>experience for you :/
<marusich>So, if your goal is really just to run a persistent GuixSD system without replacing your Arch system, then perhaps using VM might be safer and easier.
<serieux>marusich, yes, I think I'll just use a VM
<marusich>It seems simpler. I think you could probably figure out a clever way to do it without using a VM, but I would not feel comfortable doing that on my own system; I'd be worried about accidentally overwriting things.
<marusich>If there is a supported way to do what you're asking without a VM, I don't know what it is; maybe somebody else will chime in later...
<serieux>marusich: thanks!
<dpg>GuixSD finally finished compiling the system init, I've rebooted and trying to bootstrap via Libreboot, however it doesn't seem to have a kernel...? I used the --no-grub option which might be the trigger.
<Apteryx>Could someone run "guix build --check python2-urwid" ? I'd like to know if the tests failures are reproducible.
<Apteryx>On my GuixSD system with Python 2.7.13 I'm getting:
<dpg_>The kernel was in (symlinked) /var/guix/profiles/system/kernel/bzImage
<sneek>Welcome back dpg_, you have 1 message.
<sneek>dpg_, ng0 says: I'd like to tell you more, but with our possibly differing timezones/availability your best shot is either our (SecuShare) chat on (see for an how to connect) or #gnunet here
***dpg is now known as DoublePlusGood23
<DoublePlusGood23>What would an encrypted drive appear as in the initrd? as in the --root option.
<efraim>i have a macbook that I want to try installing guixsd on by going debian -> guixsd, but the debian install keeps on failing to properly boot after installation :/
<janneke>efraim: is -> guixsd directly not an option?
<efraim>its a macbookpro 3,1 from 2007(?) with efi and I know i've installed debian on it before, so it should work
<efraim>and we don't have an efi installer yet
<efraim>otherwise i'd go that route
<janneke>efraim: ugh, efi
<rekado>bleh, there *are* problems with my glibc patch :(
<Petter>A Makefile.PL script dies with this check, > my $stat = system "pkg-config --atleast-version=$dbusver dbus-1";
<Petter>I'm not sure about the "dbus-1" part. Is this something a Guix system has?
<slyfox>yes, it's a dbus package
<slyfox> /gnu/store/qa3wk49wn02xncdn9905d6vl14snvdzn-dbus-1.10.16/lib/pkgconfig/dbus-1.pc
<slyfox>i guess you'll heed to add it to build depend
<Petter>Thanks! I got passed this.
<Petter>(perl.scm is weird. If I add another module it immediately stops the build with "unknown package". Remove the module and it builds again.)
<janneke>my emacs's find-file shows completions (nice) but won't let me open a dired, any ideas what this might be?
<drtan>Hi! I have trouble getting substitutes from the server during installation. Different packages on different occasions. I wonder if it is something wrong about my networking or the mirror.
<brendyn>drtan: I think the mirror is overloaded much of the time.
<drtan>Guix SD so popular. :)
<drtan>I've tried --fallback, but it couldn't compile some packages.
<rekado>argh, my repository has been corrupted again
<rekado>maybe something’s wrong with my disk :(
<jonsger>rekado: how it's going on with your KFSN4?
<rekado>jonsger: looks like the board is broken.
<rekado>jonsger: it won’t accept any memory at all. I tried all RAM sticks I had at work, but to no avail.
<jonsger>oh bad :(
<janneke>ah, it's ido-find-file hmm C-d opens dired
<janneke>ACTION is running exwm now
<snape>janneke: there is exwm--id-buffer-alist that lists all managed buffers, but '--' says it's a private variable right?
<snape>I'm not sure we are supposed to use it
<janneke>snape: hmm
<snape>but at least it does the job
<snape>you could look into it, and if there is a buffer whose name is "Firefox", you switch to it instead of spawning a new one
<snape>for example
<grillon_>hi I have tried to install guixsd for the first time yesturday and I have problems with perl24 and kvm too. for 90-kvm.rules I got not found 404. for perl I have corrupted source. What can I do?
<grillon_>because of that I cannot do guix system init /mnt/etc/config.scm /mnt
<snape>janneke: or alternatively, you could search for all emacs buffers whose major mode is 'exwm-mode'.
<janneke>snape: ah...and now i see line-mode...things start to make sense
<snape>I don't use char-mode
<janneke>I just didn't get what it referred to until now
<janneke>ACTION converted headache-some mythbuntu box to GuixSD+kodi+exwm
<janneke>now i can program lirc commands in elisp, what a godsend
<grillon_>am I the only one who cannot do a straight forward install? I follow the doc, ask no option but somes sources are not found...
<janneke>grillon_: we have problem this weekend with hydra/substitutes
<janneke>i'm not sure what it is, but its terribly troublesome
<grillon_>janneke: ok so I may postpone install?
<janneke>grillon_: i did not manage to install from guixsd-0.12.0, i used a freshly built usb image created from git master in the end
<janneke>grillon_: that's probably for the's supposed to be a breeze
<grillon_>janneke: do you think it could work today?
<janneke>ifconfig e* up; dhclient e*; mount ... /mnt; guix system init foo.scm /mnt
<janneke>grillon_: no idea, possibly rekado knows more
<janneke>he has been looking into it a bit, i think
<janneke>terribly sorry :-(
<grillon_>janneke: no pb thank you. I have seen your command and I confirm network works and I did my patitions correctly.
<grillon_>janneke: my problem is just I cannot do init until the and because of missing source and I cannot do guix pull for the same reasons
<janneke>grillon_: did you try guix system init with `--fallback'
<grillon_>janneke: no. guix system init --fallback foo.scm /mnt?
<janneke>you cannot do init until what?
<janneke>yes init --fallback; that could help
<grillon_>janneke: ok let's try
<janneke>it will fallback to building locally if substitutes fail
<grillon_>janneke: ok I see. It's trying to download and fallback on fail for each file
<grillon_>janneke: seems to work but it's in progress, not finished yet
<grillon_>almost 2 hours and it's not finished. how long does it take to install?
<grillon_>(install guixsd with gnome desktop)
<efraim>Depends what has to be built from source
<janneke>...usually nothing should have to be built from source during install
<grillon_>janneke: maybe because I add --fallback
<grillon_>janneke: ?
<janneke>grillon_: exactly
<janneke>instead of: `binary substitute not found ... bail out', it compiles from source
<grillon_>janneke: I guess many substitute are missing :) thank you
<efraim>mbakke: I'll have to wait until I get back to my computer, but it fails like arm, with many test failures. I'm pretty sure the grub-efi tests are actually run
<mbakke>grub-efi tests require a UEFI firmware for qemu such as "OVMF" which only builds on x86_64
<mbakke>i've been meaning to enable them on supported architectures
<grillon_>I use lvm, and it's written lvm is not supported on boot in the doc. is it still true?
<mbakke>grillon_: unfortunately, yes
<mbakke>you can use it "manually" on a booted system though
<grillon_>mbakke: ohh so I'm wainting for nothing
<mbakke>godot should be around any minute now
<grillon_>mbakke: I know because I'm installing it on lvm+luks
<grillon_>what is the difficulty to support lvm?
<efraim>mbakke: I checked arm's grub-efi, test suite wasn't run
<mbakke>grillon_: we'd need support for an "lvm-device-mapping" similar to "luks-device-mapping" in gnu/system/mapped-devices.scm for starters
<mbakke>efraim: :(
<grillon_>mbakke: I'm on the usb key. I have follow install example and put type luks-device-mapping but I cannot find the scm file.
<grillon_>mbakke: I'm cloning source on that computer to search, the guixsd one is unusable(still compile sources).
<grillon_>mbakke: it's in /gnu/system/devices-mapping.scm.
<grillon_>mbakke: seems not very difficult but I never write in scheme. I need to train before.
<grillon_>3 hours of compilation and almost sure it could not work...I should give it up
<grillon_>still installing, endless install
<mbakke>grillon_: what are you compiling? are you on i686 by any chance?
<grillon_>mbakke: I'm on x64, now it seems in install phase
<grillon_>mbakke: ok it's alternating too fast don't know what is compiling now
<grillon_>mbakke: libweather
<jlicht>hi guix!
<jlicht>just reading up on the guix potluck thread, it seems very exciting
<grillon_>mbakke: you would like to share your sources?
<Petter>Is there a script or something to generate recipes for perl programs?
<jlicht>Petter: Are you talking about a cpan module?
<Petter>The program I want isn't a cpan module, but it's got about a thousand cpan module dependencies (maybe less).
<mbakke>grillon_: did you forget to authorize the hydra key perhaps? there should be binary substitutes available for most packages from the install image
<Petter>I'm adding modules, modules to modules, modules to modules to modules...
<jlicht>bah, that seems horrendous. AFAIK, there is no such template though.
<Petter>And it's very simple operations, so it could be automated at least a good bit.
<mbakke>Petter: "guix import cpan <module-name>" can create most of the package body automatically
<Petter>Hmmmmmmm... *takes a look*
<jlicht>Did the recursive importer for cpan end up in guix?
<Petter>`guix import cpan <module>` fails to download meta-data for what I've tried so far.
<grillon_>mbakke: I did nothing about authorizations, I just followed install instructions.
<Petter>Hm, wait.
<grillon_>mbakke: two weeks ago when I have installed guix package manager I did because instructions tells to do it but for guixsd there's nothing about it
<mbakke>Petter: the CPAN metadata is case-sensitive
<mbakke>grillon_: oh, ok. I think hydra is authorized by default in the install image.
<mbakke>since you're on x86_64, you could stop the installation and run `guix pull` to get the latest available packages
<mbakke>then run `guix system init` again...there are definitely substitutes for the latest packages
<Petter>Hehe, yeah, initially i wrote module name like in the recipe, html-tidy, html-treebuilder. Got a recipe now though!
<grillon_>mbakke: before trying --fallback, I tried guix pull and it does not work too
<mbakke>oh :(
<grillon_>mbakke: some sources were missing. 90-kvm-rules or something like that
<grillon_>mbakke: almost 5 hours of compilation :(
<grillon_>mbakke: is gentoo so long to install?
<slyfox>nope :)
<grillon_>mbakke: it's a corei7 fourth generation with 16Gig of ram
<mbakke>grillon_: can you try restarting the installation without --fallback and see what fails?
<grillon_>mbakke: ok after 4h45mn :(
<mbakke>slyfox: emerge -e world would take comparable time..the stage3 tarball is cheating ;)
<mbakke>grillon_: any packages you've already built will be used again next time
<Petter>The import chose not to encapsulate the recipe in `(define-public <name> ... )` for some reason. I assume it makes sense in another context.
<mbakke>as long as you don't restart
<grillon_>mbakke: ressource are not well exploited. may be I could make a better parralelisation
<slyfox>mbakke: i don't think gentoo rebuilds glibc anf gcc as many times as guix does
<mbakke>slyfox: exactly. guix doess stage1-4 in one go.
<grillon_>slyfox: you're right
<grillon_>mbakke: restarted
<grillon_>mbakke: e2fsprogs not found
<mbakke>so you get a 404 from
<grillon_>mbakke: yes it is
<grillon_>mbakke: for version 1.42.13 of e2fsprogs
<mbakke>grillon_: /gnu/store/zz9msnfm44cl3py3hjqglksf8ymi0ac8-e2fsprogs-1.42.13 ?
<slyfox>[ being slightly offtopic gentoo has guix packaged ]
<mbakke>slyfox: cool! :D
<grillon_>mbakke: exactly
<mbakke>okay, I get it too... must have been garbage-collected :(
<grillon_>mbakke: ohh what can we do about it?
<DoublePlusGood23>Checking in again. Would anyone know what an encrypted root, formatted btrfs, appear as during bootup? trying to use libreboot and can't seem to get the --root flag right. It just drops me to a guile shell in the initrd.
<mbakke>grillon_: continue compiling, I guess... the binaries from the install image should be mostly exempt from garbage collection, but newer ones are not
<mbakke>if you've gone for 5hrs on an i7, there can't be much left :(
<grillon_>mbakke: let's start again
<grillon_>mbakke: is there a way to exploit all processors?
<slyfox>it should be a default
<mbakke>grillon_: build systems that support utilizing multiple processors will do so
<Petter>DoublePlusGood23: I'd guess /dev/mapper/<name> where you provide the name.
<grillon_>it's using about 5% of the whole processors, that's strange
<slyfox>what it is building?
<DoublePlusGood23>If I'm following the conversation, when I installed the other day I did have to use the --fallback option. Otherwise I'd get 404s for the substitutes. Took about 48hrs sadly :(
<mbakke>take that, gentoo
<DoublePlusGood23>Petter: I'll try looking there again, but I think that's for lvm drives
<slyfox>"that" you mean slowness?
<Petter>No, I specify --root=/dev/mapper/guix and I don't have LVM.
<Petter>"guix" I provided in config.scm, (mapped-devices ... (target "guix")
<grillon_>for now it's downloading
<DoublePlusGood23>mbakke: yeah Core 2 Duo will do that lol
<grillon_>DoublePlusGood23: 48h to install?
<Petter>Then (file-systems ... (device "/dev/mapper/guix")
<DoublePlusGood23>Petter: hmm I may have misslabled it.
<Petter>If you can show your config we can see if we can help.
<DoublePlusGood23>I gotta go to work sadly. I'll report back later tonight.
<efraim>I'm pretty sure e2fsprogs source is around somewhere, I built it on my aarch64 board with substitutes disabled
<slyfox>'guix build e2fsprogs --check' fails
<slyfox> guix substitute: error: download from '' failed: 404, "Not Found"
<slyfox>how does guix know that nar file should be there?
<slyfox>'guix build e2fsprogs --no-substitutes' fetches source just fine
<mbakke>slyfox: last I used gentoo, `emerge -e world` with ~1k packages took less than a clearly guix wins here, in terms of build times :P
<mbakke>I used to run that command to heat up my apartment during winter
<slyfox>i think i never did 'emerge -e world'
<mbakke>I typically did it after switching gcc
<slyfox>yeah, makes sense
<grillon_>build is finished but I cannot use the system anyway. I had another problem before. my disk is gpt. I just activate legacy bios but I cannot install grub on sda
<grillon_>I would like to erase all but I'm not sure my backups of patitions are up to date
<grillon_>anything I can do would takes lot of time. a find for recent files(more recent than my dump) on each partitions. then save theses files, erase everythings and restart installation for 5 hours :(
<grillon_>may be I can save guix partitions too...
<grillon_>and evite 5 hours of compilation
<mbakke>grillon_: do you have a "bios_grub" gpt partition?
<mbakke>or: did you get any errors from grub-install?
<grillon_>mbakke: it was from grub install
<grillon_>from guix init exactly
<grillon_>mbakke: last phase seems to be a grub-install
<mbakke>what was the error? on gpt systems, grub requires a small partition to embed itself instead of MBR
<grillon_>mbakke: unable to install grub on /dev/sda
<mbakke>how is your partition layout?
<grillon_>mbakke: gpt with 6 partitions
<Apteryx>grillon_: As mbakke said, you need a BIOS_partition:
<Apteryx>I've got an error trying to build our latest grub. After many passed tests, I get: make: *** [/tmp/guix-build-qemu-minimal-2.9.0.drv-0/qemu-2.9.0/tests/Makefile.include:816: check-qtest-i386] Error. Will investigate.
<grillon_>I was lazy and waste lots of time. what I can do is verify my backup. because I was lazy I did it with dd so I have to check if it's complete. then save guix_root and repart my disk as legacy :(
<grillon_>mbakke: have you receive my previous message? because I was disconnected for 2 minutes but weechat did not notice
<mbakke>grillon_: you don't need to change partition layout, but you need a BIOS boot partition that grub can embed itself in
<mbakke>if you have any space left, create a small 1MB partition and mark it as "bios_grub"
<mbakke>with parted
<mbakke>then grub should discover this partition and embed itself there
<mbakke>this is mentioned in the git manual, but not in the currently released one :/
<grillon_>mbakke: ok great thank you :)
<grillon_>mbakke: what type? could it be ext2?
<mbakke>grillon_: yeah ext2 is fine.. AFAIK that information is not actually used for anything :P
<grillon_>mbakke: not properly aligned for performance...because it's not used can I?
<mbakke>try using a larger partition, e.g. 2MB
<nckx>grillon_: alignment is irrelevant in this case.
<nckx>Don't worry.
<nckx>Just squeeze it on in there.
<grillon_>I have 1MB left. I guess it was for alignement
<mbakke>grillon_: lucky! performance does not matter for this partition indeed
<grillon_>ok done. when you say mark it. you mean the name? I put the name bios_grub but I see there is flag too. Do I leave it empty?
<mbakke>grillon_: the bios_grub flag needs to be set
<mbakke>hi lfam!
<lfam>Hi mbakke!
<paroneayea>I have an http+websockets applicattion written in guile, deployed to guixsd, behind nginx as a reverse proxy :D
<paroneayea> I should say
<mbakke>paroneayea: woop woop! now we just need a high-performance guile reverse proxy ;)
<paroneayea>mbakke: :) probably very feasible these days
<grillon_>mbakke: ok it's done I thought it was just a name
<Petter>paroneayea: Cool! :) I get: 502 Bad Gateway.
<jlicht>paroneayea: sorry to rain on your parade, but I am getting a 502 error on the https url atm :/
<paroneayea>oops :)
<mbakke>grillon_: yay! now try init again, grub should succeed this time
<paroneayea>I killed it to set it up in a screen session ;D
<paroneayea>and forgot to bringit up before sharing th elink
<paroneayea>the application running is not yet run in a guix service
<paroneayea>that's next
<paroneayea>Petter: jlicht: try again :)
<Petter>"sorry to rain on your parade". Nice expression ;)
<lfam>I just got a build failure from `guix pull`
<mbakke>looks like a missing module kei around?
<lfam>Right, from the netsurf move.
<lfam>I'm testing the fix and I'll push a followup ASAP
<mbakke>paroneayea: I tried telling the app to connect to file:///etc/passwd, but got disconnected...what am I doing wrong? :P
<paroneayea>mbakke: lol
<paroneayea>mbakke: it doesn't support that, but thankfully it doesn't seem to do anything scary either... though it should raise a more proper error :)
<paroneayea>it's not really a finished application either
<lfam>mbakke: There were other issues besides the missing build system module, so I decided to just revert the change.
<mbakke>lfam: :(
<lfam>Looks like there are several netsurf-related modules that are private to (gnu packages web), and they need to be exported, and who knows what else? :)
<lfam>They are also used in libparserutils
<grillon_> brb
<grillon_>guix is interesting and I'm sorry I could not try guixsd maybe another time as a VM. I give up. Thank you for your help
<CharlieBrown>I need to find my flash drive so I can install it.
<mbakke>grillon_: did grub not succeed this time?
<grillon_>mbakke: no it's not
<grillon_>mbakke: but not for same reasons
<mbakke>grillon_: what's the error message?
<grillon_>mbakke: I did reboot before you tell me what to do. so I have remount everything as before but if I try init it seems to reinstall. and if I do directly grub-install I have a message about gnu-store
<grillon_>mbakke: wait I restart to tell you the exact message
<grillon_>mbakke: failed to find path of cannonical unionfs
<mbakke>grillon_: uh.. what is the exact command that gives that error?
<grillon_>grub-install /dev/sda
<mbakke>try passing --boot-directory=/path/to/guisd/boot/partition/mount as well
<paroneayea>lfam: looks like I must have review-failed
<lfam>paroneayea: Life goes on :)
<paroneayea>that'll teach me to do patch review ;)
<paroneayea>jk jk
<mbakke>I wonder what f18f4364d83075c595e4ca2aa20098eff77939a4 was about
<grillon_>mbakke: trying to install encrypted disk without cryptodisk enbaled...
<grillon_>mbakke: I have added GRUB_ENABLE_CRYPTODISK=y where it tells me to but still don't work
<mbakke>grillon_: I suspect that error might be unrelated
<mbakke>it should work to unlock the guixsd LUKS partition, mount it at e.g. /mnt/, then run `grub-install --boot-directory=/mnt/boot /dev/sda`
<grillon_>mbakke: that's what I did
<grillon_>mbakke: it's unlocked already
<mbakke>grillon_: then I'm running out of ideas :( haven't used encrypted /boot with guix, yet
<marusich>grillon_, I am late to the conversation, but the things you two are talking about sound quite different from what I think the manual describes for the installation procedure.
<marusich>Are you trying to install GuixSD in some kind of special situation?
<mbakke>marusich: grub-install failed during init due to missing BIOS boot partition, now we're trying to recover
<marusich>I see. That sounds unpleasant :(
<mbakke>looking at gnu/build/install.scm, it seems we're missing two steps
<mbakke>grillon_: can you try to first `export GRUB_ENABLE_CRYPTODISK=y`, then run the "grub-install" command from earlier, also passing "--no-floppy"
<grillon_>mbakke: ok
<grillon_>mbakke: it works
<grillon_>could I restart?
<mbakke>we also need to copy the generated grub.cfg
<mbakke>if you have the mounted guixsd system on /mnt, run this command: `find /mnt/gnu/store -maxdepth 1 -name '*grub.cfg'`
<mbakke>and copy that to /mnt/boot/grub/grub.cfg
<mbakke>then, pray to deity of choice and reboot :)
<rekado>I don’t get it: on i686 the glibc build fails
<rekado>but I cannot reproduce this on my x86_64 machine
<rekado>here’s what I do: “./pre-inst-env guix build --system=i686-linux -e '(@@ (gnu packages commencement) glibc-final-with-bootstrap-bash)'”
<rekado>on hydra this package fails to build after 12 seconds
<rekado>it fails because it doesn’t find the patch among its inputs
<rekado>does anyone see what’s wrong here?
<lfam>rekado: I noticed that; it's strange
<rekado>it’s not a very big problem considering that this is just a commit to get glibc to build for i686 without having to rebuild it for any other architecture
<rekado>on core-updates this would be partially reverted and the patch applied the usual way
<rekado>but it is very strange indeed
<lfam>I don't have access to a "real" i686 machine, so I'd boot GuixSD in QEMU for i686 and then strace it
<lfam>I'm not sure how else to debug it
<lfam>Are we sure the patch is being applied when building from x86_64 for i686-linux?
<Apteryx>Any way to tell emacs to "resize images to fit frame" instead of "fit frame to image size", when viewing graphs (M-x guix G v) ?
<Apteryx>The images are always way bigger than my display, and horizontal scrolling in emacs is a pain.
<Apteryx>Grub has apparently a dependency on qemu-minimal, and qemu-minimal tests are failing.
<lfam>Apteryx: How do they fail?
<lfam>For me, they are passing
<mbakke>rekado: could that failure be an effect of the syntax error that was fixed earlier today?
<mbakke>I've verified that the patch is applied when cross-compiling
<Apteryx>lfam: Like this:
<lfam>Apteryx: What commit are you building from? What architecture?
<lfam>And what kernel version?
<Apteryx>I'm using guix master at commit 564324f4571a37aa746507fcde6b1546c8b3e416, x86_64.
<Apteryx>12 hours old maybe.
<lfam>Hm, it should work. Can you reproduce the failure?
<lfam>Hopefully it's just a flaky test
<Apteryx>Yes, I've reproduced thrice so far. I'll try one more time and check if it's the same exact test. If so, I'll submit a patch to disable them.
<Apteryx>I also had problems with python2-urwid again yesterday. I've remove the offending test module (test_vterm) and sent a patch for this on the bug tracker.
<lfam>Did the urwid maintainer have any advice for you?
<Apteryx>lfam: I've opened an issue but no replies from the authors yet.
<rekado>mbakke: I don’t see how. I fixed the error, pushed and restarted the build, but it still fails.
<lfam>I opened a bug for flaky urwid tests over a year ago but got no response. I think you'd have to bring a patch
<Apteryx>I tried understanding the root issue but couldn't make sense of it. It only affects Python 2 and not Python 3.
<Apteryx>And when I used strace the test failures went up (eh?). That's where I decided to simply remove the test module, for Python 2 only.
<lfam>Apteryx: Re QEMU, you could try tracing the test execution as demonstrated here:
<mbakke>rekado: does restarting the glibc build also pull the latest guix sources?
<mbakke>I didn't see any new evaluations here
<lfam>Restarting the build (a "job" in Hydra parlance) won't update the sources. Each evaluation is tied to a Git commit.
<rekado>oh, right, no new evaluation!
<rekado>I assumed there had been a new evaluation since pushing my change
<lfam>Doesn't look like it
<Apteryx>lfam: When building qemu, at the ./configure phase, I see make messages such as "make[1]: flex: Command not found", "make[1]: bison: Command not found". Should we include flex & bison as native-inputs?