IRC channel logs


back to list of logs

<myglc2>I think I just observed that one can rearrange a .scm file to make it prettier (e.g., comments or order) and that such a change does not cause the package to be rebuilt. Am I hallucinating, or is this how it works? TIA
<mark_weaver>myglc2: it's how it works.
<myglc2>That is seriously sick!
<mark_weaver>some things matter, some things don't.
<myglc2>In a good way
<mark_weaver>there's a procedure that takes a package definition and creates a "derivation" out of it. that's the .drv file. the .drv file is the only thing the guix-daemon sees when asked to build it. if the .drv file doesn't change, then the package doesn't need to be rebuilt.
<myglc2>That is so cool. How do I propose an enhancement patch for an existing .scm?
<mark_weaver>myglc2: have you built guix from a git checkout?
<mark_weaver>do you know how to use git?
<mark_weaver>okay, so commit the proposed changes in your local git repo with a commit log that conforms to our conventions (see the log for examples), and then send the patch to is the format produced by "git format-patch -1"
<mark_weaver>you can also use git send-email if you prefer
<mark_weaver>but basically we want it in a form that we can apply with "git am"
<mark_weaver>myglc2: see the "Contributing" section of the Guix manual.
<myglc2>OK great, thanks.
<paroneayea>I switched my mail over from fetchmail -> fdm
<paroneayea>now that's one step closer to full time guixsd!
<paroneayea>I can read/write mail :)
<pizzaiolo>anyone seen this?
<paroneayea>oh! oh!!!!
<paroneayea>mark_weaver: looks like pulseaudio is working just fine
<paroneayea>rhythmbox isn't :)
<paroneayea>which is less worrying to me :)
<paroneayea>Rhythmbox-Message: Missing plugin: gstreamer|1.0|.rhythmbox-real|MPEG-1 Layer 3 (MP3) decoder|decoder-audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, parsed=(boolean)true
<paroneayea>Rhythmbox-Message: Automatic missing codec installation not supported (helper script missing)
<paroneayea>that's probably it...
<GChriss>paroneayea: gst-libav provides some of those codecs
<GChriss>not sure about mp3
<mark_weaver>paroneayea: you need gst-plugins-ugly
<mark_weaver>paroneayea: and you need GST_PLUGIN_PATH="$HOME/.guix-profile/lib/gstreamer-1.0"
<paroneayea>mark_weaver: ho ho, that fixed it
<paroneayea>\\o/ \\o/
<paroneayea>btw, does anyone else find that M-! and all sorts of other commands give
<paroneayea>shell-command-on-region: Searching for program: no such file or directory, /bin/bash
<paroneayea>in emacs on guixsd
<paroneayea>is there a workaround?
<paroneayea>M-x grep and all sorts of other things also break
<mark_weaver>paroneayea: works for me. maybe because I have the SHELL environment variable set?
<mark_weaver>I'm actually not sure how it's getting set, but it is for me.
<mark_weaver>maybe it's coming from the shell field of my user entry in /etc/paswd ?
<paroneayea>mark_weaver: yes maybe SHELL affects things...
<paroneayea>hm, but $SHELL seems here
<paroneayea>set here
<paroneayea>and /etc/passwd points to a reasonable /bin/bash
<paroneayea>oh hm
<paroneayea>a fresh emacs is fine
<paroneayea>it must be something in my config...
<paroneayea>yep, that's it
<paroneayea>why on earth did I have this set:
<paroneayea>(setq shell-file-name "/bin/bash")
<paroneayea>(setq explicit-shell-file-name "/bin/bash")
<paroneayea>so much bs in my emacs config, I don't even know where it all comes from anymore
<mark_weaver>heh :)
<kristofer>in gnu/services/xorg.scm where is xf86-input-libinput defined?
<kristofer>nevermind, found it
<mark_weaver>kristofer: both "guix package -s" and "guix package -A" will tell you the file and line number.
<mark_weaver>and there's also "guix edit"
<suitsmeveryfine>kristofer: what's your aim with upgrading input-libinput?
<kristofer>I'd like to be able to scroll using 2 fingers on the touchpad
<suitsmeveryfine>the fact that you can't do it right now is that due to the packafe?
<suitsmeveryfine>sorry, "the current package version" I wanted to say
<kristofer>suitsmeveryfine: my dilema currently is that the xorg-server package is still using the original 0.8.0 version of libinput, instead of 1.1.5
<kristofer>guix package -i xorg-server matches a binary on hydra, so it doesn't appear to update the symlink to the libinput module
<suitsmeveryfine>I see, but is 0.8.0 a very old version?
<mark_weaver>kristofer: the xorg-server package doesn't hold any references to xf86-input-libinput, so it need not be rebuilt.
<mark_weaver>kristofer: only the xorg configuration needs to be updated
<kristofer>from what I can tell, xorg-configuration-file should use the version of xf86-input-libinput that I have specified in the package definition
<kristofer>I can't figure out why it doesn't
<mark_weaver>it will, when you run "./pre-inst-env guix system reconfigure" in a guix source tree where you've updated the xf86-input-libinput package
<kristofer>that's what I've been trying to get to the bottom of.. it will require a system reconfigure
<lfam>mark_weaver: I'm continuing to work on the python-3 bytecode timestamp issue from a couple days ago. The more I think about it, the more I think that patching Python to make all the bytecode have a "epochal" timestamp is the wrong thing to do. And I think that making the Python build system set the timestamps of unpacked Python source code the right thing. My question is, is there a danger to discarding upstream's timestamps like that?
<lfam>In general, do upstream projects ever use the timestamps of source files when building in a way that would break stuff if we reset the timestamps?
<lfam>I plan to say this in the bug thread but I wanted to get a "sanity check" before I write the email
<kristofer>do I need to run guix system reconfigure as root?
<lfam>kristofer: yes
<davexunit>kristofer: yes, because it alters the whole system.
<lfam>davexunit: What do you think about my question re: resetting timestamps of Python source code as we unpack it?
<kristofer>I thought so! thanks everyone for your attention
<lfam>Or anybody else who knows more about Python than I do (that's not a lot ;) )
<davexunit>lfam: fixing it in the build system sounds reasonable
<lfam>If the Python interpreters we package always set the internal bytecode timestamp to "1", then that bytecode is NEVER used because it is always stale.
<lfam>Except within the Guix package tree
<lfam>And we already do this for Python 2
<mark_weaver>lfam: for now, I would adopt the same approach we already did for python 2, to make it deterministic without additional delays.
<mark_weaver>and then we can look at whether there's a nicer approach
<mark_weaver>in our case, recording the timestamps of the corresponding source files is not very useful, because in many cases those timestamps will be Jan 1 1970 anyway.
<mark_weaver>we should rather have easy ways to find the corresponding source from a given output directory
<lfam>Yes, it works against other Guix packages, but not for anybody that might be using our Python interpreters to do Python development, or to run Python software that is NOT provided by Guix
<mark_weaver>okay, fair point :)
<lfam>IMO our Python 2 package is very slightly broken because of this. I'll send an email to the bug thread
<mark_weaver>but actually, if that special environment variable isn't set, it still records the timestamp, right?
<lfam>Oh true
<mark_weaver>so actually I think it's fine
<lfam>Yes, you're right
<lfam>In that case, we'd want the python-build-system to set that environment variable automatically, right?
<lfam>Oh, it's in gnu-build-system, and I assume inherited by python-build-system.
<lfam>Hmph, my patch didn't have the desired effect.
<Jookia>Can we delete all the svn repos in Guix
<Jookia>and ftp repos
<Jookia>Well, not ftp repos per-se- ftp links are able to be mirrored
<Jookia>But svn repos aren't able to be
<lfam>If you want to hunt down new sources for everything and send the patches, I don't see why not. But why?
<Jookia>lfam: SVN is impossible to use over Tor
<mark_weaver>Jookia: one advantage of ftp sources is that they can be easily scanned for newer versions, because the directory listings are standardized and easily machine readable.
<mark_weaver>ftp can be used over Tor, no?
<Jookia>Ftp can, though often the servers block Tor connections
<Jookia>But mirroring ftp files is fine and guix download worksaround that
<Jookia>If you go to the GNU ftp server with Tor, your connection will be rejected
<paroneayea>ACTION staring at build-system/python.scm
<paroneayea>I don't see where it uses setuptools / etc, which is what I expected
<mark_weaver>Jookia: the plan is to distribute substitutes over Gnunet, and that would include the sources as well.
<mark_weaver>of course, we should try to convince the upstreams to allow Tor connections. I'm surprised that GNU's ftp site would block Tor. I doubt that was the intent; it's more likely that some exit relays are getting automatically blacklisted for some time because of attempts to break in from those IP addresses.
<mark_weaver>if they really are blocking Tor, I could talk to RMS about it. I'm sure he would be against blocking Tor.
<pizzaiolo>I asked for guixSD to download icecat and for some reason it's installing a whole bunch of unrelated stuff, like binutils and linux-libre
<pizzaiolo>is this normal?
<pizzaiolo>this is my first time installing a package btw
<paroneayea>I'm seeing now
<paroneayea>ACTION confused by build/python-build-system.scm
<paroneayea>confusing naming! :)
<mark_weaver>pizzaiolo: did you run "guix pull" ?
<lfam>paroneayea: Yes it is
<pizzaiolo>mark_weaver: I did not
<pizzaiolo>I did guix package -i icecat
<mark_weaver>pizzaiolo: you should, otherwise you will get old versions of everything, with security holes.
<mark_weaver>first run "guix pull"
<pizzaiolo>ok, but why is it downloading unrelated things?
<pizzaiolo>it's fetching gcc now
<mark_weaver>pizzaiolo: probably because the old icecat you are asking to download is no longer on the substitute server, so you will need to build it from source code.
<pizzaiolo>oh so I'm compiling it?
<mark_weaver>if you scroll up, it should tell you what it plans to build and what it plans to download.
<mark_weaver>just Ctrl-C
<mark_weaver>then "guix pull", and then try again
<pizzaiolo>mark_weaver: ERROR: In procedure getaddrinfo: Name or service not known
<mark_weaver>sounds like you don't have a working network connection
<mark_weaver>or there was a transient DNS lookup error
<pizzaiolo>but I was downloading a bunch of packages just now
<mark_weaver>this used to happen a lot more in 0.9.0, but somewhere since then it seems to have gotten a lot better.
<mark_weaver>but if you never ran "guix pull" then you have very old software now.
<mark_weaver>well, "very old" by our standards, anyway :)
<pizzaiolo>sure but that means I have a connection, no?
<mark_weaver>hence my later statement "or there was a transient DNS lookup error"
<mark_weaver>which might have been cached. this happened a fair bit in the past, but seems to have gotten a lot better since 0.9.0 was released. I guess civodul did something to improve it.
<mark_weaver>can you try it again?
<mark_weaver>if you're looking for a polished distro with no rough edges, you've come to the wrong place.
<mark_weaver>heh :)
<paroneayea>that should be the /topic ;)
<mark_weaver>lol :)
<pizzaiolo>mark_weaver: disconnecting and reconnecting did the trick
<mark_weaver>cool :)
<pizzaiolo>by the way thanks for the ever-present help :)
<pizzaiolo>It's much appreciated
<mark_weaver>np :)
<calher>Editing my config.scm.
<pizzaiolo>what's that command to upgrade the system?
<pizzaiolo>guix system reconfigure?
<mark_weaver>pizzaiolo: yes, run as root. make sure to either run "guix pull" as root also (in addition to your user account), or make ~root/.config/guix/latest a symlink pointing at ~USER/.config/guix/latest, where USER is the user you normally run "guix pull" as.
<pizzaiolo>oh, that's a tad confusing
<pizzaiolo>I ran guix pull as nonroot
<pizzaiolo>is that a problem?
<mark_weaver>yes, I know, that's why I mentioned it.
<mark_weaver>no, normally you run "guix pull" as your normal user, and most guix commands.
<pizzaiolo>ok cool
<mark_weaver>but each user can have their own copy of guix, and their own version of the guix recipes.
<pizzaiolo>I tried running guix system reconfigure without root and it said wrong number of arguments
<mark_weaver>which is a good thing, but remember that it also applies to root.
<pizzaiolo>doesn't that mean that something is missing from the command?
<mark_weaver>pizzaiolo: you need to name your OS configuration as the last argument.
<pizzaiolo>oh ok
<pizzaiolo>config.scm right?
<mark_weaver>I'd happy to help, but it would be good if you could read the docs more and ask fewer questions that can be easily answered on your own.
<mark_weaver>our manual goes over all of this
<lfam>Is there such a thing as a python debugger, where you can set a stopping point in the code and get a python shell?
<lfam>There are some good jokes in the manual
<calher>How do I add NTP support to config.scm? I can't read "ntp-service [#:ntp ntp][#:name-service
<paroneayea>if I wanted to package a specifically python2 application
<paroneayea>I wonder if I'll run into trouble
<paroneayea>because the PYTHONPATH will be for py2, not py3
<lfam>We have some python-2 only stuff
<lfam>I haven't had any problems with them yet
<paroneayea>lfam: hm, things with a cli too? maybe could you point me to some names of packages?
<paroneayea>ACTION is trying to package "assword", a package manager
<mark_weaver>calher: for most purposes (ntp-service) is sensible.
<lfam>paroneayea: letsencrypt, transmission-remote-cli
<paroneayea>lfam: aha, thanks
<lfam>Well, transmission-remote-cli has an ncurses interface, not exactly cli
<paroneayea>well, close enough
<paroneayea>something with an executable :)
<lfam>letsencrypt has both
<paroneayea>okay, nice, got one dependency for assword installed and working it seems
<mark_weaver>that's a great name :)
<paroneayea>also a great program!
<paroneayea>it could use some features but in general works quite nice
<calher>So how would I add (ntp-service) to <>?
<calher>I mean <>
<mark_weaver>calher: put it in the same list as (dhcp-client-service)
<mark_weaver>but %base-services needs to stay at the end
<calher>I don't have that.
<mark_weaver>I just downloaded the link you gave, and it was there
<mark_weaver>%base-services is a list of services. (cons* a b c d e <old-list>) returns a new list that has <old-list> with a b c d e added to the front.
<mark_weaver>for example, (cons* 1 2 3 4 '(5 6 7 8 9)) => (1 2 3 4 5 6 7 8 9)
<mark_weaver>in this case, it is a list of services.
<mark_weaver>calher: looks good
<calher>OK, committing.
<calher>Committed revision 10.
<calher>"Revision 10." I love Bazaar.
<calher>Pushed up to revision 10.
<calher>mark_weaver, what about wicd-service?
<calher>I want to connect to WiFi without doing "ifconfig wlp2s0 up; iwconfig wlp2s0 essid 'Daisy Bell'; dhclient wlp2s0" all the time.
<myglc2>Trying to (require 'magit) I get Debugger entered--Lisp error:
<myglc2>(file-error "Cannot open load file" "no such file or directory" "dash")
<myglc2>Do I have to install dash or something?
<myglc2>I use magit all the time, but just setting it up on guixSD
<myglc2>... from a recent guix git pull
<mark_weaver>calher: add (wicd-service) to services, and wicd to your system-wide packages, and add 'netdev' to the supplementary-groups of your normal user.
<mark_weaver>myglc2: after installing 'magit' in your user profile, magit.{el,elc} will be in ~/.guix-profile/share/emacs/site-lisp. is that in your load-path ?
<myglc2>I don't have a ~/.guix-profile/...
<myglc2>This is on a new user account freshly created by reconfigure
<myglc2>I can just manually fix it,
<myglc2>but I would like to understand why it was not automatically created.
<mark_weaver>myglc2: it doesn't exist until you install something in that user profile for the first time.
<mark_weaver>if emacs and magit are in your system-wide packages, then /run/current-system/share/emacs/site-lisp is where magit.el will be.
<myglc2>OK, thanks.
<mark_weaver>sorry, I meant /run/current-system/profile/share/emacs/site-lisp
<myglc2>No worries, that's what I thought you meant. Unfortunately with that added to my loadpath I still get (file-error "Cannot open load file" "no such file or directory"
<mark_weaver>some emacs packages might add things to a subdirectory. I haven't looked at dash.
<mark_weaver>there's some autoload system to handle these things, but I don't know the details.
<mark_weaver>alezost would know
<mark_weaver>and probably also civodul
<mark_weaver>but I guess the autoloads only work for packages that were installed when you launched emacs.
<mark_weaver>and I don't know how they handle packages installed in the system-wide profile
<myglc2>I guess I was hoping that if, in guixSD, I installed emacs git and magit anything else required would be pulled in automatically
<mark_weaver>most of us prefer to put most things in our user profile, and that's the most well handled case.
<myglc2>So by profile you mean use git package -I to get the things you want
<myglc2>Sorry I mean guix package -i
<mark_weaver>ah yes, I forgot that dash is needed by magit now.
<mark_weaver>sorry, I have to go afk. maybe ask on the ML.
<mark_weaver>or ask alezost or civodul
<myglc2>No prob, thanks. I think the INFO pages imply that this should work so I'll raise it on the user list
<myglc2>... and switch to installing as a user
<calher>mark_weaver, pushing.
<Jookia>Is there a way to get Guix's initrd to printk
<mark_weaver>Jookia: I don't know about printk, but it can print things to the console.
<mark_weaver>the relevant code is in gnu/build/linux-boot.scm, and you can see calls to 'display' and 'format' in there that print messages to the console.
<Jookia>mark_weaver: I have gotten EHCI to work with Linux but I'm still unsure why it's not booting- all I have is the kernel log, not a tty
<mark_weaver>Jookia: is the EHCI available as a terminal device that can be written to like a tty?
<Jookia>mark_weaver: Perhaps- I'll have to mess around in Debian for a bit to see if it's able to do that
<mark_weaver>Jookia: linux supports a "console=" command-line argument that can be used to put the console on a serial port, and that should be what Guix's initrd writes to as well, I guess.
<Jookia>Ooh, I forgot about that!
<calher>Would this work, or do I need to add a Tor user?
<mark_weaver>Jookia: if you have a USB-serial adapter supported by Linux, it looks like console=ttyUSB0 is supported as well.
<mark_weaver>I have to go afk, happy hacking!
<kristofer>I made a package definition for nmap!
<lfam>kristofer: Nice :) I have a WIP but working one too. Care to share notes?
<Jookia>calher: Try it and find out :)
<calher>Jookia, that's scary.
<Jookia>Why is that scary
<calher>Jookia, if it fails it's scary because my sys won't work
<Jookia>calher: you can't roll back?
<calher>Jookia, no.
<calher>I don't think so.
<Jookia>calher: Is your GRUB broken?
<calher>Jookia, how could it break?
<calher>I'm on Libreboot.
<Jookia>calher: Well, GRUB should have previous system revisions
<Jookia>calher: If it doesn't that's a huge bug
<calher>Jookia, it may not, because of Libreboot.
<Jookia>Libreboot should read the config file and give you options
<Jookia>Unless you edited Libreboot's grub.cfg
<mark_weaver>calher: haven't you been loading GuixSD's grub.cfg from Libreboot's GRUB?
<mark_weaver>calher: if you do "ln -s grub.cfg /boot/grub/libreboot_grub.cfg" then it will be loaded by the first (default) menu item in Libreboot's GRUB.
<mark_weaver>that's what I do on my Libreboot machines running GuixSD.
<calher>mark_weaver, oh ok, so it will work
<mark_weaver>but even without that, there's a menu item that scans for other grub.cfg files on the hard disk.
<mark_weaver>and then you can select an older system generation if the new one doesn't work.
<Jookia>mark_weaver: Is there a reason why the drm subsystem/kms isn't started in the initrd?
<mark_weaver>Jookia: I don't know what you mean by "starting" it. Maybe it's my ignorance.
<mark_weaver>how would we do that, and why?
<Jookia>mark_weaver: Me either, but most distros I know of switch from text mode to kms+drm when booting- Guix doesn't seem to. Not sure how (maybe a module option?), it'd be useful for people that don't have a working screen in Libreboot/GRUB but it does work in Linux
<mark_weaver>Jookia: are you talking about the graphical boot process, i.e. plymouth ?
<Jookia>No, text booting
<Jookia>At some point in the boot process your system should change screen resolutions- that's what I'm talking about
<mark_weaver>on my laptops it seems to be at native resolution from the beginning
<Jookia>Even in Libreboot?
<Jookia>I see
<mark_weaver>Jookia: what your hardware again? what kind of GPU ?
<Jookia>mark_weaver: T400, Intel GPU- Libreboot just doesn't have the ability to set the screen up properly while Linux can
<mark_weaver>well, I don't know much about this. feel free to research it and propose something to us
<mark_weaver>but fwiw, I've used GuixSD with a Libreboot X200, as has paroneayea and aeva, and for me at least, it seemed to be in native resolution from the start.
<mark_weaver>but maybe I'm depending on the fact that Libreboot could initialize my screen in the X200.
<Jookia>Neat- I don't have a working screen on a Libreboot machine so I assumed it was like every other laptop ever
<mark_weaver>on my machines, Libreboot's GRUB shows a nice background image even in the GRUB menu, and then GuixSD's grub.cfg loads another background image, both in native resolution.
<mark_weaver>and then the kernel boots with the "bathing penguin and tux" graphics at the top and text in native resolution below, etc.
<mark_weaver>on both X60 and X200 machines.
<Jookia>I shall do some work to see if I can get my problem fixed since other distros somehow do it- though I still haven't found a way to communicate with EHCI so if I can fix this I'm kinda stuck
<mark_weaver>which distros have you tried that work on the Libreboot T400?
<mark_weaver>well, that get the graphics working from early linux boot
<Jookia>Basically all of them that boot at all
<Jookia>Trisquel, Debian, Parabola
<mark_weaver>Jookia: does our USB installer boot?
<mark_weaver>can you see and control Libreboot's GRUB ?
<mark_weaver>Jookia: note that booting our USB installer from Libreboot GRUB is different than booting other USB installers, because ours is not an ISO. See
<Jookia>mark_weaver: I don't know
<Jookia>mark_weaver: I can control (but not see Libreboot's grub), and I have no idea what the Guix USB is doing
<Jookia>mark_weaver: I have a few ideas on how to fix this, so don't worry too much
<Jookia>mark_weaver: Adding the i915 module gives me a console!
<mark_weaver>Jookia: ooh, nice!
<mark_weaver>maybe we should add that by default, dunno.
<Jookia>Perhaps- It's not by default in NixOS so maybe there's some magic detection glue that should be added to cover this for things like Noveau too. Though Debian and Arch both recommend explicitly adding the module
<Jookia>I think documentation is warranted at the least, so I'll see what I can do about that
***ueno_ is now known as ueno
<mark_weaver>Jookia: okay, thanks for looking into it!
<mark_weaver>Jookia: I see that I have the i915 module loaded, and that seems to have happened automatically, but maybe not until eudevd was launched or something.
<Jookia>mark_weaver: Maybe there needs to be more probing in early init?
<Jookia>Though maybe that's too complex for such odd issues
<mark_weaver>the modules themselves should handle the probing.
<mark_weaver>or at least that's my guess. I don't know how to do it reasonably.
<mark_weaver>or maybe that's udevd's job.
<Jookia>It is a mystery
<mark_weaver>it seems to do that job on my machine
<Jookia>I'll have to look more in to it then, once I catch up on patches I've been doing
<mark_weaver>I guess your machine is a special case. usually the boot flash has initialized video.
<Jookia>It could be a symptom of weird coreboot bugs
<Jookia>What's the workflow for documentation? Is there a way to generate HTML from it?
<mark_weaver>I'm not sure it's so much a "bug" as an incomplete implementation.
<mark_weaver>Jookia: if you want, sure: make doc/guix.html
<mark_weaver>ditto for pdf
<mark_weaver>but I usually use the info reader in emacs.
<Jookia>I'm going to submit two mior patches then work on the libreboot? patch
<mark_weaver>sounds great, thanks!
<Jookia>It's working but I haven't cleaned up the patch- I also need to submit a patch to Libreboot, then get Btrfs and LUKS set up to work nicer with Guix, then add LVM support
<Jookia>Then I'll have a bootable machine
<Jookia>mark_weaver: Do you know the policy of updating copyright headers on files? I'm not sure whether to add a notice for my small changes or not
<mark_weaver>Jookia: it's good to always update them.
<Jookia>Neato petito
<boegel>civodul: ping! :)
<wingo>so. in guixsd, is the idea that you never have local #! scripts that work?
<wingo>tbh i don't understand the reason for the exception that allows /bin/sh to be present
<wingo>but prohibits /usr/bin/env
<lfam>I believe you can use the sh in /run/current-system in your shebang
<alezost>I just point /usr/bin to my ~/.guix-profile/bin
<alezost>I mean with a symlink
<lfam>You could also use Guix to install your script, and that would patch the shebang for you. But it might get annoying to enumerate all the dependencies
<wingo>not everyone uses guixsd :)
<wingo>#! scripts in particular are often shared between people or form part of a build system, and there's no nice fix to that
<wingo>except like doing all your development in a container with mapped namespaces or something
***francis7 is now known as francis
***francis is now known as fchmmr
<lfam>I use them often but my impression is that you might not find many friends of the Bourne shell script here ;)
***fchmmr is now known as francis7
<wingo>but i repeat the question: afaiu there is no justification of /bin/sh but not /usr/bin/env
<wingo>lfam: it's precisely for that reason! the bourne shell has favored status in guixsd, it works. /bin/sh is there.
<wingo>but there is *no* way to make a shell script that works on guix and *also* on non-guixsd systems that doesn't use /bin/sh
<wingo>that includes bash, python, guile, etc
<Jookia>There's no /usr/bin/env? Jeez
<Jookia>I wonder why
<wingo>because there's no /usr :)
<alezost>Jookia: because there is no /usr
<wingo>but why is there /bin?
<Jookia>Just add /usr/bin/env
<Jookia>git why are you so broken
<alezost>wingo: do you suggest to have just /usr/bin/env? If so, I object, as I personally use /usr/bin/guile and /usr/bin/python for my scripts
<Jookia>Why not use /usr/bin/env guile or /usr/bin/env python
<wingo>alezost: the utility of /usr/bin/env is as a trampoline. e.g. #!/usr/bin/env bash
<wingo>of course the kernel is ridiculously stupid about shebang handling. why no relative paths, why not more than 2 arguments
<wingo>it's too early in the morning to be techmad :)
<Jookia>so we can't build libreboot on guix now ;)
<Jookia>well, maybe with tons of patching- but definitely no developing
<alezost>Jookia: wingo: I've just checked. This works in a guile script:
<alezost>#!/usr/bin/guile \\
<alezost>-e main -s
<alezost>And this doesn't work:
<alezost>#!/run/current-system/profile/bin/env guile \\
<alezost>-e main -s
<alezost>the error: /run/current-system/profile/bin/env: guile \\: No such file or directory
<wingo>yes i know. to gain /usr/bin/env portability, you have to write your script in a different way. sad panda :/
<alezost>wingo: could you tell me this different way please :-)
<wingo>ending your script with (when (batch-mode?) (apply main (program-arguments)))
<Jookia>Not having /usr/bin/env is kind of something I'd laugh at a distro for
<alezost>wingo: thanks! I didn't know about 'batch-mode?'
<wingo>it appears to be undocumented :) but it's not going away, so feel free to use it :)
<civodul>boegel: pong!
<civodul>hi there!
<Jookia>I guess the 'solution' in Guix to most problems is 'package it' which doesn't work very well for things that don't involve installing things
<wingo>Jookia: so i can understand the argument for not having any /bin or /usr. but i also understand that once you start adding to /usr there is no logical stopping point, and for development you need more than /usr/bin/env usually
<Jookia>wingo: logical stopping point is making a distro that's usable for most tasks
<wingo>so the real solution for most development is containers and mapping a profile to /usr in the container
<lfam>No, that's true. Although there's no reason you couldn't make a shell-build-system that trivially copied the script into the store and set the right permissions
<wingo>ACTION adds Jookia to ignore list :)
<Jookia>ACTION shrugs
<Jookia>I'm certainly disappointed in learning that I'll have no way to run my shell scripts in Guix
<lfam>Jookia: I just don't see why you think that's the case. There's been several suggestions that are trivial to do.
<Jookia>lfam: What's trivial that doesn't include writing more code
<cehteh>hardcoded paths :D
<civodul>ACTION thinks the arguments haven't changed since :-)
<lfam>Jookia: Just symlink env to /usr/bin/env
<Jookia>lfam: Why isn't that default?
<cehteh>well for some security critical shell scripts i sometimes hardcode absolute paths .. that wont work well in guix
<civodul>Jookia: are you using GuixSD already?
<lfam>For a security critical shell script, the guarantees of running the correct code you get from Guix and way stronger than just using absolute paths
<lfam>the "correct code" meaning, the path points to what you want it to point to
<cehteh>yes .. but it needs to be rigged the other way around
<Jookia>civodul: I've been spending time setting it up- It worries me that I can't write code that's portable without specializing for Guix
<francis7>backwards compatibility
<francis7>it's a thing
<civodul>Jookia: i think you'll have to see for yourself how much of a problem it is to lack /usr/bin/env
<francis7>#!/bin/bash is correct because that's what everyone uses
<alezost>wingo: thanks, batch-mode? is great; so now I agree with you on having /usr/bin/env :-)
<civodul>Jookia: my experience has been mostly "no problem" for my use cases, but wingo had a different experience, for instance
<Jookia>civodul: As a user? Maybe not that much- As a programmer, it sounds much more difficult converting all my scripts to work on Guix and normal systems
<civodul>Jookia: i do program as well occasionally ;-) and it's been ok
<francis7>#!/usr/bin/env bash <-- also fine
<civodul>but again, YMMV
<boegel>civodul: do you know who was (co-)organising the Guile devroom at FOSDEM?
<francis7>#!/bin/bash <-- please do not break this :)
<civodul>boegel: i had my name on it, but really Pjotr Prins took care of everything
<rekado>boegel: Pjotr Prins organised it.
<Jookia>civodul: I think /usr/bin/env should exist in containers- we can specify dependencies there and teach people to wrap their scripts maybe- but not at all means there's a huge amount of breakage. Throwing away compatibility with other distros for no gain at all is really weird
<francis7> <-- correct response
<wingo>francis7: it is not broken, it has never worked :)
<francis7>ACTION afk
<francis7>but hint: a broken thing that everyone uses isn't broken, so don't break it
<Jookia>civodul: Having a container create /usr/bin/env and maybe an operating-system option for people who like to play with sharp blades who aren't normal users would be fantastic
<Jookia>francis7: neat, it seems there *is* a solution
<wingo>man, it's cute when guix newbies like me have opinions innit :)
<Jookia>I want to get my libreboot? patch put on the mailing list in the next hour but I can't test it :(
<lfam>Really, a security critical shell script that just relies on absolute paths for its reliability is just one mutable-usr-operating-system upgrade away from falling over. That's one situation where it would be worth it to port the script to Guix.
<Jookia>lfam: True but not everyone runs Guix and the problem is that writing code for both Guix and normal systems is a little more difficult now
<lfam>Indeed it is.
<francis7>everyone rides a bicycle with two wheels on it
<cehteh>aside that, woudlnt it be possible to generate a 'usual' filesystem hierarchy with namespaces per user profile and some mount magic?
<francis7>everyone drives a car with 4 wheels
<lfam>Jookia: So, your patch doesn't work because the system can't interpret the shebang?
<Jookia>lfam: Oh, no- my patch doesn't work because Git's being broken
<boegel>civodul, rekado: I'm helping out with the video cutting, and I plan/hope to do the cutting for the Guile (& Lua) devroom tonight
<francis7>everyone eats spaghetti with a fork and spoon
<francis7>these are interfaces that are well-established
<Jookia>francis7: wait what
<lfam>Oh, okay. I was going to point out that there are many package in Guix that have shell scripts inside them and they all work fine. So you might look in there for some examples of how this can work.
<boegel>civodul, rekado: there's bad news too though... it seems like part of the Guile talks are missing, the recordings only start at 12:20 or so, i.e. during the Q&A part of rekado's talk :(
<francis7>^ bicycle
<Jookia>Spaghetti with a spoon?
<Jookia>patch -p1 appllies my patch, but git won't
<df__>francis7: :p
<francis7>and those cars would fall over sideways when you turned around corners too quickly
<lfam>We get your point francis7. So, for you, what is the issue? The libreboot source tree contains shell scripts with shebangs like #!/bin/bash and you think these won't work in Guix?
<francis7>guix is that 3-wheel car
<francis7>because it broke the thing that everyone uses :)
<francis7>#!/bin/bash <-- 4-wheel car
<Jookia>Aren't all distros moving to /usr/bin/bash
<lfam>francis7: If that is the issue for libreboot, I don't think it will be an obstacle. There are tons of shell scripts in the tree of Guix packages and they all work correctly.
<Jookia>lfam: But what if he doesn't want to package Libreboot every time he wants to recompile
<francis7><Jookia> Spaghetti with a spoon?
<francis7>Ok, ignore that one
<lfam>If I had a large project and I wanted to be able to build it reliably, and effectively manage the relationships between the zillions of dependencies, I would develop it for Guix or a system like it. Developing it on a traditional distro such as Debian requires you to manage the state of all the dependencies, without having the tools to do that build into the system. But of course he is the one working on the big project, so that is my
<lfam>naive outsider's perspective.
<lfam>And one usually doesn't have to repackage something just to recompile. Not until you make some change to the build process would you normally need to touch the packaging.
<Jookia>'Have everyone use Guix' isn't a solution to 'I can't write code for both normal systems and Guix'- and I imagine 'normal systems' would be chosen instead of Guix
<lfam>I just don't see the large barrier. Most of our packages are only changed by automated processes in the build process. There aren't many Guix specific changes, at least to leaf packages. And all distros have to make distro specific changes to core packages.
<Jookia>The barrier *is* the build process
<Jookia>Because we're not packaging
<Jookia>Developers don't package their software when developing
<lfam>Eh. To each, his or her own.
<Jookia>That doesn't seem like an appropriate response to 'Guix breaks a commonly established workflow'- on Arch I don't make a PKGBUILD for every piece of software I download and develop. The proposed solution seems like something I could fix in a day (if Git worked)
<civodul>boegel: re videos, yeah, i read they had recordings only starting from "lunch time" :-/
<civodul>boegel: anyway, thanks for helping out with videos!
<boegel>civodul: I'm happy to help any way I can with FOSDEM stuff, such a great meetup
<Jookia>mark_weaver: civodul: libreboot? patch should be in guix-devel now
<Phlogistique>Suggestion: use binfmt_misc to handle binaries that start with #!/usr/bin/env with the user's env
<Jookia>Phlogistique: Would be very cool
<Phlogistique>I've just done a proof of concept
<Phlogistique>echo ':path:M::#!!::/home/no/bin/path_interpreter:C' > /proc/sys/fs/binfmt_misc/register
<Phlogistique>no@nrubinstein-de ~/bin % cat path_interpreter
<Phlogistique>first_line="$(head -n 1 "$1")"
<Phlogistique>exec $cmd "$@"
<Phlogistique>And now I can run scripts with pseudo-shebangs lines :)
<Jookia>Phlogistique: Neato petito!
<civodul>Phlogistique: nice!
<civodul>Phlogistique: you should post it to guix-devel
<civodul>we could provide a command or something to install this handler
<Jookia>That could be very useful for containers where we can specify the inputs/outputs
<Phlogistique>course the behaviour might be slightly different so used #!! instead of #!/usr/bin/env
<Phlogistique>*of course, so I used
<civodul>yeah but we could do that for whatever command
<Jookia>civodul: Do you have any thoughts on removing SVN repo downloads from Guix?
<rekado>(actually, I eat spaghetti with chop sticks...)
<rekado>Jookia: it really depends on finding alternative sources then.
<Jookia>Right now I'm unable to complete my Guix build on my torified system
<rekado>we download from SVN (or git) only when there's no tarball that we could use.
<Jookia>Unfortunately SVN doesn't work well (if at all) over Tor
<Jookia>Perhaps I'm missing some command to proxify it
<Jookia>It doesn't care about https_proxy or http_proxy env vars
<civodul>alezost: BTW, generation diffs in Emacs made a great impression during my FOSDEM talk :-)
<civodul>alezost: then someone asked "can you do the same for the full OS?"
<civodul>alezost: to which i said "not entirely"
<alezost>civodul: what does "the full OS" mean? system generations?
<civodul>alezost: right, but not just the system profile but also system services and everything
<alezost>ah, well I don't see how a human readable diff between system services can be made. I mean we can make a diff between "shepherd.conf" files but I don't think it will be very useful
<civodul>yeah that seem tricky at best
<civodul>if shepherd services were purely declarative that would be easier
<civodul>you could compare the command lines etc.
<petter>is there a command you can run during installation to get a list of available timezones?
<civodul>petter: tzselect
<civodul>well it doesn't quite return a list
<petter>i'm thinking of how to get a timezone to input in the configuration. This will do!
<petter>for a list of locales i'm changing from "locale -a" to: ls /run/current-system/locale/X.
<petter>(in the installation draft)
<petter>(as "locale -a" apparently isn't available during installation)
<civodul>you mean the 'locale' command is unavailable?
<petter>that's what i heard
<petter>i didn't change this during installation so i didn't try
***Digitteknohippie is now known as Digit
<petter>will "tzselect" be available during installation?
<Jookia>Kind of important since selecting the wrong timezone will panic your kernel
<civodul>petter: if it's not, we should add it; i was checking that
<civodul>Jookia: no longer :-)
<Jookia>civodul: Ooh, fixed? :)
<petter>civodul: i'll assume "tzselect" is available
<civodul>Jookia: yes, it fails at "build time" now, which isn't perfect yet, but much better :-)
<civodul>petter: yes, i'll add it
<petter>civodul: great!
<Jookia>civodul: Would you object to a patch that adds i915 to the default modules? I'd need someone with a non-Intel card to test this doesn't break their setup though
<civodul>Jookia: you mean in the initrd? we'd need to test if it doesn't break non-intel users, indeed
<civodul>on my machine it actually gets loaded when udev start, which is too late to get the Linux-libre mascot
<Jookia>civodul: This is true- I needed the mascot to find out I was having errors since my T400 doesn't have graphics until kms
***francis8 is now known as francis7
<Jookia>Woo! I have a workaround for proxying svn checkout over HTTP
<fhmgufs>sneek: Do you have some messages for me?
<sneek>fhmgufs, you have 1 message.
<sneek>fhmgufs, mark_weaver says: if a package wants to install its gir data into an existing store directory, you need to modify it to install the gir data in its own package output directory. see the grilo and libgee packages in gnome.scm for examples, but the fix might be somewhat different in your case.
<fhmgufs>mark_weaver: thanks a lot.
<Jookia>btw- for anyone curious
<Jookia>after I fixed my t400's screen my first greeting with guix on it was btrfs.fsck not found causing it to bail
<roelj>What's the build system if the build process only involves a Makefile, so running "make" will build the whole package?
<roelj>Should I use gnu-build-system and remove the additional steps?
<efraim>that's a fairly normal way to do it
<Jookia>Does anyone here have a system *without* Intel graphics?
<efraim>I have amd graphics, but i'm still running guix on debian
<Jookia>efraim: If you open a terminal and type 'sudo modprobe i915' what happens
<efraim>doesn't say anything
<roelj>efraim: Do you know of a package that does this? Then I can have a peek.
<Jookia>efraim: Does it mention anything in 'dmesg | tail' ?
<efraim>nope, just hot laptop warnings
<efraim>i'd be looking for something radeon i think
<Jookia>Hmm. I'm wondering whether it'd be fine to 'modprobe i915' at the start of Guix for everyone
<efraim>from `modprobe -c` I have:
<efraim>options i915 modeset=1
<efraim>options radeon modeset=1
<Jookia>Maybe it's a safe bet then
<efraim>I don't see any noveau listed
<taylan>roelj: I packaged things that do this. emulators, most notably.
<taylan>Nintendo emulators, that is
<efraim>I think i915 may have started as generic on-chip graphics
<efraim>so it should be fine to just enable
<roelj>taylan: What do I need to remove other than
<roelj>taylan: 'configure'?
<taylan>in games.scm, mupen64plus for instance. I just had to delete the configure phase.
<efraim>ACTION goes to walk the dog
<roelj>taylan: I see. Thanks
<taylan>(game console emulators all seem to have strange build systems, presumably because the community is half programmer half multimedia oriented, and partly MS Windows oriented, so they're not keen on all the best practices...)
<roelj>Sounds like fun to package then.. :)
<taylan>lots of fun!
<roelj>Something different.. In (native-inputs) a ` is used. But in (arguments) I see a ' is used. What's the difference between a ` and a ' ?
<taylan>`(foo ,(+ 2 3)) -> (foo 5)
<roelj>Does ` do quasiquoting?
<roelj>And the regular ' makes it a string?
<taylan>nope, just doesn't allow "unquoting"
<roelj>Oh ok
<taylan>'(foo ,(+ 2 3)) -> (foo (unquote (+ 2 3)))
<roelj>Thanks for that insight
<fhmgufs>Was wrong with this code:
<fhmgufs>It should replace to strings in the configure file.
<taylan>fhmgufs: the strings are expected to be regular expressions. so for instance the $ characters need to be escaped
<taylan>e.g. the first should be "`\\\\$PKG_CONFIG --variable=girdir gobject-introspection-1.0`"
<taylan>two backslashes so the resulting string contains one, which is then interpreted by the regexp engine.
<taylan>in the second string, the paranthesis characters need the same treatment
<fhmgufs>Ok, thanks.
<taylan>yw :)
<fhmgufs>taylan: Is this right (it works, but looks strange): ("\\"\\\\$\\\\(\\\\$PKG_CONFIG --variable=typelibdir gobject-introspection-1.0\\\\)\\"")?
<mark_weaver>civodul: gnupg-2.1.11 on x86_64 has failed its test suite twice in a row. the first time, it failed 14/35 tests in the last section! the second time, it failed only 1/35 tests.
<mark_weaver>I saved copies of the failed logs. will try a third time I guess.
<mark_weaver>no such problems on i686
<rekado>fhmgufs: do you really want to include the double quotes in this expression?
<rekado>also note that "." in the expression matches any character (it probably doesn't make a difference here).
<rekado>I sometimes wish for a plain string expression instead of a string that is interpreted as a regular expression.
<fhmgufs>Me, too.
<fhmgufs>Are this POSIX regex expressions? Is there a reference for that?
<taylan>fhmgufs: POSIX Extended Regular Expressions aka ERE, should be in a typical GNU/Linux system's manpages
<taylan>(there's also regex(3) which is about the C API)
<rekado>in Scheme you have an additional layer of escaping, though, because some characters are not allowed in strings or have a different meaning.
<taylan>it would be cool if Guile had something akin to Elisp's rx macro
<taylan>well I guess SRFI 115 is the thing for that
<rekado>to match an open paren verbatim you escape it with a backslash: \\(
<rekado>but in a string you have to escape the backslash again
<rekado>this is what makes it so noisy, visually speaking.
<civodul>this new 'top' command is really crazy
<civodul>'top' had remained unchanged since i used it for the first time
<civodul>and now it looks like a grav-mass tree
<civodul>rather nice, just a bit too red to my taste
<mark_weaver>yes, I found it quite surprising to see such a redesign in top after decades unchanged.
<piyo>which "top"? any screen shots?
<mark_weaver>if you have guix, you can try it yourself
<taylan>which package is top in?
<mark_weaver>civodul: gnupg-2.1.11 failed three times in a row on x86_64
<piyo>civodul: thanks!
<mark_weaver>taylan: procps
<taylan>civodul: crazy!
<taylan>mark_weaver: thanks
<civodul>mark_weaver: so this was introduced by the recent upgrade that ae made, right?
<rekado>I usually use htop, which always looked more colourful.
<civodul>mark_weaver: i'm running "guix build gnupg-2.1.11 --rounds=3" now
<rekado>the colour can be switched off with "z", no?
<piyo>url copying from this terminal seems to be borken... I finally see the "red".
<mark_weaver>civodul: either that, or the security-updates patches. hydra didn't evaluate the gnupg-2.1.11 update until after I cherry-picked the security-updates commits.
<civodul>rekado: indeed
<piyo>+1 for htop
<mark_weaver>civodul: the security-updates commits updated curl, openssl, and harfbuzz. I guess gnupg was not likely affected by those.
<piyo>is there supposed to be two "shepherd"s in that top output?
<civodul>mark_weaver: the 3 rounds were successful for /gnu/store/lk82n0sxjm9z2wciiadvd32nnkr2a404-gnupg-2.1.11 (x86_64, current master)
<davexunit>piyo: one shepherd is PID 1, the other is ludo's own shepherd
<davexunit>I do the same.
<davexunit>ACTION reads
<civodul>davexunit: something like that would be interesting
<civodul>not completely sure about the implementation proposed there
<davexunit>I know that deploying servers with config files that contain secrets is important, but I'm not sure I agree that they should be allowed into the store.
<civodul>yeah, same here
<davexunit>ACTION goes afk
<taylan>the ~/.toprc file might just have the most horrible format I've ever seen. auto-generated upon hitting 'W' though.
<piyo`>davexunit: I read your link, and an issue linked to it: "Support network in initrd and enter LUKS passphrase via SSH"
***piyo` is now known as piyo
<mark_weaver>civodul: did you try building gnupg-2.1.11 on your machine?
<mark_weaver>civodul: is there a way to find out which slave built a given package?
<mark_weaver>we really need that, IMO. for example, we could see if non-deterministic build failures like internal compiler errors (which happen fairly often) are correlated to a particular machine, maybe that machine has bad RAM.
<mark_weaver>and recently, a webkit build failed due to lack of virtual memory. I'd like to know which slave it was, but the information seems to be lost to me.
<mark_weaver>(or I don't know how to find it)
<mark_weaver>maybe the 14 test failures on the first gnupg-x86_64 build attempt was a hardware problem.
<mark_weaver>(the other two times, there was only one test failure, and the same one both times: gpgtar.test)
<mark_weaver>and, if we ever discover a trojaned binary, we should know which build machine was compromised.
<civodul>mark_weaver: the 3 rounds were successful for /gnu/store/lk82n0sxjm9z2wciiadvd32nnkr2a404-gnupg-2.1.11 (x86_64, current master)
<civodul>i agree re build traceability
<mark_weaver>civodul: interesting.
<civodul>mark_weaver: is this the one that failed to build?
<mark_weaver>civodul: yes:
<mark_weaver>of the two failures on hydra where only the gpgtar.test failed, I can see that they were done different slaves, because the localstatedir is different (/var vs /usr/local/var) and one of them uses /tmp/nix-build-* and the other /tmp/guix-build-*
<civodul>all the more interesting then
<mark_weaver>civodul: and then there's the first failure, when 14(!) tests failed. that was one a machine that uses /usr/local/var as the localstatedir, and /tmp/guix-build-*
<mark_weaver>here's the log of that first failure:
<mark_weaver>something went really wrong there. hopefully the build slave can be uniquely determined by those fingerprints.
<mark_weaver>could be a hardware problem
<civodul>mark_weaver: ENOSPC sounds more likely
<civodul>if only we had Munin running on all the machines
<NiAsterisk>sorry for interrupting. I need to create an 'make install', I already found packages which can serve as a base for experimentation. I remember /usr/share/docs/'uniquename-version' as the dir for documents of all kind, and /usr/bin as the directory for executables to copy to?
<mark_weaver>civodul: matches that fingerprint
<civodul>mark_weaver: it has 28G free
<mark_weaver>civodul:'s guix has localstatedir /usr/local/var, but I can't find where the /tmp directory is, and lack the permissions to see guix-daemon's environment variables.
<mark_weaver> has localstatedir=/var, so it's not that one.
<mark_weaver>civodul: do you remember what TMPDIR is used on
<mark_weaver>ah, looks like /gnu/tmp, so it also matches the fingerprint.
<mark_weaver>but it has 477G free
<mark_weaver>so, I don't know how to tell whether the 14 failures happened on or
<mark_weaver>oh, I guess I could check the drv logs
<mark_weaver>got it. the 14 failures happened on the failure log is still there on the machine.
<fhmgufs>civodul: Is there something special I have to do to get access to the guix git repository?
<mark_weaver>civodul: and there is 477G on that machine where the builds happen, so it definitely wasn't due to ENOSPC
<mark_weaver>so might have a hardware problem
<mark_weaver>fhmgufs: it is publicly accessible for read access. for now, please submit proposed patches to the mailing list.
<mark_weaver>fhmgufs: and see the "Contributing" section of the Guix manual.
<fhmgufs>I meant write access and if there is a kind of "qualification process".
<mark_weaver>fhmgufs: there's no official process, but generally we grant write access when you have submitted enough patches that we gain confidence in you, and when it becomes a burden to commit your patches :)
<fhmgufs>Ok! :)
<mark_weaver>ACTION goes afk for a while
<mark_weaver>civodul: it would be good to install the 'memtester' package on and run it.
<civodul>mark_weaver: running it now
<mark_weaver>civodul: thanks. it will only be able test the memory that's not being used for other things at the time, of course.
<mark_weaver>the best thing would be to run something like memtest86+
<mark_weaver>but maybe this will find a problem.
<civodul>dunno but i'm not sure memory is the most likely problem
<mark_weaver>what else?
<mark_weaver>here's another failure due to lack of virtual memory:
<mark_weaver>ACTION restarts the gnupg build again
<mark_weaver>there are some important dependency failures due to the gnupg failure:
<mark_weaver>there have been many mysterious build failures like internal compiler errors that make me suspect a hardware problem, and RAM is the most common thing that causes this afaik.
<mark_weaver>but maybe there's another likely cause that I'm not thinking of.
<mark_weaver>could be overheating due to a bad fan, I suppose.
<civodul>i didn't see anything obvious in /var/log
<mark_weaver>civodul: I wouldn't expect to see anything there
<mark_weaver>would you?
<mark_weaver>ACTION boots his Lemote Yeeloong for the first time in a while.. found another power adapter he didn't know he had.
<civodul>Docker for continuous integration!
<civodul>davexunit: ↑
<NiAsterisk>what do I need to change to get everything in "Documentation" into output "doc"? this change is untested but almost working.
<NiAsterisk>I don't quite get the 3.4 manual section
<NiAsterisk>about multiple outputs
<NiAsterisk>I've looked at glib.scm and others, but it's not really obvious to me
<efraim>docker for CI seems like one of the few legit uses of docker
<davexunit>at $dayjob, we have started using docker to do rpm/deb package builds
<kristofer>ACTION needs a $dayjob
<mark_weaver>ACTION gets sucked into rebasing the wip-loongson2f branch onto master, for some damn fool reason
<pecg>Hello. Coming from gentoo, want to move to GuixSD, is full disk encryption working with LUKS?
<mark_weaver>pecg: yes
<pecg>I've read that LVM is not supported yet, but I could live without it.
<mark_weaver>right, no LVM yet
<NiAsterisk>pecg: iirc Jookia wants to hack on that soon, lvm
<mark_weaver>pecg: here's a draft guide on how to do it:
<mark_weaver>well, that's a draft of things to be added to the Guix manual.
<pecg>Well, perfect
<pecg>Now I 'just' have to learn the guix DSL
<pecg>and I will be able to write my own system declaration
<pecg>am I able to compile everything, and avoid binary installations as in NixOS?
<davexunit>pecg: yes
<NiAsterisk>system declaration is easy, for me coming from gentoo getting into packaging was difficult.. still is
<mark_weaver>pecg: one more note: we only recently added the needed crypto+hash modules to the default initrd, so you'll need to either add them manually to your OS config or run "guix pull" from the USB installer.
<davexunit>(nix actually cheats somewhat in this regard by using pre-built binaries in a number of packages)
<mark_weaver>or build from the git repo and install from there.
<mark_weaver>pecg: you're in for a lot of compiling though :)
<davexunit>speaking of pre-built binaries, I'm still quite concerned about Chicken Scheme including non-source C files for the compiler.
<pecg>NiAsterisk: I never got into ebuilds, I was using gentoo because of openrc and the compilation features, but they don't support deblobbing anymore and in order to use >= 4.0.9 kernels I have to add 'freedist' licenses, that I cannot do
<davexunit>but AFAICT there's no alternate route.
<pecg>In fact I don't want to
<mark_weaver>pecg: you need to start from our minimal bootstrap binaries, though.
<NiAsterisk>pecg: they don't? iirc 2 months ago there was deblobbing
<mark_weaver>they are included in our tarball releases, except for the statically-linked guile which is downloaded when you 'make'.
<NiAsterisk>I was using hardened-gentoo with deblobbed kernel set.
<mark_weaver>we don't use anything from the host system to bootstrap, except for its kernel.
<pecg>NiAsterisk: Today it is not anymore.
<mark_weaver>I guess it's the same with NixOS
<mark_weaver>(but am not 100% sure of that)
<pecg>mark_weaver: Yes, in order to 'bootstrap' the system, after that I can compile the base system
<NiAsterisk>:O really
<NiAsterisk>4.0.4 is the last deblobbed it seems
<NiAsterisk>where there's already 4.4 upstream
<NiAsterisk>thanks for the info :)
<pecg>I was able to use onyl free software with gentoo, but they seem a little 'hostile' to support freedom
<pecg>Last year they removed linux-libre.
<pecg>They say deblobbing scripts are prone to bugs.
<pecg>mark_weaver: I thought the same
<davexunit>gentoo is annoying
<mark_weaver>we are glad to inherit their expatriots who care about freedom :)
<NiAsterisk>it's difficult.. some other people including me ended up with custom ebuild collections and developments.. I was just not into their whole process of neglecting crypto software etc
<davexunit>they *still* only ship guile 1.8
<pecg>If it were the case, why don't fix them? and share the improvements
<davexunit>guile 2.0 (not guile, 2.0.11 or something new, but 2.0) is *masked* due to some problems that I'm unconvinced are problems.
<NiAsterisk>davexunit: and if you try to build guile 2, you break it so hard you end up with an unrepairable system (kind of why I ended up here)
<pecg>davexunit: And you will find a very hard day trying to update to 'unstable'
<pecg>The only reason I haven't changed to guixSD already was lvm, but today I convinced myself I can live without it, in fact I have never been in the need to actually use it
<NiAsterisk>pecg: because contributing to gentoo is not easy.. I prefer to work with projects who have some common goal with what I want, and guix serves more than just the distro and is free as in freedom :)
<pecg>NiAsterisk: Exactly, guixsd is a freedom commited distro
<mark_weaver>pecg: one more note regarding that draft guide: it was written for use on Libreboot machines, which include GRUB and grub.cfg burned into the boot flash, so even /boot can be encrypted.
<pecg>before gentoo I was on parabola, but I changed because of some problems I had with systemd.
<NiAsterisk>I remember you from parabola :)
<mark_weaver>if you don't have GRUB in your boot flash, then you'll need to make a separate /boot partition that's unencrypted, I guess.
<pecg>mark_weaver: But with lvm I have encrypted /boot
<pecg>since it is inside the whole volume
<pecg>NiAsterisk: I was there for years, as an active user
<pecg>I didn't 'approved' the move to support from Ceata
<mark_weaver>pecg: how does GRUB access its modules?
<pecg>That was one of the other reasons I moved from there
<mark_weaver>well, more generally, how does GRUB get loaded?
<NiAsterisk>ah, okay. hm, anyone could point me to an easy to read example for output separations? I need "out" and "doc" and with glib.scm I don't get it how to apply it.
<pecg>From /dev/sda1 which is a tiny GPT partition that does it
<mark_weaver>pecg: well, okay. on GuixSD, the only thing on /boot is GRUB.
<pecg>I will read the docs and the 'tutorial' you provided and see how far can I go without breaking something.
<mark_weaver>given this, is there a reason not to make /dev/sda1 your /boot partition?
<mark_weaver>pecg: if you know a better way, we are open to suggestions :)
<pecg>mark_weaver: No, not at all, I was using it to have /boot in /dev/sda2 which was the encrypted volume
<pecg>Let me try to replicate the configuration I currently have
<pecg>And then share the declaration, if I don't fail of course
<mark_weaver>pecg: if you put GRUB on /dev/sda1, then what was in your encrypted /boot ?
<pecg>i think I will start doing it today
<pecg>mark_weaver: No, /dev/sda1 was only 2M for GPT, /dev/sda2 is lvm with /boot inside
<mark_weaver>pecg: if you modify Guix to put GRUB somewhere else, then /boot will be empty, so why encrypt it?
<mark_weaver>do as you wish, of course, but I'm just trying to save you work and headaches for no purpose
<pecg>mark_weaver: Thanks, I appreciate it. In fact I was thinking on doing what you mention, put /boot in a flash drive
<mark_weaver>well, GRUB on my /boot uses 9M.
<NiAsterisk>mine uses 7.9/100MB
<pecg>mark_weaver: Yes, but what about the kernel and initramfs?
<pecg>I want to have them in /boot also
<mark_weaver>pecg: those are in /gnu/store
<mark_weaver>so GRUB needs to open the encrypted volume to load the kernel and ramdisk.
<pecg>mark_weaver: Oh, sh*t, I didn't think about that
<mark_weaver>our grub.cfg includes the file names of things in /gnu/store: the kernel, the initramfs, the boot script, system, etc.
<mark_weaver>for each generation of the system in the menu.
<pecg>I must study how the system is configured then
<pecg>mark_weaver: That's how you accomplish options with 'build' tags on grub
<mark_weaver>petter is our resident expert on this. he wrote that draft guide.
<mark_weaver>on full disk encryption with GuixSD, that is.
<pecg>Because it loads every kernel and initramfs built that is in the store
<pecg>This guy Eelco Dostra has changed the way I see operating systems
<davexunit>I should start using full disk encryption.
<mark_weaver>well, more precisely, all the system generations that are linked in /var/guix/profiles
<pecg>I don't know why no one had that idea before.
<mark_weaver>which is normally all the systems that you have installed (using "guix system init" and later "guix system reconfigure")
<pecg>NixOS and GuixSD are the only declarative operating systems around
<petter>i'll add to the draft an explanation that kernel and initramfs does not go in /boot as many will expect
<pecg>is the only way to have multiple versions of the system in one hard-drive without breaking each other.
<pecg>petter: Thank you very much
<mark_weaver>indeed, it's brilliant.
<pecg>mark_weaver: state of the art, indeed
<mark_weaver>GRUB is the only thing that there's only one of, so we need to be careful not to deploy a broken GRUB.
<pecg>I could basically backup the declaration file, and replacate exactly the same installation in other machines, without any problem
<mark_weaver>although even if you broke GRUB, you could boot GRUB from USB (e.g. from our USB installer) and then use it to load the grub.cfg on disk.
<pecg>mark_weaver: But that could be easy to repair
<mark_weaver>it wouldn't be too bad...
<mark_weaver>even if grub.cfg got borked, it's not too hard to boot an arbitrary /gnu/store/*-system in the store.
<pecg>Exactly, just like a normal system
<pecg>I will backup all my stuff today and start working on the migration
<pecg>Hopefully the last I will do
<pecg>I cannot even count how much times I have had to install GNU/Linux and its different flavours, and as much as I enjoy the process, it is a pain in the ass, wether you are in apt, yum, pacman or portage, it is always a time consuming manual task
<pecg>declarative operating systems are the future
<mark_weaver>and I must warn you that installing Guix for the first time is far from streamlined, to put it mildly :)
<mark_weaver>especially when you're doing something unusual like you're planning to do.
<mark_weaver>but we're here to help :)
<pecg>mark_weaver: I tried to do it in 2015 and failed
<NiAsterisk>so if I have (outputs '("out" "doc")) and later on in (arguments) I have (doc-dir (string-append doc "/share/doc")) and (doc-dir (string-append doc "/share/doc") (copy-file "Documentation/DevelopmentProcess.txt" (string-append doc-dir "/DevelopmentProcess.txt")) would that be a valid way to only copy that file when guix package -i lispf4:doc is called? it's a bit out of context, but basically that's it?
<mark_weaver>once you get it set up, it's pretty solid though...
<pecg>it was on a VM, but still
<pecg>I don't when, but I'll be back here to share my experience, I'm sure I will break something, and consequently learn something
<mark_weaver>NiAsterisk: when a package is built, all of the outputs are generated, unconditionally.
<mark_weaver>however, when downloading substitutes, you needn't download them all.
<pecg>it gives a sense of strange happinness to go into the unknown
<pecg>lots of fun
<mark_weaver>NiAsterisk: and you're going to need to do (let ((doc (assoc-ref outputs "doc"))) ...) in there somewhere as well.
<NiAsterisk>mark_weaver: hm. so I want to make 80MB attached PDF docs optional, they document how this language works, etc etc
<mark_weaver>NiAsterisk: the downloading can be optional, but when building the package, there's no way to make it optional without making two different packages.
<mark_weaver>*downloading of binary substitutes
<mark_weaver>pecg: okay, good luck!
<NiAsterisk>it looks similar to this but not tested with the lastest changes: (it breaks iceweasel, so curl is the best)
<mark_weaver>feel free to ask questions, and I'll be curious to hear how it goes.
<NiAsterisk>I'll try and see if I can change it.
<mark_weaver>NiAsterisk: adding "#:tests? #f" to arguments is the preferred way to disable tests, rather than deleting the check phase.
<NiAsterisk>noted, thanks
<mark_weaver>NiAsterisk: also, phase procedures should return a boolean indicating whether they succeeded, so add a #t after all those 'copy-file' calls.
<efraim>could adding a (zero? before also work? or is #t at the end better
<mark_weaver>copy-file's return value is unspecified
<mark_weaver>efraim: it depends on whether there's anything to test for zero-ness :)
<mark_weaver>in this case, there isn't.
<mark_weaver>most things will raise an exception if there's an error. 'system*' returns the result code of the subprocess, and does not raise an error if the result is non-zero.
<NiAsterisk>would the same apply for configure?
<mark_weaver>so we need to check the result of 'system*'.
<NiAsterisk>prefering #:configure? #f over delete?
<mark_weaver>NiAsterisk: no, there's no flag for that. you need to delete the phase.
<mark_weaver>NiAsterisk: the (replace ...) should be lined up with the (delete ...) above it.
<mark_weaver>I guess you're not using emacs.
<NiAsterisk>I am using it
<mark_weaver>oh, I see.. your parens are wrong.
<mark_weaver>the 'replace' needs to be within the 'modify-phases'
<NiAsterisk>which is why I said it's work in progress etc :)
<mark_weaver>but you have it as a sibling.
<mark_weaver>*nod* :)
<mark_weaver>NiAsterisk: and the 'mkdir-p' and 'copy-file' calls need to be within the body of the 'let*', not within the set of variables being bound.
<mark_weaver>as you have it, 'mkdir-p' will be bound to 'bin-dir', etc.
<mark_weaver>anyway, I'll leave you to it :)
<NiAsterisk>hm. okay, this was the part I just added by almost copy pasting. thanks!
<petter>here's a new version of the installation draft, new are WiFi setup, also host-name, timezone and locale are elaborated upon
<NiAsterisk>would be nice to have an option to strip Documentation from the git entirely and only get the 2MB code, documentation made available someplace else..
<NiAsterisk>80MB pdfs vs 2MB code.. :/
<petter>(i'm currently learning texinfo to convert it)
<mark_weaver>petter: sounds great, thanks!
<mark_weaver>pecg: see the updated draft from petter here:
<petter>tzselect is probably not available though, i think ludo just added this earlier today
<jin_>hi guix's
<mark_weaver>hi jin_ :)
<jin_>i have a question about check-test phase for compile a package
<pecg>mark_weaver: bookmarked
<mark_weaver>jin_: okay, what is it?
<jin_>when compile a package the phase check-test show error such as ' missing test plan'
<jin_>i see the file of package and all dependences its ok
<fhmgufs>Which package do you build?
<fhmgufs>I mean is it a custom one?
<jin_>tracker package
<jin_>its part of message,
<myglc2>petter: is looking really good
<myglc2>petter: Have you considered explaining how to set up mdadm
<fhmgufs>Sorry, seems to be package specific.
<fhmgufs>I'm currently wondering about the compiled glib settings schemas in my profile. There is one gschemas.compiled symlink to the store dir of one package, so the other package's schemas are missing of course. How do I fix this?
<petter>myglc2: thanks :)
<mark_weaver>myglc2: I don't think we have RAID support yet in GuixSD.
<petter>myglc2: i'm not familiar with mdadm
<mark_weaver>obviously this is important for servers, so we'll want to add it soon.
<mark_weaver>sneek: forget obviously this ?
<mark_weaver>silly bot
<petter>sneek has a great attitude though
<mark_weaver>heh :)
<myglc2>petter, mark_weaver: re mdadm, I like to install and boot RAID from RAID so glad to know you are thinking about it.
<myglc2>petter, mark_weaver: I thought maybe you had it but had not yet explained it, since I saw it mdadm in linxux.scm
<mark_weaver>myglc2: we have the mdadm package, but not yet any support for it in our file-system mounting code, initramfs, etc.
<mark_weaver>actually, to be honest, there might not be anything to do. I haven't tried.
<mark_weaver>maybe the kernel does it all automatically
<mark_weaver>or maybe we need to add one or more modules to the initramfs
<myglc2>the debian 8 generic install supports installing, booting and swapping on RAID1, which as a user is so much better than going back in later and converting to RAID
<myglc2>I don't understand any of the details though
<myglc2>I've just used it
<mark_weaver>I also use mdadm for RAID 1 on my Debian server, but I don't know what's needed in GuixSD to make it work. it might be trivial.
<mark_weaver>it just needs someone to try it, I guess.
<myglc2>In the meantime, not haveing mdadm is not interfearing with my enjoyment of guixSD ;)
<mark_weaver>actually, the more I think about, I suspect that adding one or more modules to our initramfs is probably all that's needed.
<myglc2>I would be happy to try or test. I have two clone machines, one is running debian 8, at least for a little while longer ;)
<mark_weaver>although I don't know about GRUB.
<myglc2>Well I'm not pushing for it, but you will eventually want it and I am happy to help if I can
<mark_weaver>GRUB needs to be able to access the root partition.
<myglc2>Yeah I think that is the key issue
<mark_weaver>GRUB does have support for RAID (md)
<mark_weaver> /boot might need to be on a non-RAID partition, since that's where GRUB loads itself from, dunno.
<myglc2>On my debian machine all the partitions are RAIDed, so GRUB must deal somehow
<davexunit>(this is very much a rant piece, with cursing and all, but it hits pretty close to home for me)
<NiAsterisk>davexunit: i've read that some weeks ago. I think a lack of accessibility with most of the www can be added to the sadness.
<mark_weaver>petter: the new guide looks great!
<petter>dave, do you know if the presentation you gave a few weeks ago is available now?
<mark_weaver>petter: one thing: 'deco' is now 'herd'.
<petter>mark_weaver: thanks! :)
<petter>mark_weaver: ah, i'll fix this
<davexunit>petter: no, I am not sure if a video will surface... :(
<mark_weaver>well, it's still 'deco' on the 0.9.0 USB installer, but it will be 'herd' on the 0.9.1 installer
<davexunit>I'll let folks know if that changes
<petter>davexunit: ok :/
<davexunit>petter: I'm sorry. I had everything setup to record on my own... but then my laptop crashed hard 10 minutes in.
<davexunit>so I have nothing.
<davexunit>there *was* another camera there, though, so there's hope!
<davexunit>it just might take awhile to surface
<petter>mark_weaver: right, let's keep it in mind then and update later
<petter>davexunit: yeah, i heard. I was hoping those other guys would have put it up by now
<NiAsterisk>there's many videos currently processing :)
<davexunit>NiAsterisk: for FOSDEM, yeah, but this was a different occasion.
<NiAsterisk>68 so far added for 2016
<davexunit>I gave a talk to a small group in boston
<davexunit>petter: I'm not the best public speaker, but I hope that if a video surfaces that it will be useful nonetheless.
<petter>davexunit: i'm sure it'll be good. I like learning about things from different people
<petter>i'm still wrapping my mind around this whole Guix thing
<davexunit>at some point it will click
<davexunit>that's how it was for me
<davexunit>lots of "but how does this work?" "but how could that possibly work?" then "ohhhhh I get it"
<petter>yeah, exactly :)
<petter>currently i've spent more time with installation than actually exploring the system
<mark_weaver>I'm not sure what to do about hydra's failure to build gnupg-2.1.11 on x86_64 after 4 failed attempts.
<mark_weaver>ludo built it 3 times on his laptop, and it succeeded every time.
<mark_weaver>and it hasn't failed on any other system.
<mark_weaver>it's causing several other important packages to dependency-fail on hydra
<mark_weaver>it built successfully on i686, armhf, and mips64el on the first try
<mark_weaver>I don't have a working x86_64 at the moment on which to test.
<petter>i can help if you'd like
<mark_weaver>petter: can you try "guix build -K gnupg" after "guix pull" or equivalent?
<mark_weaver>assuming you have a x86_64 box
<petter>yes, X200 is x86_64
<petter>(little endian in case it matters)
<petter>i haven't updated in a while, so "guix pull" will probably take some time
<mark_weaver>you should update anyway. there are important security updates
<a_e>I just read up on your irc conversation of earlier this afternoon (archiving seems to be delayed).
<a_e>The last few runs on again show 14 failing tests.
<a_e>I forced a build on now by lowering the speed factor of
<a_e>There I see one test failure as well.
<a_e>gpgtar as usual
<a_e>Now I am trying it at
<petter>a_e: I've seen the archive stop before - on days with lots of activity. I suspect there's a limit to how much chat it'll take
<a_e>petter: It turns up with some delay, though.
<mark_weaver>a_e: so far, there have been two ways that it fails on hydra: 14 failed tests, or 1 failed tests (the gpgtar.test)
<mark_weaver>a_e: and I've not heard a report of it failing on any other machine
<mark_weaver>unfortunately, I don't know whether this problem was introduced by the gnupg-2.1.11 update or the recent security-updates of openssl, curl, and harfbuzz
<mark_weaver>I guess it's probably the update because I doubt that gnupg uses any of those things.
<mark_weaver>but civodul tried building it on his laptop three times, and it built successfully every time.
<a_e>Well, now it has failed with 1 error on also.
<a_e>So it is not a issue alone.
<mark_weaver>it's also interesting that the build succeeded on all other architectures, including i686 which uses the same build slaves.
<a_e>I just see that my build on has succeeded.
<mark_weaver>hydra is currently trying it again on chapters
<mark_weaver>oh, interesting.
<mark_weaver>indeed, it finally succeeded. hydra has it now.
<mark_weaver>well, at least we can now build the things that depend on it, but I'd like to understand what's going on here.
<a_e>(Since no other things are building right now on x86, it is easy to force hydra to try rebuilds and to even force the build machine. Nice!)
<a_e>Yes, these failures are worrying.
<mark_weaver>I'll restart the dependency-failed builds
<mark_weaver>and then there's another security-updates branch to build out
<a_e>"guix size gnupg | grep openssl" shows that there is a dependency on openssl!
<a_e>The dependency chain is gnupg->openldap->openssl.
<mark_weaver>I'd be surprised if that's causing the problem.
<fhmgufs>Is there an environment variable or sth like this specifying where glib searchs for gsettings schemas?
<fhmgufs>Because it should look in the store and not in my profile.
<a_e>mark_weaver: Someone with the access rights could try to build gnupg-2.1.11 on using the previous openssl to check this.
<mark_weaver>fhmgufs: XDG_DATA_DIRS might be it. 'glib-or-gtk-build-system' automatically wraps programs with something that sets that variable to include the inputs.
<mark_weaver>a_e: sure. best to cherry-pick the gnupg-2.1.11 update on top of dfb9001, since that tree is already built out.
<mark_weaver>using the previous openssl but the new curl and other things might result in a lot of stuff being rebuild needlessly.
<mark_weaver>a_e: if that shows that the problem is in gnupg itself, we could do a git bisect.
<petter>gnupg seemed to build fine for me. It exited with status 0.
<mark_weaver>petter: thanks for checking!
<petter>sudo guix pull
<mark_weaver>heh :)
<petter>i should do a full update and reboot
<mark_weaver>petter: yes
<vaeringjar>hej, I noticed some good news from fosdem about guix and sound and usb. some friends of mine and I wonder what about the progress with hurd/mig/mach packaging?
<mark_weaver>a_e: if at first you don't succeed, try again:
<NiAsterisk>oh, i just found pjort's guix-notes. whished I discovered this earlier :) but taking notes myself isn't so bad either
<mark_weaver>a_e: I filed a bug report for this:
<mark_weaver>I attached the failed build logs that I captured.
<bavier>module-import-compiled builds are non-deterministic?
<mark_weaver>bavier: yes, unfortunately. guile's macro expander (part of the compiler) is non-deterministic. we're discussing how to fix it.
<bavier>I see, ok
<bavier>nice to know it's being worked on
<bavier>gnupg builds are failing 14 tests for me too, twice now
<mark_weaver>bavier: oooh, that's good! if you could investigate, that would be very helpful.
<mark_weaver>bavier: see and please send email to about it
<mark_weaver>if you download the substitute from hydra, you could switch the order of the inputs or some other trivial change to force a rebuild later.
<mark_weaver>or add #t to the end of the custom phase. we should do that anyway :)
<a_e>bavier: That is good news indeed! Hopefully you will find what the problem could be.
<bavier>pressure... heh
<a_e>mark_weaver: I do not think I have access to, so I could not compile there myself without going through hydra (which looks like overkill).
<a_e>bavier: No, I am just happy to be off the hook :-)
<mark_weaver>so far, bavier is the only one who's been able to reproduce this
<mark_weaver>bavier: for starters, it would be interesting to know whether reverting the gnupg-2.1.11 update fixes the problem.
<mark_weaver>(to rule out the possibility that it was one of the security updates that caused this issue to surface)
<efraim>I was about to start building gnupg-2.1.11, but it turned out I was still on the hurd branch, so that wouldn't have helped much at all
<mark_weaver>and if 2.1.10 works and 2.1.11 fails, a git bisect would be useful
<bavier>sorry, synergy borked my X
<bavier>the armor.test.log has some info: "armor.test: bug#1179 is back in town"
<bavier>a lot of "No passphrase given" failures
<mark_weaver>gah, icecat can't load that page: Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
<mark_weaver>ACTION tries epiphany
<mark_weaver>bavier: ah, good find!
<bavier>it doesn't have much to go on, but just that others are encountering the sme
<bavier>all the failures have this "No passphrase given" message
<bavier>currently checking gnupg-2.1.10
<mark_weaver>thank you!
<nckx>How big is texlive's nar? curl --head says no.
<bavier>gnupg-2.1.10 builds fine, so I'll start a git bisect
***ringst_ is now known as ringst
<mark_weaver>nckx: about 2.1G
***francis7 is now known as Guest76035
<nckx>mark_weaver: thanks. Another hour to go, then...
<mark_weaver>nckx: it's *much* faster to build texlive-texmf locally. here's a trick: guix environment texlive-texmf -- guix build texlive-texmf --no-substitutes
<mark_weaver>the worst of it is that the transfer often dies in the middle and then you need to start from scratch
<nckx>mark_weaver: sssssh! Jinx.
<mark_weaver>nckx: hydra is in dire need of replacement, and we're working on it. in the meantime, you will often find it quite slow.
<nckx>mark_weaver: but thanks for the tip, I really didn't know that. I knew it was 50% (or so) fonts, but figured something so huge must still take a while to build on a netbook.
***francis8 is now known as francis7
<mark_weaver>nckx: it's mostly just data, not much to build.
***francis7 is now known as fchmmr
***fchmmr is now known as francis
<mark_weaver>it's not the same as texlive-bin
***francis is now known as francis8
<nckx>mark_weaver: I saw the Minifree thread on the ML. That's cool news & hardware.
***francis8 is now known as francis7
<NiAsterisk>where is it failing? is (let*) (let*) not okay?
<NiAsterisk>I can't make it out yet.. my knowledge on scheme is limited
<francis7>nckx, link to that thread? which mailing list?
<mark_weaver>NiAsterisk: in both cases, you are putting the expressions to run within the 'let*' where the bindings should go
<mark_weaver>for each of those 'let*'s, you need to move one of the close parens from the end of the 'let*' to the end of the line of the last binding.
<NiAsterisk>I closed parens too early?
<mark_weaver>you closed them too late
<civodul>ACTION updates the talks at
<francis7>ah cool
<mark_weaver>NiAsterisk: (let* ((v1 e1) (v2 e2)) expr ...) is the right form.
<mark_weaver>what you have is this: (let* ((v1 e1) (v2 e2) expr ...))
<mark_weaver>see the difference?
<NiAsterisk>okay :)
<NiAsterisk>my next question would've been if you have something I can read into, but it's just syntax, so there's not much other than what I already found
<efraim>I just got the gpgtar failure on gnupg-2.1.11, running it again
<nckx>mark_weaver: are there any plans for a dumb cache in front of Hydra? That saves an actual tonne of CPU & I/O on its own, as I'm sure you already know.
<nckx>(Sorry, I'm new to GNU-as-a-project and your infra. I didn't even realise how relatively hard it must be to buy servers.)
<mark_weaver>nckx: we already have one on the same machine, but we should add more.
<mark_weaver>but when it's slow, the problem is more likely that the item is not yet cached, and is being generated+compressed on-demand.
<a_e>nckx: To build texlive, I would do the following:
<a_e>guix build texlive-bin
<a_e>to download the binaries from hydra
<a_e>wget ...texlive-texmf... from the texlive server
<mark_weaver>nckx: the complication is mainly that we want to build a Libreboot-based server, and no one is currently offering them pre-built.
<mark_weaver>and we are not really hardware people
<a_e>And then the "guix environment texlive-texmf" as mark_weaver suggested; you can then "guix build texlive --no-substitutes" inside.
<a_e>"texlive" is the only package that should be installed by a user.
<a_e>The reason that texlive-bin and texlive-texmf are exported at all is so that one can build semi-locally as I just explained.
<davexunit>a separate caching server in front of the frontend server might be nice.
<nckx>mark_weaver: I admire your (plural) commitment.
<mark_weaver>a_e: fwiw, I build only 'texlive-texmf' locally, not texlive itself.
<nckx>mawk_weaver, a_e: thanks! I'll do that next time, or if this transfer fails.
<mark_weaver>and I should also mention that the clever command comes from lfam
<a_e>texlive itself is mainly a collection of symbolic links. You may as well build it locally also.
<mark_weaver>a_e: ah, okay. so texlive-bin is the thing that needs building?
<nckx>So no (prefer-local-build) in Guix? :-)
<bavier>nckx: there's the '--no-substitutes' option
<a_e>texlive-bin needs to be compiled and is reasonably big; texlive-texmf mainly needs to be unpacked. texlive is essentially the union of both.
<mark_weaver>a_e: ah, okay, thanks!
<nckx>bavier: but no way to specify it in the package itself (not implying that's the best solution).
<mark_weaver>nckx: I don't remember clearly, but I think it's been discussed and we failed to reach consensus on whether it was a good idea.
<mark_weaver>e.g. on underpowered arm machines it might be bad
<mark_weaver>when we have a better distribution system for binary substitutes, it probably won't be desireable
<mark_weaver>we have a #:substitutable? option, but that's a bit different
<mark_weaver>anyway, I have to go afk for a while...
<efraim>my machine is fairly weak and it takes ~20 minutes to build, but 1.5 hours to download
<efraim>doesn't it also need lots of ram?
<bavier>ISTR that our downloader write only to RAM
<nckx>mark_weaver: yeah, it feels a bit hacky... A way to specify a local/network preference ratio would be better (e.g. even with GNUnet/HydraNG, my local connection might be as slow as my CPU) — as well as a total mess in practice.
<nckx>efraim's point, basically.
<efraim>guix build texlive-texmf --sources --no-substitutes to download the source from upstream instead of from hydra
<nckx>But I've never met a way of expressing build ‘heaviness’ that didn't suck.
<nckx>ACTION stops thinking aloud.
<nckx>ACTION lols. ‘bzip2: Compressed file ends unexpectedly’. Here we go.
<bavier>nckx: it happens, just try again
<nckx>bavier: I know :-) I meant that I can now try out a local texlive build a bit sooner than I was hoping.
<a_e>efraim: Interesting! On the other hand, I keep a local copy of the sources on disk, since they tend to be garbage collected. And I am building texlive all the time...
<bavier>nckx: ah, yup
<nckx>530 "Sorry, the maximum number of allowed clients (10) are already connected.\\r"
<nckx>Good thing I'm not in a rush.
<nckx>ACTION ...10!? OK...
<a_e>nckx: 10 for the upstream texlive sources?
<nckx>a_e:, yes. Anyway, I'm in now.
<efraim>a_e: a local copy of texlive, or of most packages?
<a_e>I thought of the sources of texlive.
<a_e>efraim: Yes, I keep the texlive sources also in my home directory, so as to be able to do a quick "guix download file:texlive-20150523-texmf.tar.xz" in case it gets garbage collected in the store.
<a_e>You could say that I am collecting texlive-texmf copies :-)
<fhmgufs>How do I get the version (major.minor) of another package?
<fhmgufs>like (version-major+minor ?????)
<bavier>fhmgufs: that's the one
<bavier>(version-major+minor (package-version <foo>))
<fhmgufs>:) Thanks!
<roelj>Can I use #:make-flags for compiling a different make target?
<bavier>roelj: I think that would work
<bavier>it might be abusing the flag though
<roelj>Is there a better way?
<mark_weaver>roelj: #:make-flags aren't good for that, because they are also passed during the "make check" and "make install" phases.
<roelj>mark_weaver: Ok, I didn't think of that
<mark_weaver>roelj: better to make a custom phase that does the right thing.
<mark_weaver>if you want to see the default phase, it's 'build' in guix/build/gnu-build-system.scm
<roelj>mark_weaver: Thanks. That was my next question :)
<calher>OK, how did I boot GuixSD on Libreboot last time? The tips on the installation manual draft doesn't look like what I entered. Something about "cryptomount -a; set root=(ahci0,usb1); config /boot/grub.cfg"?
<janneke>i'm having trouble with running more recent guile versions in guix, how are you all doing that?
<janneke>i am trying guile-next, but it seems that .../guile/site/2.0/.. paths are used which hold conflicting guile-library .go's
<janneke>i would like to run something much more recent (git?), why do i not find that in the repo?
<calher>I thought the whole thing about Guix is that you can have different versions without conflict.
<davexunit>janneke: use one guile or the other
<davexunit>you can't use both in the same profile.
<davexunit>make a new profile or use 'guix environment' if you're just screwing around
<calher>Oh, yeah. That makes sense. I wouldn't want to have multiple versions *in the same profile*.
<calher>Ah, I remembered how to boot it.
<calher>I need a copy of desktop.scm again.
<civodul>if you go to (HTTP!) and click on "Expand", you'll see something pretty cool
<civodul>thanks to the help of roelj on debugging
***Digitteknohippie is now known as Digit
<calher>I'm confused. I did guix package -i gnupg and it is in my profile, but I can't do gpg foo.gpg.
<a_e>Hm - on icecat, there are quite a few external sites to unblock first!
<bavier>civodul: did you mean to paste an https address?
<a_e>calher: Try gpg2; you just installed gnupg-2.1.11 (probably).
<mark_weaver>civodul: clicking expand doesn't do anything for me
<civodul>bavier: no, http-unsecure
<bavier>my firefox is blocking a lot of "insecure content"
<civodul>mark_weaver: oh?
<roelj>mark_weaver: HTTPS is currently not working
<a_e>I allowed all origins, and clicking does nothing for me either.
<mark_weaver>it used to toggle showing the details, but now that no longer works.
<a_e>With https-everywhere, I am automatically on https.
<fhmgufs>For me it works.
<civodul>a_e: yes, you have to disable it for now
<calher>a_e: gpg2 worked, but it seems I may have to declare the passphrase beforehand because it's not asking me for one and says it failed.
<mark_weaver>ah, maybe that's the problem. I use https-everywhere
<a_e>calher: gpg2 is complicated. You need to define a pinentry programme in .gnupg/gpg.conf.
<a_e>Add a line
<a_e>Sorry, in .gnupg/gpg-agent.conf, add a line
<calher>gpg was great. What's with this new-fangled gpg2 junk?
<a_e>pinentry-program /home/user-name/.guix-profile/bin/pinentry-gtk-2
<fhmgufs>civodul: My problem with this page is that its so big. Couldn't it be split?
<a_e>You can also do the following:
<calher>I'm still in TTY. I don't have desktop.scm.
<a_e>guix package -r gnupg -i gnupg-1.4.20
<calher>I'd like desktop.scm
<civodul>fhmgufs: yeah we'll have to do something about it
<a_e>Very nice that page!
<fhmgufs>For me it's practically unusable.
<mark_weaver>ah, after disabling https-everywhere and some other protection that icecat was doing, one time I got a brief glimpse of what appeared to be build statuses, but it's now I can't get it working anymore.
<a_e>I switched to iceweasel for the test :-)
<mark_weaver>clicking expand almost never works for me.
<bavier>it only worked once for me
<a_e>So now there is some work to do for making it compatible with our icecat. If this is at all possible.
<a_e>Including content from another web site into https might not work.
<mark_weaver>ACTION tries it in epiphany
<civodul>it's expected that it doesn't work in https at the moment
<civodul>we need Hydra to serve stuff in https
<a_e>What does it download from all these other web sites?,,, ...
<mark_weaver>it works much better in epiphany
<calher>a_e: Removing gpg2; getting gpg1
<mark_weaver>we need to break this page up into smaller pages. I suspect a lot of the slowness is due to how huge the page is.
<a_e>It is not slow for me.
<bavier>a_e: probably package logos
<a_e>On the contrary, it is amazingly sleek.
<mark_weaver>still, it's great to see progress on this!
<a_e>I see! Neat. So even without enabling these origins, the rest will work.
<a_e>So it is possible to mix different tls sessions in one page?
<mark_weaver>bavier: how could it download the logos? we don't have that information in our package descriptions.
<mark_weaver>anyway, I don't see any package logos
<mark_weaver>so I'm also curious why it causes lookups to other sites.
<a_e>They appear for mpfr and r, for instance.
<mark_weaver>(I'm taking a_e's word on that, I haven't checked)
<a_e>mark_weaver: I am also curious where the information comes from.
<bavier>mark_weaver: we lookup logo url from IIRC
<mark_weaver>bavier: hmm, can you give an example of a logo that is visible for you, other than the GNU head?
<a_e>After clicking on "expand".
<calher>Crap. Every time I boot, it's 1969.
<bavier>mark_weaver: gimp package e.g.
<bavier>once expanded
<mark_weaver>calher: that's a known issue when running recent kernels on recent Libreboot. you can work around the problem by using linux-libre-4.1 instead
<mark_weaver>and hopefully Libreboot will fix/work-around the problem soon on their end.
<mark_weaver>(well, it's in upstream coreboot, not something that Libreboot did specifically)
<mark_weaver>ah yes, I see the ones for gimp and mpfr
<mark_weaver>and I can see that it tries to for guile but there's a broken image link
<calher>mark_weaver: So it's not because I'm using bare-bones and didn't put it any S-exps for time?
<calher>mark_weaver: How do I change kernels?
<calher>Is there a manual for that?