IRC channel logs


back to list of logs

<zacts>I just saw this article about mcron on
<zacts>is guix going to use mcron for its cron, instead of vixie cron?
<zacts>so I'm brainstorming a way I may be able to run the guix distro as my main distro
<zacts>one idea would be to have a chroot debootstrapped debian jessie on top of the guix distro
<zacts>for any packages that guix doesn't offer
<zacts>I just don't know what the proper way to do this would be, and what the logistics would be
<zacts>so any ideas / insights / tips / etc... would be welcome
<vmlinuz88>zacts Guix is not a stable enough distro to use a your main. it is still alpha software.
<zacts>vmlinuz88: I realize guix is alpha software
<zacts>I'm a power user
<zacts>but I would like to have a few more packages than guix currently offers
<zacts>while I help work on / test / develop guix
<zacts>if it crashes it crashes
<zacts>I do make regular backups
<zacts>and I would personally rather run guix on bare metal as a distro, than just a package manager on top of debian, so I can really fully see the implications of my testing, and packages
<gnusosa>zacts: have you tried the GuixSD
<zacts>what is GuixSD again?
<gnusosa>zacts: I don't know about LVM missing point, there seems to be a package now...following the list.
<zacts>oh the Guix System Distribution
<gnusosa>zacts: also there's XFCE and some gnome packages
<zacts>I just use stumpwm
<zacts>I don't use any desktop wm, unless I'm directly testing them
<zacts>oh the only thing is that I wonder if guix allows for full disk encryption yet
<zacts>I forgot about that one
<zacts>the guix manual sleightly mentions FDE
<zacts>well DE, not FDE
<zacts>it mentions cryptsetup and parted
<gnusosa>I don't see dm-crypt
<gnusosa>in the list
<zacts>ah ok
<zacts>well, I'll have to stick with debian host for now then
<zacts>I could run guix in kvm though
<zacts>for now
<gnusosa>oh yeah cryptsetup
<zacts>and use the guix package manager on top of debian for now
<zacts>yeah cryptsetup
<gnusosa>Yeah well there you go
<gnusosa>you will probably have to modify your system scm
<zacts>well, the problem isn't that I just need cryptsetup
<zacts>it's that the init and boot system needs to know how to unencrypt FDE
<zacts>at boot
<zacts>so on other systems mkinitcpio would add cryptsetup modules dm-crypt modules to the initial linux kernel at boot
<zacts>for sure, I could attach a cryptsetup encrypted drive to a running guix system via cryptsetup
<zacts>but FDE is a different story
<gnusosa>ohh you mean like
<gnusosa>fair enough
<gnusosa>yeah you will have to use initram
<zacts>what is initram?
<zacts>I just don't know the guix specific details of initramfs
<gnusosa>Yeah I don't know that guix will create that.
<gnusosa>but once you boot into it
<zacts>I'll just wait on it for now
<gnusosa>you can create it yourself
<gnusosa>that's more on GRUB to drive that :)
<zacts>I'll just use kvm + GuixSD for now
<zacts>and debian host
<zacts>but perhaps I myself can contribute in this direction of FDE + GuixSD
<gnusosa>I started with bare stage3 from Gentoo, quickly move to GuixSD
<zacts>to make it easier
<gnusosa>I created the initramfs and kernel in Gentoo
<zacts>oh cool
<zacts>ok, brb
***tschwing_ is now known as tschwinge
<civodul>Hello Guix!
<mark_weaver>good morning!
<zacts>I'm still awake
<zacts>I shouldn't have had that caffeinated beverage with my dinner last night
<zacts>It's 2:12am for me though
<rekado_>for some reason icedtea6 now fails and the fix appears to be to add another directory to the include paths.
<rekado_>unfortunately, the directory is target-specific.
<rekado_>looks like this: /lib/gcc/x86_64-unknown-linux-gnu/4.8.4/include/gcj/
<rekado_>how can I generically generate something like "x86_64-unknown-linux-gnu"?
<rekado_>I wonder why gcj does not install the only file in that directory to /include.
<civodul>rekado_: probably with "gcj -print-file-name" or -print-libgcc-file-name
<civodul>yeah try "gcc -print-file-name=include"
<civodul>maybe it just needs to be added to $CPATH?
<civodul>do you know which commit caused the regression?
<rekado_>civodul: I don't know which commit is responsible.
<rekado_>I just saw that it's broken after fixing the gcj build.
<rekado_>icedtea6 builds when I add the path to the include dir to CPATH.
<thomassgn>Hi. trying to setup guix here. I have used the sample config with minor changes (hostname, timezone, fs device and label, username and comment). Running 'guix system -c5 -M10 --fallback init /mnt/etc/config.scm /mnt' I get 2 failures in 'Testsuite summary for GNU Guix 0.8.1'. I also cannot find (via locate after updatedb) the log file, probably because of "Makefile:3392: recipe for target 'test-suite.log'
<thomassgn>failed". Troubleshooting/fixing help/tips wanted
<rekado_>I just discovered that (with-output-to-string (lambda _ (system* "date"))) does not return the output because system* does not write the output to the current output port.
<rekado_>How can I capture the output of running a command such as "gcc -print-file-name=include"?
<davexunit>thomassgn: okay, so first thing: if you are compiling stuff during the installation that's going to take an extremely long time.
<davexunit>you should enable substitutes from
<davexunit>second thing: failed builds are deleted, so you won't find that test suite log file without running 'guix build -K guix'
<davexunit>(then it will be in /tmp somewhere)
<civodul>thomassgn: could you try "guix build -K guix"?
<civodul>oops, davexunit already suggested that
<civodul>rekado_: (use-modules (ice-9 popen)) (open-input-pipe "gcc --foobar")
<rekado_>civodul: thanks!
<thomassgn>davexunit: hoy, sorry. I am used to running gentoo where I build all my software from scratch :P Will try running with -k build: 'guix build -c5 -M10 guix'.
<thomassgn>hum, so the build failed with the same errors, and I can still not find anything in /tmp or via locate. I think the '--fallback' flag just means 'compile from sources if missing packages from hydra', at least that is what I gathered from the documentation. I see plenty of stuff being downloaded from hydra something
<thomassgn>davexunit: civodul ^^
<thomassgn>by anything I mean the test-suite.log specifically or other contents in /tmp
<thomassgn>oh, hehe, ignore that. I forgot to add the -K
<civodul>heh :-)
<thomassgn>looks like there was a package that is corrupt, running the guix build with '--no-substitues' so it'll build all the failing ones from source (the good ones have already been finished it seems)
<civodul>thomassgn: oh, downloading the substitute failed saying the thing is corrupt?
<rekado_>the patch I just sent to the ML fixes icedtea6 and icedtea7 for me.
<thomassgn>civodul: from the test-suite.log I get something like ';;; (c #<condition &nix-protocol-error [message: "signed hash doesn't match actual contents of imported archive; archive could be corrupt, or someone is trying to import a trojan horse" status 1] 1c43390>)" Ironically this is for the derivation '...-corrupt-substitute.drv'.
<thomassgn>the 2 tests that fail are tests/nar.scm and tests/store.scm
<davexunit>paroneayea: I saw in an email that you removed the check phase from your guile-emacs build. instead of removing the phase, just add '#:tests? #f' to 'arguments'
<rekado_>I have a patch to remove non-free functions from shogun, but I want to wait until I can be sure it's actually still compiling before I send it to the ML.
<rekado_>(need to download texlive again...)
<paroneayea>davexunit: aha ok!
<civodul>thomassgn: could you paste test-suite.log as well as $top_builddir/{nar,store}.log ?
<civodul>rekado_: re texlive, :-(
<civodul>we really need to call for hardware/hosting donations if we want to scale
<civodul>i feel inexperienced in that area
<civodul>anyone willing to help? :-)
<Steap>I hear that sects are really good at convincing people to give them most of their belongings
<davexunit>I'm setting up the church of guix. tax exempt ftw!
<Steap>we already have the church of emacs
<Steap>so I guess it is doable
<davexunit>yeah, we have close ties to that church.
<civodul>ok, who wants to be the guru? :-)
*paroneayea elects civodul
<civodul>a guru has to be self-proclaimed, not elected ;-)
*paroneayea elects himself!
<paroneayea>not because I want to, but because I'm the only person I can elect!
*civodul has to go
<davexunit>paroneayea: I am the true leader of the holy order of guix!
<davexunit>now we must fight
<paroneayea>davexunit: fighting sounds like work :)
<thomassgn> search for '$ cat' to get to the beginning of each file.
<thomassgn>hurr, too slow for civodul apparently :(
<mthl>Hello Guix!
<paroneayea>hello mthl !
<mthl>I'm about to push my changes in guix-artwork but i have a last commit message question before...
<mthl>Should i use dots instead of repeating "Likewise."
<bavier>mthl: The repeated "Likewise" seems fine
<bavier>mthl: I believe may also apply here
<phant0mas>the final mig needs to link against flex, so flex should be a input not a native-input.
<phant0mas>so that's not a problem for our cross-toolchain.
<phant0mas>but when I try to build for target=i686-gnu flex is not in the cross-library-path so I get undefined reference to `yywrap'
<mthl>bavier: I don't know, since the "callers" were not there before...
<phant0mas>well no big deal I add flex to inputs
<phant0mas>and then when the problems start
<phant0mas>flex needs m4
<phant0mas>m4 has every damn test fail
<phant0mas>probably because m4 at this point is targeting hurd
<bavier>mthl: that's right
<mthl>bavier: I will wait for civodul 's blessing! :-)
<phant0mas>so I tried disabling tests when cross-building
<phant0mas>looked good
<bavier>mthl: always a good idea ;)
<phant0mas>but then bison with target hurd starts complaing that m4 is not usable
<phant0mas>need your opinions because I am ready to start hiting my head against the wall
<bavier>phant0mas: could you list flex as both an input and a native-input?
<civodul>mthl: the change log looks good!
<civodul>for new files it's enough to write "New file." without providing details of variables/procedures added
<mthl>civodul: thanks
<mthl>I will push after dinner :-)
<civodul>enjoy your meal!
<phant0mas>bavier: you can, but the result is the same, the one targeting hurd will fail
<civodul>phant0mas: probably flex needs to be provided both as native and non-native
<civodul>native for the "flex" program, and non-native for libfl
<phant0mas>I did that, the problem though is that m4 which is a dependency fail
<phant0mas>actually make check fails
<phant0mas>all of the tests
<phant0mas>with segfault
<phant0mas>civodul: I sent all the logs from m4 to the list, please have a look
<civodul>when cross-compiling, 'make check' does nothing normally
<civodul>because nothing can be done
<alfplayer>I keep trying to install Guix by running "guix system init" from the Guix USB 0.8.1
<alfplayer>I copied /etc/configuration-template.scm to /mnt/etc/config.scm, removed xorg from use-service-modules and slim-service
<zacts>hi guix
<alfplayer>this is the log:
<alfplayer>two fails on that test suite
<alfplayer>at the end
<alfplayer>it installs xorg anyway; how can I avoid this?
*civodul looks
<civodul>alfplayer: thomassgn report the same issue earlier today, with guix itself failing to build
<civodul>one thing you could try is to run 'guix pull' prior to 'guix system init'
<civodul>that will allow you to install current guix master
<civodul>(as a workaround)
<zacts>ok, I'm going to work on my guix pm install on debian jessie
<phant0mas>civodul: in the case of m4 it runs the test for some reason
<phant0mas>I will disable the tests when cross-building and make bison use it whether it likes it or not :P
<alfplayer>can I install a shell-only system, without Xorg?
<civodul>alfplayer: normally yes, but you're saying Xorg was being built anyway?
<alfplayer>civodul: yes, it was built anyway
<civodul>oh i see
<civodul>i think the main issue is that things are being built from source
<alfplayer>civodul: many packages were built, even after enabling substitutes using guix archive --authorize < ...
<civodul>and some libraries use xorg-server as a build-time dependency
<civodul>alfplayer: yes, that's because the substitutes for 0.8.1 are no longer available on
<civodul>really a mistake on our side
<civodul>if you run 'guix pull', you'll have the latest & greatest, and so substitutes will be available
<rekado->the guix emacs mode isn't working for me (using Guix on Fedora) :-/
<rekado->"error in process sentinel: sleep-for: Text is read-only"
<rekado->"error in process sentinel: Text is read-only"
<rekado->I get these messages when running M-x guix-all-available-packages
<rekado->(or any other M-x guix-... command)
<rekado->oh, there are errors shown in the REPL buffer
<civodul>rekado-: we need alezost's help here
<civodul>perhaps you could mail the list
<civodul>feedback welcome on the new "X.509 Certificates" section, from mark_weaver notably :-)
<rekado->is there a way to use guix.el without a "make install"'d Guix?
<rekado->I see that ./emacs/guix-helper.scm contains a configuration with a prefix to look up guile modules.
<rekado->I'd much rather use it with the current version from git.
<alfplayer>"guix system init /mnt/etc/config.scm /mnt" after "guix pull" now returns this
<alfplayer>guix system: error: failed to load '/mnt/etc/config.scm':
<alfplayer>ERROR: In procedure module-lookup: Unbound variable: canonicalize-reference
<alfplayer>any clue?
<alfplayer>it seems canonicalize-reference was removed
<alfplayer>config.scm must be updated from the USB version?
<paroneayea>kind of disturbed that if you (require) something in racket that you don't have
<paroneayea>that it'll stop to fetch it from the package repo
<paroneayea>troubling from a #guix perspective
<paroneayea>maybe convenient for many users