IRC channel logs

2017-10-13.log

back to list of logs

<TaoHansen[m]>well %gnome-desktop-service is now failing to build Totem and grub-efi is bailing out with https://paste.pound-python.org/show/ALJHwe5Np4o1rTZ4VjsN/
<TaoHansen[m]>(bootloader (grub-configuration (grub grub-efi)
<TaoHansen[m]>(target "/boot/efi")))
<Apteryx>thomassgn: OK, thanks for checking. There must be something's wrong with bayfront SSL cert.
<Apteryx>s/'s//
<niebie>Hey guys, I have a problem when installing GuixSD on a fresh system - one test fails when building guix itself
<niebie>its defined in tests/store.scm
<niebie>verify-store + check-contents
<niebie>The error is that the path is not in the Nix store.
<niebie>the path looks mangled - dtmp/guix-tests/store/<hash>-tar
<niebie>So it seems to me like this test failing is a false failure, and something is wrong with the test
<niebie>Can I install GuixSD skipping this test for now, since it looks like a false failure?
<Apteryx>niebie: you can definitely use that built guix to install guix on your system, even if the tests failed.
<Apteryx>Although it can be useful to report tests failures to the project so that they get fixed!
<niebie>It failed during 'guix init' - how do i supress the tests with that call? or do i need to use 'guix environment guix', and then make install it?
<Apteryx>guix system init?
<TaoHansen[m]>man GuixSD is really frustrating. GNOME stopped building so okay, trashed that, i'll just use the Emacs X Window Manager like i'm used to. tore out %gnome-desktop-service, rebuilt, started up EXWM, everything was tiny. no problem, i'll just install xrdb, write a new .xsession since the default SLIM should source it. nope. okay, tear out all of %desktop-services, replace with %base-services, install xinit and rebuild.
<TaoHansen[m]>that's where i left off. every rebuild takes ages because for some reason GuixSD needs to compile everything over again from scratch? why does it do that?
<TaoHansen[m]>every single build where i trash and replace something, GuixSD for whatever reason rebuild really basic packages i know it has already.
<TaoHansen[m]>rebuilds*
<davexunit>if you haven't installed guix as a user then you are using an older and older guix with each reconfigure of the system
<TaoHansen[m]>davexunit: why is that default behavior?
<davexunit>because any other way is not possible
<davexunit>guix installs guix, but it can't possibly know the hash of itself
<davexunit>thus the system guix refers to a slightly older version
<TaoHansen[m]>so fresh install i should be doing a guix package -i guix right off the bat?
<davexunit>'guix pull' to get the latest
<TaoHansen[m]>davexunit: i would do this except everything is broken on the latest. i know GuixSD is considered beta but latest packages break GNOME and UEFI
<TaoHansen[m]>prefer to stay on the ISO's versions it tracks
<davexunit>okay
<davexunit>you can guix pull a specific version
<davexunit>but anyway, that's why things keep rebuilding. gotta go.
<TaoHansen[m]>davexunit: makes sense, thanks for your help
<davexunit>(I know it's not great that it's like this, but I don't know what a possible solution could be)
<TaoHansen[m]>could someone paste their .xsession for me? i'd like to make sure i'm composing it correctly.
<TaoHansen[m]>nevermind, nailed it!
<niebie>Apteryx: yes, 'guix system init'
<Apteryx>I believe the tests you see are tests from dependencies pulled by your operating-system definition. There's no easy way to turn them off for the time being.
<Apteryx>niebie: maybe it's already been fixed in latest guix? Have you tried running guix pull before running guix system init?
<Apteryx>Otherwise, I'd report the issue.
<sturm>I'm getting a `gzip: stdin: unexpected end of file` when guix gets to installing linux-libre
<sturm>(on a guix pull from today)
<sturm>download gets to 25% then stops
<sturm> https://mirror.hydra.gnu.org/guix/nar/gzip/ypi36cjc28daw95m2sqaywvhbpdknjb3-linux-libre-4.13.5
<sturm>seems to download ok when I try it in a web browser on another computer
<sturm>working now... weird
<civodul>Hello Guix!
<kmicu>( ^_^)/
<amz3>hey
<mekeor>hellou, amz3
<mekeor>:)
<civodul>plop
<Apteryx>hello guix!
<rekado>the missing RAID controller modules seem to be mpt2sas, mpt3sas, megaraid_sas
<Apteryx>rekado: good you found out!
<Apteryx>rekado: Is it known to you that bayfront's SSL cert seem to be broken, at least with gnutls? Should I report a bug about it?
<rekado>now I wonder how I can get the new initrd on that server…
<Apteryx>do you have physical access to the machine?
<rekado>sometimes, yes
<rekado>I could boot from a USB stick and init the config again, this time with the missing module
<Apteryx>wouldn't it be possible to start a guix install again, and fixing your initrd option from there?
<rekado>but that’s so brutish
<civodul>Apteryx: what do you mean about bayfront's cert?
<Apteryx>rekado: in what ways?
<Apteryx>In my opinion (and it might not work like this currently), when mounting an existing root in the installer, it should be possible to to redownload/rebuild the dependencies which are already found in the /gnu/store... But maybe that's not possible currently for some reason?
<Apteryx>to *not* redownload
<Apteryx>civodul: try this: guix download "https://bayfront.guixsd.org/file/nnn-1.3.tar.gz/sha256/0sivgcmg3hihz15v2wgbxnd0icn06pyvvqdqh8x0mwkhvm434fpb"
<Apteryx>If you can reproduce, you should see something like: ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum An unimplemented or disabled feature has been requested.> peer-certificate-status)'.
<Apteryx>The same file uri works fine over other substitute servers such as berlin.
<Apteryx>civodul: I'm close to have a script that validates or invalidates the 650ish dynamically generated archives that we get from github for our packages, but am having some issue with managing ports. If you have some bandwith, here's one of the procedure: the dynamic-wind somehow closes the ports I open in the let above. Advice welcome! http://paste.lisp.org/display/358456
<civodul>Apteryx: "An unimplemented or disabled feature has been requested."?
<civodul>what's that?
<Apteryx>haha, I have no idea? One wild guess would be that the cert uses ECDSA or something which has not been enabled into our gnutls build?
<civodul>weird
<civodul>could you email bug-guix? :-)
<Apteryx>sure!
<Apteryx>voila
<civodul>thank you!
<Apteryx>yw!
<Apteryx>I'll try using url-fetch instead of guix-download -- this should make my life easier
<civodul>rekado: did you have a chance to test the monad/thread-safety patch?
<civodul>bavier: i have a patch whereby compile-all.scm honors make's '-j' flag :-)
<civodul>(as part of a series about 'guix pull')
<bavier>civodul: yay!
<bavier>I realized at some point that'd I'd want to rewrite a significant portion of the futures implementation and (guix workers)
<bavier>civodul: could I review the patch?
<civodul>bavier: definitely, i'll send it to debbugs and Cc you
<ng0>civodul: progress on the great memory reef barrier?
<civodul>well, more or less :-)
<civodul>i'm trying several approaches in parallel
<civodul>which may or may not be a good idae
<civodul>but it's pretty hard to stay focused on a single approach
<ng0>A beginning is more than we have right now
<ng0>so even more or less is more :)
<civodul>right :-)
<civodul>we'll get there
<civodul>i'm determined!
<civodul>bavier: did you see the monad/thread-safety patch i posted yesterday?
<civodul>i think you hit that problem too
<bavier>civodul: I didn't see it yet
<bavier>the patch that is
<civodul>it's in https://bugs.gnu.org/27476
<civodul>if you could test on some big machine where you experienced the bug before, that'd be great
<bavier>civodul: sure, I can try it on a big machine. I haven't run into that error yet (haven't yet run 'guix pull')
<bavier>the problem I encountered earlier was a test failure in tests/workers.scm
<civodul>bavier: right, i've seen that bug report, and i think your conclusions are correct
<civodul>the "guix pull" bug could also happen with 'make'
<civodul>since it's the same build method
<bavier>hmm, ok, I'll try running 'make' a few more times
<Apteryx>The script is running! We'll know exactly how many of our Github packages are broken since they patched their git.
<Apteryx>Eh, we are a Friday 13.
<coolNate>hello
<coolNate>I'm interested in installing GuixSD since I got a new Qualcomm Atheros libre wifi adapter
<coolNate>but I have EFI and I'm not sure if you can do it
<bavier>coolNate: guixsd has EFI support
<bavier>IIRC
<coolNate>ok
<coolNate>I tried doing the install but there seem to be no methods of actually setting it up
<coolNate>I tried not installing the bootloader at first and then chrooting to /mnt and there were no commands or anything
<coolNate>I was trying to install grub from the new base system but I had no luck
<zacts>hello
<zacts>does guix provide reproducablility in any way?
<zacts>like reproducible builds of certain packages
<zacts>reproducibility*
<oriansj>zacts: technically guix doesn't make the packages reproducible but rather simplifies the packaging of programs in reproducible ways.
<oriansj>eg. build in chroot with known inputs, should produce a deterministic that given a well behaved program should be reproducible.
<zacts>ah nice
<bavier>zacts: and guix has several tools to help fix reproducibility issues, like 'guix challenge', 'guix build --rounds=...'
<TaoHansen[m]>can one define the contents of system files through their config.scm such as /etc/fstab and /etc/sudoers?
<civodul>TaoHansen[m]: /etc/fstab is generated based on the 'file-systems' field
<civodul>and /etc/sudoers is copied from the 'sudoers' field
<civodul>'sudoers-file' actually
<civodul> https://www.gnu.org/software/guix/manual/html_node/operating_002dsystem-Reference.html
<TaoHansen[m]>civodul: thank you