IRC channel logs


back to list of logs

<dpg>The spiffy script on to build all guix packages fails to build and exits constantly for me even with the --keep-going flag. Is there a better way to fill up your store for guix publish?
<dpg>This seemed to be the next best thing after offloading wouldn't function.
<lfam>dpg23: How does it fail? Also, if you can't get offloading to work, you should ask on
<dpg23>lfam: I'll run here for a bit, and paste the error.
<dpg23>lfam: Here was my error for offloading: I thought it might be related to this patched bug.;bug=18115
<lfam>Hm, I'm not sure :) You should send it to help-guix
<dpg23>lfam: will do thanks.
<dpg23>lfam: Seems the build script is failing here: . I was under the impression --keep-going would ignore that.
<lfam>dpg32: I'd also expect it to continue
<lfam>I wonder if it does --keep-going in the context of the build target's dependency graph, but not in the list of target
<lfam>I would send that one to :)
<lfam>Also it would be good to figure out why yasm is failing to build
<dpg23>Thanks for the help :)
<lfam>I just built yasm on my x86_64 machine. Are you on x86_64?
<lfam>dpg23 ^
<dpg23>Yup, x86_64 on Ubuntu
<lfam>Huh. Would be interesting to see yasm's test suite log (if retained with -K)
<dpg23>lfam: It seems to build fine now...
<lfam>Some non-determinism in yasm's build system, it seems.
<dpg23>lfam: must be.
<lfam>Rather disturbing IMO
<dpg23>lfam: I know one of guix's listed goals is to be completely determinist. Do modern package managers have that problem?
<lfam>Can you clarify your question?
<lfam>Like, what do you mean by "modern package manager" and "problem"?
<dpg23>modern package manager = apt, zypper, pacman, etc. problem = non-deterministic outputs.
<lfam>Pretty much all efforts to build software from source code have these issues, whether in the context of a package manager or, for example, when building by hand by typing `make`.
<lfam>There could be some part of the software's build system that embeds a timestamp, or that uses random numbers
<lfam>Or there could be a race condition in the build system, which I suspect for yasm
<mark_weaver>dpg23: see for more on this
<dpg23>lfam: Huh, interesting. mark_weaver: I'll check that out, thanks.
<lfam>But if you "zoom out" from those minor issues, you can see difficulties with even knowing where your binaries came from, which Guix can help with.
<dpg23>lfam: Doesn't apt/dpkg, for example, solve that by signing packages from the repos?
<dpg23>mark_weaver: That was very informative, thanks.
<lfam>dpg23: Those signatures tell you that the package you are downloading was signed by somebody that owned the key used to make the signature. But, it doesn't help you understand how the package was built, or how you could rebuild it
<lfam>Those signatures are just about ensuring that malicious people don't trick apt users into downloading malicious binaries
<dpg23>lfam: So guix builds are signed to prevent malicious binaries and also proves the binary == the source?
<mark_weaver>dpg23: reproducible builds enable *anyone* to independent verify that the distributed binaries are genuine
<lfam>"Sort of" to the first part. No to the second part. All a cryptographic signature tells you is that the signed file was signed by the owner of the key. You have to decide if you trust the key's owner to not be malicious
<lfam>For reproducing builds, you need to tightly control the inputs to the build. This means all the dependencies of the build, the compilers, and the environment.
<lfam>I recommend reading the original Nix paper to get an idea how Guix and Nix try to achieve that
<dpg23>Ah, I see. I'm guessing this also means it only really works with FOSS software.
<lfam> <> Nix: A Safe and Policy-Free System for Software Deployment
<lfam>dpg23: Well, being able to build reproducibly matters for vendors of proprietary software too. Presumably they want to know how to reproduce the binaries they distribute.
<dpg23>lfam: ?
<lfam>No, the one titled Nix: A Safe and Policy-Free System for Software Deployment
<dpg23>lfam: Ah just saw your message.
<lfam>All the ugly hashes in /gnu/store are an effort to capture the dependency graph of the store item. The hash is the hash of all the inputs to the build.
<lfam>Read the paper, you will be enlightened :)
<lfam>I bet that paper you linked would be very interesting too, although I don't know if it's relevant or not
<dpg23>lfam: reading now, thanks
<dpg23>lfam: Wow, that was a good read.
<dpg23>lfam: The Guix design makes much more sense now.
<lfam>dpg23: I'm glad!
<dpg23>lfam: Why does Guix use Guile Scheme though?
<dpg23>lfam: Is it just do to being the GNU extension language?
<ijp>probably the main reason is the civodul is comaintainer of guile
<lfam>dpg23: You should ask civodul, I don't want to speak for him :)
<lfam>But, I use NixOS a little bit on the side, and I really prefer the use of Guile over the Nix language. It's great to have the Guix domain-specific-language embedded in a full programming language like Guile.
<lfam>Now that you have read the Nix paper, you should read the Guix paper:
<dpg23>I'll ask him then, thanks.
<dpg23>lfam: Will do, last one was very interesting.
<dpg23>lfam: But beforehand ,this might not be appropriate for this channel, what is GNUNet exactly? I've tried using it before and it seemed to be a less functional Freenet or Tor.
<lfam>dpg23: It's where I read this channel's IRC log ;)
<lfam>To be honest, I don't know all the applications. I know what it says on and not much more. I think ng0 is involved in gnunet
<dpg23>lfam: Yeah the logs were hosted there and it got me curious. Too bad he just left.
<dpg23>lfam: Would using docker or Linux containers in general be useful while building software in guix? In the sense of keeping a seperate build enviroment.
<lfam>dpg23: It happens in a chroot, which is described in the Guix paper I linked earlier. If you read that, you'll probably end up knowing more than I do about the build environment in the chroot ;)
<dpg23>lfam: Reading now. Pretty interesting so far.
<dpg23>lfam: Thanks again, that was really informative.
<lfam>Cool, glad to hear it
<dpg23>The (build-system ) concept is really brilliant.
<efraim>debugging cmake-3.5.2 now, ctestupload ... wait for it... tries to open a connection to
<civodul>Hello Guix!
<ecraven>hello civodul
<rekado>I'm trying to package an addon to EMMS, but since it isn't installed to %install-suffix EMMS files are not found at build time.
<rekado>Is there a way to add a directory to the build phase without replacing the phase completely?
<civodul>rekado: to add a directory to the build phase?
<civodul>not sure what you mean :-)
<civodul>i'm glad you added all these Emacs packages, BTW!
<civodul>unprivileged guix builds are the hot thing these days!
<rekado>I meant: make Emacs find "emms" at built time.
<rekado>the emacs-build-system installs things to %install-suffix and only adds files from there to the Emacs load-path.
<rekado>"emms" differs.
<rekado>it does not install things to the "guix.d" subdir AFAICS
<civodul>i see, maybe we should change that?
<civodul>that's a question for alezost i guess
<rekado>if I remember correctly, alezost is no fan of the "guix.d" subdir.
<civodul>right, but still ;-)
<efraim>reverting cmake->3.5.0 on core-updates fails with the same error about libarchive's version
<efraim>upgrading it to 3.5.2 didn't help either
<rekado>davexunit: does avr-gcc work for you?
<rekado>I get this error as I'm trying to build for an Atmega32: "avr-ld: cannot find crtatmega32.o: No such file or directory"
<rekado>it also attempts to link with -latmega32 but this library doesn't exist.
<rekado>I'm pretty sure that it should be crtm32.o.
<rekado>also not good: "avrdude was compiled without usb support."
<rekado>even though we have a patch to make it compile with libusb.
<jlicht>rekado: is avr* the stuff that is used for Arduino as well?
<ng0>i think i might have questions about the 'scripts' dir later, after some more reading, to clarify my understanding of stitching together gnunet-fs with the gnunet.git repo of guix and a gnunet-service and something in between, towards an gnunet-fs based guix pull. I have some ideas which make sense. I'll address that in an email, irc is not satisfying for me for that for long text.
<rekado>jlicht: I think so.
<rekado>I've never used Arduinos; only plain AVR Atmega*
<ng0>well, pull and package and publish and all that.
<ng0>i did not leave, i just idle. but dpg23 left already. i think it's also nicer to not assume pronouns of other people ;)
<ng0>i know there's an english version somewhere, but i forgot the homepage.. for the people who are able to read german, this one is an interesting paper: (GNUnet und informationsmacht: Analyse einer P2P-technologie und ihrer sozialen wirkung)
<rekado>looks like building avrdude with "libusb-compat" instead of "libusb" (and without the patch) are sufficient to make usb support work again.
***kelsoo1 is now known as kelsoo
<Lillo>i've errors during guixsd compilation
<Lillo>some packages are unreachables
<Lillo>help me please
<ng0>I'll have a look
<ng0>pastes are often more useful than a vague description :)
<ng0>everything else is reachable?
<Lillo>an other question: why "guix package -i guix" installs guix 0.9.0 and not guix0.10.0?
<ng0>is this during or after the initial setup of guixsd?
<civodul>Lillo: is inaccessible via Tor; could you try instead (for instance)?
<ng0>you should never run guix package -i guix
<alezost>Lillo: I think you never run "guix pull", that's why
<civodul>Lillo: the 'guix' package inside Guix is necessarily an older snapshot of Guix, hence this behavior
<civodul>efraim: that's the problem with libarchive on core-updates?
<alezost>ng0: this is not prohibited, users can run "guix package -i guix"
<ng0>notice the "should", not "must" :)
<efraim>I'm not sure if the problem is libarchive or cmake
<alezost>ng0: right :-)
<iyzsong>Lillo: you can try 'guix download' then continue.
<iyzsong>it's not on CPAN anymore, and most mirrors doesn't have it now... we should update the package.
<ng0>2.02 now
<ng0>no.. that one?
<ng0>I'll write an update shortly, if no one else is on it already.
<Lillo>iyzsong: guix download tje package but then it do not use it
<Lillo>it search the package where there is not
<efraim>i updated the mirrors a month ago or so after seeing lots of perl source failures on
<Lillo>and i have the same error
<alezost>rekado: re building a package that requires emms: I think the best would be to modify emacs-build-system to make it look in "share/emacs/site-lisp/" dir (currently it looks only in "share/emacs/site-lisp/guix.d/<package>")
<alezost>rekado: IIUC this can be done by adjusting 'emacs-inputs-el-directories' procedure from (guix build emacs-build-system)
<alezost>I hope Federico will not object against this modification
<iyzsong>Lillo: still for 'perl-uri'? I think it should build now.
<iyzsong>ng0: oh, thanks :-)
<ng0>how do test perl-uri? or is it enough that it succesfully builds?
<Lillo>it doesnt build :/
<ng0>Lillo: i update the package. what you want to pull, does not exist on mirrors anymore of cpan
<Lillo>but i cant do updates
<Lillo>im not on guixsd
<Lillo>i'm trying to install it
<Lillo>i'm using guix on debian testing
<ng0>however i have no push access, and I can't send emails at the moment, so it will be some more hours or me throwing it on my server and somebody fetches the update from there.
<Lillo>but when someone release the update what i have to do? i cant do updates
<ng0>tests succeeded, package built. i think i can risk to send emails while moving my system.
<ng0>guix pull. or chery pick it into git.
<Lillo>guix pull will install a lot of packages on my debian
<Lillo>i cant do it
<iyzsong>Lillo: it only cost some disk space, as all guix packages are in /gnu/store, they won't conflit with the debian host system.
<Lillo>it cost hours for compilation too lol
<Lillo>i'll guix pull
<iyzsong>Lillo: ok.. did you enable substitutes (by guix archive --authorize) from hydra? then you don't need to build most (if not all) things.
<kyamashita>I tried switching to a new guix tree clone, but I still can't commit any changes. :(
<Lillo>i don't remember lol
<civodul>kyamashita: why can't you commit?
<kyamashita>I don't know. I get an unpacker error when using the git protocol and permission denied with the SSH protocol.
<iyzsong>can fetch/clone use the SSH protocol?
<davexunit>iyzsong: no because it would require a key
<davexunit>at work, I have some packages that do authenticated clones of github repos via HTTPS basic auth
<davexunit>you encode the username/password in the repo URL and git will know what to do.
<iyzsong>ah, ok. kyamashita: did you mean commit or push?
<ng0>iyzsong: patch is out
<kyamashita>Oh, :P. I meant push.
<davexunit>I used a special github user that only has minimal read-only access to some repos.
<alezost>kyamashita: did you "tell" savannah your ssh key?
<Lillo>iyzsong, i did guix archive --authorize < ~root/.guix-profile/share/guix/ and now i dont need to compile useless packages
<Lillo>thank you
<iyzsong>Lillo: yep :-)
<kyamashita>alezost: Yes, and I checked yesterday that the keys on Savannah and my machine were the same.
<alezost>hm, do you use ""?
<ng0>another 9 GiB to copy :/ my regular reminder to use another backup system
<kyamashita>alezost: I don't think so.
<alezost>try it!
<alezost>btw what address did you try?
<kyamashita>alezost: Oh! I was using the anonymous addresses.
<kyamashita>alezost: Maybe this will solve the problem.
<alezost>I hope :-)
<bluehatmed>Hi all
<bluehatmed>I can not install guixsd VM qemu
<bluehatmed>someone give me the right instructions and thank you
<adfeno>bluehatmed: What does QEMU or GuixSD tell you?
<sneek>Welcome back adfeno, you have 1 message.
<sneek>adfeno, jlicht says: your quit message made me laugh :-)
<adfeno>sneek: tell jlicht Thanks! :D
<kyamashita>Yay! Push works now! Thanks alezost! :)
<sneek>jlicht, adfeno says: Thanks! :D
<alezost>kyamashita: yay! welcome to the "pushers family"
<alezost>rekado: I've sent the patch that should fix the problem you found (compiling emacs package that requires emms)
<bluehatmed>adfeno: I want to test the distribution gnu guix before installing it on my computer the problem given the instructions to install guixsd on virtual machine is always failed
<bluehatmed>I try installed on QEMU
<adfeno>bluehatmed: but what failled exactly?
<adfeno>Instructions, as you can easily read and notice, are made by several steps.
<ng0>bluehatmed: can you provide an error log?
<bluehatmed>1) qemu-img create -f qcow2 my_guix.cow 4G
<bluehatmed>2) qemu-system-x86_64 -enable-kvm -cpu host -net user -net nic,model=virtio -m 1G -hda my_guix.cow -hdb /home/bluehatmed/GuixSD/guixsd-usb-install-0.10.0.x86_64-linux -boot menu=on
<bluehatmed>No bootable device
<adfeno>Try passing GuixSD image as USB device for QEMU.
<adfeno>Let's see...
<davexunit>does our guile-next package bootstrap from source?
<iyzsong>does use '-hda' for the guixsd-usb disk works? that's the way I did it, iirc in the live the hard disk is hdb (the guix-usb is hda), so you should install the grub to '/dev/hdb'.
<davexunit>I have a suspicion that it might use the pre-built .go files in the tarball
<davexunit>but no time to investigate right now
<bluehatmed>okay my friends I will try again
<bluehatmed>adfeno: how to do?
<adfeno>bluehatmed: Trying to remember... :D
<bluehatmed>adfeno: ok :D
<civodul>davexunit: it bootstraps from source, the .go files are removed in a snippet
<adfeno>bluehatmed: Try setting this instead of hda and hdb...
<bluehatmed>adfeno: I followed this wiki
<ng0>imo everything outside of should be merged into manual at some point to make it more explanatory on different levels of understanding.
<adfeno>-drive "file=[Where the image is, if path needs comma, double it (",,").],index=[Starts from 0, I would put the "virtual" disk device here, not GuixSD USB image],media=[ Use "cdrom" for GuixSD USB, and "disk" for the "virtual" disk device]
<adfeno>" ← Don't forget to close with quotes.
<adfeno>For example...
<davexunit>civodul: oh cool, good to know.
<adfeno>-drive "file/home/adfeno/Test path,, now/Virtual disk device.qcow,index=0,media=disk" -drive "file/home/adfeno/Test path,, now/GuixSD USB image.img,index=1,media=cdrom"
<adfeno>And of course, blind me had to forget the equal sign after "file"... :S
<civodul>bluehatmed: in general it is best to follow the official manual, for instance
<adfeno>civodul and everybody else:
<bluehatmed>thank you all very much
<adfeno>I don't know if I'm really blind today or what, but during my attempt to browse the documentation...
<bluehatmed>big thank you ^^
<adfeno>... I couldn't find a reference to this page you just gave, from the first "installation"-related sections of the manual.
<civodul>adfeno: you may not be blind; it's true that the manual is lacking in some places, possibly including this one
<adfeno>bluehatmed: You're welcome.
<civodul>but it's still the place to look for doc, and to improve it too :-)
<adfeno>civodul: I was like: "Where in the world is that page about GuixSD on QEMU, I have seen it, but I can't find"... :D
<adfeno>Then, I tried looking int he first installation sections, but I couldn't find it.
<adfeno>Then I resorted to the official QEMU documentation.
<adfeno>Actually... I looked up in the installation-related sections of GuixSD manual, not in Guix's.
<adfeno>(and now I see that both use the same manual... Sorry)
<civodul>i go to the table of contents or the index when i'm lost :-)
***Kooda_ is now known as Kooda
<ng0>civodul: manual.. I think we should expand the tor-hidden-service service explanation to point out that hidden services can have subdomains.. it's a feature which is not so well documented maybe, just learned about it last week when someone I know moved pages and services under one onion and several subdomains of it.
<ng0>I try to find a section in the tor manual or documentation to point to
<ng0>well, http/https only.
<ng0>found it
<efraim>don't know that they need subdomains, if i understand it correctly you could have each service with its own address
<ng0>not need, can have
<ng0>you can have one onion address per service or, only with http/https you can have one onion address and different subdomains
<ng0>live example: .. one moment
<ng0>the v2 page of http://secushare.cheettyiapsyciew.onion/ which also lists other subdomain onions
<ng0>well and git
<ng0>looking at out manual, we could add just a link to this finished proposal, pointing out that this is possible as well. I'll do it, maybe today, maybe some time this week or later
<ng0>I hope someone at some point uses lispf4 and complaints about it being broken.. so someone more competent than myself, at this point in the languages it is written in, fixes lispf4 on guix.
<ng0>but maybe it's easier to debug than I think, but it's still no high priority for me.. author of the software never came back to me, contrary to what they said.
***roptat_ is now known as roptat
<ng0>hm... mediafiles, with mpv under gnome de started to quit after more than 60 minutes.. appears only with .mp4 so far.
<ng0>np apparent reasons, the files are okay
<ng0>also webm
<kyamashita>ng0: Only under GNOME?
<ng0>i just run gnome, that's all
<kyamashita>Ah. Skipping past 60 minutes doesn't work either?
<ng0>that's why i said "files are okay"
<ng0>they are not damaged
<ng0>ie i can scroll through without glitches, but watching and occasionally, supposedly time related, they just quit
<ng0>a usual star trek original series episode is alright
<ng0>so maybe there's bitrot in many files I can't see yet.. but it's happening too often
<ng0>under gentoo, not a week ago, they were alright
<ng0>i'll start this one charly chaplin movie again, this time from the terminal with verbose output to see what's the reason
<efraim>that's an unusual bug
<ng0>this mp4 file: h264,aac,yuv402p
<ng0>machine uptime shouln't be a reason for quitting.
<ng0>up 4 days 6:55, 0 users, load average: 1.06, 0.45, 0.27
<ng0>swap and ram are bored to death.
<ng0>mpv version 0.17.0 there was no update in the last days I guess?
<efraim>checked about an hour ago
<kyamashita>I have the same version, but I haven't had issues with videos >60 minutes.
<ng0>it's a first for me too
<ng0>so.. no idea
<kyamashita>Granted I only really have webms to test on.
<ng0>give it some time and i can get you output
<ng0>happens with webm too.
<ng0>made no sense to move everything to webm yet as i had not found a good way to batch transcode webm+vp9
<kyamashita>I'll also play a ~65 minute webm that I have in the background and see what output I get.
<ng0>i've been copying backups for 2+ days now.. different harddrive target though
<mark_weaver>ng0: I also use mpv on GuixSD, and have watched movies > 60 minutes with in recently. never had any issues with it
<mark_weaver>I'm on i686 (32-bit), though
<ng0>yeah i have watched longer movies before too
<efraim>mpv seems to get rebuilt fairly often, the only big change I can think of is vapoursynth's upgrade
<ng0>so idk what this is.. failing harddrive.. who knows
<ng0>integrity is okay with fsck at least
<mark_weaver>I/O errors would be logged by the kernel into one of the log files, I think
<mark_weaver>can you reproduce the problem on a particular file?
<kyamashita>mark_weaver: Probably dmesg logs.
<mark_weaver>ng0: can you reproduce the problem, maybe on a particular file?
<ng0>i'm trying this right now and send the log.. i can't publish the file though
<ng0>or look at the log
<ng0>in dmesg/kernel log nothing came up
<ng0>totem gives those, but i don't use totem for its bad performance here:
<ng0>Jun 20 15:47:02 localhost vmunix: [366628.781128] .totem-video-th[11402]: segfault at
<ng0> 40 ip 0000000000404812 sp 00007ffe47be76e0 error 4 in .totem-video-thumbnailer-real[
<mark_weaver>it might be that some of your files have errors that cause the video decoder to crash
<ng0>and for that i would consider failing harddrive the reason.. have to replace it soon, but i haven't had the money to spent yet
<mark_weaver>I don't think a failing hard drive would cause these problems.
<mark_weaver>hard drive problems should be reflected as I/O errors reported by the kernel, and probably not by segfaults in video thumbnailers.
<mark_weaver>you might test your RAM, though
<ng0>that's a possibility.. i'll let a check run once I am able to shutdown
<ng0>dropped 5 frames so far.
<ng0>that's not unusal
<ng0>there's also this which i am aware of for a long time but did not bother to apply here.
<ng0>when it's not in full screen mpv suceeds in playing longer
<kyamashita>ng0: So you think mpv might be autoprobing and selecting the wrong OpenGL backend?
<ng0>around ~40 minutes the problem was
<ng0>i have messages like this: [vo/opengl] Could not create EGL context! for a very long time and ignored them equally long, way before guixsd.
<ng0>it was never a real problem
<kyamashita>I get a "Could not create EGL context!" error, too, but my computer settles on the X11 OpenGL backend.
<kyamashita>So I never thought of it as a problem.
<ng0>a very minor amount of frames gets dropped with this video.. 9 in 43:07 minutes
<ng0>but this isn't a problem eiuther
<mark_weaver>ng0: fwiw, I almost always use mpv in full screen mode
<ng0>me too
<ng0>i'll look into ram and this horribly old graphics card
<ng0>fullscreen this video: went from dropped 10 to dropped 67 in no time
<ng0>ACTION afk
<paroneayea>I was interested in playing with Python
<paroneayea>with a specific library
<paroneayea>but it looks like our python (python-3.4) is not new enough, needs 3.5
<paroneayea>I guess I should package Python 3.5.
<efraim>3.5.2 is (almost?) out
<paroneayea>efraim: heh, guess it's definitely time to get the 3.5.x series in then :)
<lfam>Yes, we should work on that
<davexunit>hopefully it's a simple update, but python updates have seemed difficult in the past
<lfam>detrout was working on it for a while, so I don't think it's simple :(
<lfam>Her work is on guix-devel
<efraim>i should make sure python2 still builds on core-updates
<paroneayea>ok I'll take a look.
<lfam>paroneayea: Search for "Python 3.5 start of update"
<paroneayea>lfam: yeah already have it up :)
<lfam>Hopefully it's ready to merge as quickly ;)
<davexunit>having this weird situation where the guix daemon that I provision on new ubuntu VMs crash the first time a client attempts to connect
<davexunit>it works after restarting the daemon
<efraim>texlive-minimal-2016 built fine, now to try out texlive-2016 and some sample programs
<lfam>Does anything get printed on the console? Or could you strace it?
<lfam>davexunit ^
<mark_weaver>or run it in gdb and get a backtrace
<davexunit>I am having trouble finding the logs
<davexunit>I can't run it in gdb because it's not reproducible after the initial issue
<davexunit>guix-daemon doesn't have an option for specifying the log file
<lfam>Doesn't ubuntu use systemd / journald?
<davexunit>and I don't know where the init system is piping stdout
<davexunit>lfam: it does now, but I'm using 14.04 which does not
<davexunit>yeah, but it also works with sysvinit style init scripts
<davexunit>which I am using
<lfam>I have no idea how that system works
<davexunit>no such file
<davexunit>I need to find the logs, if there are any. maybe there's nothing.
<mark_weaver>davexunit: I think guix-daemon just writes to stdout and/or stderr
<davexunit>seems right.
<davexunit>now to find where pid 1 is piping this output
<efraim>oops, forgot to run guix gc before starting texlive, down to like 2GB in /gnu
<mark_weaver>davexunit: it might just be going to the console, or to nowhere. you might need to arrange to redirect stdout/stderr when launching guix-daemon, dunno.
<mark_weaver>davexunit: maybe there's a missing dependency in the init system, and guix-daemon is getting launched too early?
<davexunit>mark_weaver: that could be.
<davexunit>hopefully I will figure out how to see the logs and then I might know a bit more
<lfam>davexunit: They aren't in /var/log/upstart? My web search suggested that answer
<mark_weaver>keep in mind that guix-daemon doesn't output much. iirc, it might not even print anything until a client connects to it
<davexunit>yeah, I'm not getting any logs even when I connect
<davexunit>so my attempts to redirect output aren't working
<mark_weaver>ah, okay
<davexunit>it's weird. if I restart the daemon via the init system, the daemon logs to my terminal
<davexunit>rather than the file I tried to redirect output to
<mark_weaver>how are you doing the redirection?
<davexunit>the wrong way, apparently. I tried: guix-daemon & > /var/log/guix 2>&1
<mark_weaver>the '&' needs to go after the redirections
<davexunit>thank you
<davexunit>now I can log
<mark_weaver>that's good!
<davexunit>now I'm going to rebuild the VM from scratch and see if the problem shows itself again
<davexunit>I always get confused with order of operations when combining some of these bash operators
<mark_weaver>'&' is actually a statement terminator, like ';', iirc
<davexunit>ah I see
<lfam>Yes, also analogous to && and ||
<mark_weaver>but yeah, bourne shell is quite a complex beast.
<mark_weaver>and something I wish I didn't need to know
<lfam>Send good vibes to efraim :)
<mark_weaver>heh, yeah :)
<mark_weaver>maybe some day we'll have a good shell replacement in guile
<davexunit>mark_weaver: thanks for all the help
<davexunit>hopefully one step closer to using guix on some production servers ;)
<davexunit>I'll soon enough have a Chef cookbook to release that might help other people try out Guix in their own odd hybrid environment. :)
<davexunit>"add support for all of Hackage"
<Steap>yeah, that is really nice
<Steap>I'd like to do that with Python, but we cant always extract the dependencies...
<davexunit>mark_weaver: initial daemon startup problem resolved!
<davexunit>seems like it was an IO issue that was killing it.
<mark_weaver>davexunit: huh. how did you resolve it?
<davexunit>mark_weaver: redirecting the output to a file, oddly enough.
<mark_weaver>ah, nice :)
<davexunit>I think it has something to do with what I saw in the process tree
<davexunit>some processes say they are running in pts/0
<davexunit>whereas the daemon says "?"
<paroneayea>Yay, Python 3.4.4 was a cinch to update
<paroneayea>next up, Python 3.5.
<davexunit>mark_weaver: if I restart the daemon manually, the process is then run under pts/0 and the problem doesn't show itself
<lfam>Does anyone want to extol the benefits of Guix vs Travis?
<lfam>Not that they are the same thing, but I wonder how much Guix could help them.
<lfam>I have never used Travis so I'm not the person to have the conversation
<davexunit>lfam: I'd just leave that one be
<davexunit>since Guix isn't a full CI system.
<davexunit>with the Hydra replacement, then we'll be talking.
<lfam>bzip2 bug: <>. Red Hat isn't going to fix it
<davexunit>ACTION thinks that 'guix environment' could probably use an option to preserve user-defined environment variables in the new environment
<utbrs>can u explain what's guix and can i use it on gentu?
<davexunit>does anyone remember what the last bright idea I had for 'guix environment' was? happened last week I think and everyone chimed in and was like "yeah that would be great"
<davexunit>but then I forgot :(
<davexunit>utbrs: guix is a package manager, and yes you can use it on gentoo as well as any other GNU/Linux distro.
<utbrs>do you mean i can install binaries instead of compiling them the gentu way?
<davexunit>utbrs: it's a completely separate package management system. you can install pre-built binaries or build from source with guix.
<utbrs>if i installed it should i remove portage?
<davexunit>you should never remove your distro's package manager
<utbrs>will portage know about packs installed via guix?
<davexunit>they are completely separate
<utbrs>what for is guix-deamon do i need it?
<davexunit>guix-daemon builds software on behalf of users
<davexunit>it runs as root and allows unprivileged users to build and install softwarew
<utbrs>you mean that non-deamon builds as root? and deamon as a suer?
<davexunit>you must use the daemon.
<davexunit>guix doesn't work without it.
<utbrs>i could not find blz2 pack on portage
<utbrs>and g++
<mark_weaver>utbrs: the builds are done as unprivileged users, but the parent process of the daemon itself needs to be root to set up the isolated build environment
<davexunit>utbrs: g++ is the GNU C++ compiler and it comes with gcc
<mark_weaver>utbrs: for g++, install the 'gcc-toolchain' package
<davexunit>portage probably doesn't have a package with that name, but it is surely in one of the packages
<utbrs>and what about blz2?
<davexunit>I don't know what that program is
<utbrs>no toolchain in portage but i think i should have it as part as gcc
<davexunit>package names are often different between distros
<utbrs>i have that and why do linuxes still use torvald's kernel if there is libre kernel?
<davexunit>I'm feeling a little fatigued by all of these questions.
<thomasd>Hi #guix,
<cehteh>i am pretty upset by people taking away other peoples freedom of choice because they thing they know what kind of free software is the best for someone else
<utbrs>gentu is captured i think
<utbrs>they promote building kernel from root
<utbrs>and patch kernels from
<Sleep_Walker>cehteh: yes, that is the most upsetting behaviour I have seen
<sneek>I'll keep that in mind.
<mark_weaver>cehteh: what specifically are you referring to? who's taking away other people's freedom of choice?
<Sleep_Walker>cehteh: sometimes I face it in openSUSE community - the most significant example was transition to systemd
<cehteh>just generally, thinking about the mame discussion some months ago, but also debian choice of making it rather hard to get rid of systemd, or gnomes choices to hide a lot customization because of simplicity
<utbrs>there is no freedem
<Sleep_Walker>cehteh: heh, yes, exactly
<cehteh>people should have the right to shoot into their own feet, even if it hurts
<mark_weaver>cehteh: in the examples you give, I don't think those are cases of taking away other people's freedom of choice.
<cehteh>yes you can always argument that way because you can tell then "build your own version" or "dont use ours then" ...
<mark_weaver>we, the developers of guix, have chosen to include only free software in our distro. you don't have to use our distro if you don't want to, and you can also modify it to do what you want.
<utbrs>are you all zionists?
<cehteh>but i feel thats not encouraging freedom, its only a lame excuse
<civodul>utbrs: this kind of question is off-topic
<utbrs>then there is no freedom
<mark_weaver>there's some vague fuzzy thinking going on here
<Sleep_Walker>time to code again
<lfam>Does anyone know a simple Go program that I can use to test the go 1.4 package on guix-devel?
<cehteh>mark_weaver: yes thats ok, but not including things like 'mame' because it could potentiall run non free software would be false
<lfam>Ideally something without any dependencies...
<mark_weaver>cehteh: well, as I recall, the result of that discussion is that we should allow mame to be included
<lfam>Checking, I'm surprised that it is not.
<mark_weaver>but I vaguely recall that there were trademark issues that needed to be patched around
<cehteh>yes i am only giving an example about that this discussion upset me because it even happend.. there should be no doubt about including mame in the first place
<utbrs>do i need to change torvald's kernel by linre kernel to use packs from guix?
<cehteh>linux kvm could run non free OS'es .. hey i can even publish a shell script with a no free license .. would you remove bash then, even consider thaT?
<cehteh>that train of thought to start with is wrong already
<mark_weaver>cehteh: somewhat brought it up and made an argument. not a guix developer. it happens.
<mark_weaver>but more to the point, I think it's wrong to claim that we, the guix developers, are "taking away other peoples freedom"
<civodul>lfam: Docker? :-)
<cehteh>i didnt made that claim
<cehteh>guix works well so far, but you have to keep that into mind for future as well
<utbrs>your name is ludovik?
<civodul>lfam: more seriously:
<civodul>a pretty handy program
<cehteh>its more about some 'users' dont get the idea that free software was created to ensure peoples freedon, not per se to make the software free or as some religoious group
<utbrs>you can be from mossad
<mark_weaver>cehteh: well, you complained about "people taking away other peoples freedom of choice", and when I asked for an example, you brought up the mame thing.
<mark_weaver>cehteh: do you have an example of "people taking away other peoples freedom of choice" that's along these lines?
<cehteh>yes but that discussion was not initiated by a guix devel or?
<lfam>civodul: Looks promising
<utbrs>i will ask my friends about your project
<lfam>Looks like it needs go-nat-pmp, but if _that_ can build without any more dependencies, that's okay
<civodul>lfam: somehow i thought Go was already in
<civodul>so i'm glad you're looking at it
<lfam>civodul: I believe you were the last to reply to that thread ;)
<civodul>ah, good!
<civodul>i tend to get lost in the maze of patches :-)
<cehteh>mark_weaver: i was merely responding to utbrs, as in 'even if guix has (valid) reasons to use the linux libre channel, there are reasons for a lot of people to use linus tree (even if it contains non free bits by some definition)'
<lfam>The next step will be a go-build-system
<civodul>that would be awesome
<civodul>it seems that building Go programs it pretty easy
<utbrs>i don't care for tracking maybe will use some binaries
<mark_weaver>cehteh: okay, we can let this drop :)
<utbrs>they have sent me the video of my penis
<utbrs>so now i don't care
<mark_weaver>utbrs: please refrain from such comments here
<lfam>Thank you
<mark_weaver>ACTION was close to doing it, but he'd have had to remember how :)
<civodul>heh :-)
<cehteh>ACTION winks with the censoring and free speech flag :D
<cehteh>j/k ...
<civodul>ACTION finally has a test of the installation procedure \\o/
<civodul>initially i thought i'd be "an easy way" to test the fix for
<civodul>*it'd be
<davexunit>civodul: that's really cool
<davexunit>I've been wanting to expand the automated system tests to include GuixSD containers
<lfam>In other "finally" news, I sent a patch to Pjotr last night that should makes Erlang pass --check on my machine. And the latest release of Erlang made the Erlang compiler create its ouput reproducibly. So, soon :)
<lfam>I mean, it does make Erlang pass --check on my machine.
<quiliro>i am back again
<civodul>lfam: that's good news, thanks for taking the time!
<civodul>¡hola quiliro!
<quiliro>my machine with guix expired a month ago
<quiliro>civodul: hello
<quiliro>i am installing guix in my son's machine now
<quiliro>civodul: como estas?
<quiliro>i have an error
<quiliro>at installing guixsd
<quiliro>wicd failed
<lfam>quiliro: How did it fail? What did the error message say?
<quiliro>guix system: error: build failed: some substitutes for the outputs of derivation '/gnu/store/.............. wicd-1.7.3.tar.gz' failed
<quiliro>(usually happens due to networking issues); try '--fallback' to build derivation from source
<quiliro>lfam: ^
<lfam>quiliro: Did you try running the command again with --fallback?
<quiliro>lfam: will that build everything from source
<lfam>quiliro: It will only build from source if it can't find the binary substitute
<lfam>So, no
<quiliro>oh cool
<quiliro>lfam: thanks
<lfam>Does anyone know if we still have the substitutes from 0.10.0?
<quiliro>lfam: it is working perfectly...i thought that would compile everything
<lfam>quiliro: To compile everything, you would use --no-substitutes
<quiliro>i am going to study....sorry for my lazyness
<quiliro>i should have reread the docs
<lfam>No problem :)
<civodul>lfam: i don't know for sure, but hopefully yes
<civodul>though i think with our current hydra setup we don't have this guarantee
<ng0>what is gentu
<lfam>I think it's how you spell gentu if you are crazy
<ng0>someone wrote about it.. should've pointed to my guix ebuild
<lfam>Guess I'm going crazy too
<ng0>oh, kicked
<ng0>i see
<ng0>i did not read that much, otherwise i wouldn't have commented on it with what I've read now afterwards :D