<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>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>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 guix-devel@gnu.org is the format produced by "git format-patch -1" <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. <paroneayea>mark_weaver: looks like pulseaudio is working just fine <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) <GChriss>paroneayea: gst-libav provides some of those codecs <mark_weaver>paroneayea: and you need GST_PLUGIN_PATH="$HOME/.guix-profile/lib/gstreamer-1.0" <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>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>and /etc/passwd points to a reasonable /bin/bash <paroneayea>so much bs in my emacs config, I don't even know where it all comes from anymore <kristofer>in gnu/services/xorg.scm where is xf86-input-libinput defined? <mark_weaver>kristofer: both "guix package -s" and "guix package -A" will tell you the file and line number. <kristofer>I'd like to be able to scroll using 2 fingers on the touchpad <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 <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 <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? <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 <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>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>Well, not ftp repos per-se- ftp links are able to be mirrored <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. <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>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>this is my first time installing a package btw <paroneayea>ACTION confused by build/python-build-system.scm <mark_weaver>pizzaiolo: you should, otherwise you will get old versions of everything, with security holes. <pizzaiolo>ok, but why is it downloading unrelated things? <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. <mark_weaver>if you scroll up, it should tell you what it plans to build and what it plans to download. <pizzaiolo>mark_weaver: ERROR: In procedure getaddrinfo: Name or service not known <mark_weaver>sounds like you don't have a working network connection <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. <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>if you're looking for a polished distro with no rough edges, you've come to the wrong place. <pizzaiolo>mark_weaver: disconnecting and reconnecting did the trick <pizzaiolo>by the way thanks for the ever-present help :) <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. <mark_weaver>no, normally you run "guix pull" as your normal user, and most guix commands. <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. <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. <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 <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 <lfam>Well, transmission-remote-cli has an ncurses interface, not exactly cli <paroneayea>okay, nice, got one dependency for assword installed and working it seems <paroneayea>it could use some features but in general works quite nice <calher>So how would I add (ntp-service) to <bazaar.launchpad.net/~csh-a/calher-configs/trunk/download/head:/config.scm-20160203084012-z3m8g3a2bed1czuq-1/config.scm>? <mark_weaver>calher: put it in the same list as (dhcp-client-service) <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) <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 <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>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. <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>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>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 <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. <mark_weaver>Jookia: if you have a USB-serial adapter supported by Linux, it looks like console=ttyUSB0 is supported as well. <calher>Jookia, if it fails it's scary because my sys won't work <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. <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>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 <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. <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>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! <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: 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>or at least that's my guess. I don't know how to do it reasonably. <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. <Jookia>I'm going to submit two mior patches then work on the libreboot? patch <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 <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 <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 <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>#! 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 <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>#!/run/current-system/profile/bin/env guile \\ <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 :) <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>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 <lfam>Jookia: Just symlink env to /usr/bin/env <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 <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 <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 <wingo>francis7: it is not broken, it has never worked :) <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 <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 <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? <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 <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 :( <Jookia>patch -p1 appllies my patch, but git won't <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>because it broke the thing that everyone uses :) <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 <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>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>echo ':path:M::#!!::/home/no/bin/path_interpreter:C' > /proc/sys/fs/binfmt_misc/register <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 <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>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? <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>(as "locale -a" apparently isn't available during installation) <civodul>you mean the 'locale' command is unavailable? <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 <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 :-) <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. <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 <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>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 <taylan>roelj: I packaged things that do this. emulators, most notably. <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 <taylan>in games.scm, mupen64plus for instance. I just had to delete the configure phase. <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.. :) <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 ' ? <roelj>And the regular ' makes it a string? <taylan>nope, just doesn't allow "unquoting" <taylan>'(foo ,(+ 2 3)) -> (foo (unquote (+ 2 3))) <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>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. <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>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>civodul: gnupg-2.1.11 failed three times in a row on x86_64 <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. <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 <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. <taylan>the ~/.toprc file might just have the most horrible format I've ever seen. auto-generated upon hitting 'W' though. ***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>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>mark_weaver: is this the one that failed to build? <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-* <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>something went really wrong there. hopefully the build slave can be uniquely determined by those fingerprints. <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: hydra.gnunet.org'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>guix.sjd.se has localstatedir=/var, so it's not that one. <mark_weaver>civodul: do you remember what TMPDIR is used on hydra.gnunet.org? <mark_weaver>ah, looks like /gnu/tmp, so it also matches the fingerprint. <mark_weaver>so, I don't know how to tell whether the 14 failures happened on chapters.gnu.org or hydra.gnunet.org <mark_weaver>got it. the 14 failures happened on hydra.gnunet.org. the failure log is still there on the machine. <mark_weaver>hydra.gnunet.org:/usr/local/var/guix/drvs/kx/b0w43ksc2jjh2pf6vfphghn5c24mri-gnupg-2.1.11.drv.bz2 <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>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 :) <mark_weaver>civodul: it would be good to install the 'memtester' package on hydra.gnunet.org and run it. <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+ <civodul>dunno but i'm not sure memory is the most likely problem <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. <civodul>i didn't see anything obvious in /var/log <mark_weaver>ACTION boots his Lemote Yeeloong for the first time in a while.. found another power adapter he didn't know he had. <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 <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? <pecg>I've read that LVM is not supported yet, but I could live without it. <NiAsterisk>pecg: iirc Jookia wants to hack on that soon, lvm <mark_weaver>well, that's a draft of things to be added to the Guix manual. <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? <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) <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 <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. <pecg>mark_weaver: Yes, in order to 'bootstrap' the system, after that I can compile the base system <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 <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 <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. <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 <pecg>That was one of the other reasons I moved from there <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 <pecg>mark_weaver: Yes, but what about the kernel and initramfs? <pecg>I want to have them in /boot also <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. <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. <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 <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 <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>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. <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? <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 <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>feel free to ask questions, and I'll be curious to hear how it goes. <mark_weaver>NiAsterisk: adding "#:tests? #f" to arguments is the preferred way to disable tests, rather than deleting the check phase. <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>efraim: it depends on whether there's anything to test for zero-ness :) <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. <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>the 'replace' needs to be within the 'modify-phases' <NiAsterisk>which is why I said it's work in progress etc :) <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. <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, http://sprunge.us/PMib 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.. <petter>(i'm currently learning texinfo to convert it) <petter>tzselect is probably not available though, i think ludo just added this earlier today <jin_>i have a question about check-test phase for compile a package <jin_>when compile a package the phase check-test show error such as ' missing test plan' <jin_>i see the configure.ac file of package and all dependences its ok <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? <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. <petter>sneek has a great attitude though <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>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 <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. <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 ;) <myglc2>Well I'm not pushing for it, but you will eventually want it and I am happy to help if I can <myglc2>Yeah I think that is the key issue <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. <petter>dave, do you know if the presentation you gave a few weeks ago is available now? <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>petter: I'm sorry. I had everything setup to record on my own... but then my laptop crashed hard 10 minutes in. <davexunit>there *was* another camera there, though, so there's hope! <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 <davexunit>NiAsterisk: for FOSDEM, yeah, but this was a different occasion. <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>lots of "but how does this work?" "but how could that possibly work?" then "ohhhhh I get it" <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>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. <mark_weaver>petter: can you try "guix build -K gnupg" after "guix pull" or equivalent? <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 hydra.gnunet.org again show 14 failing tests. <a_e>I forced a build on guix.sjd.se now by lowering the speed factor of hydra.gnunet.org. <a_e>There I see one test failure as well. <a_e>Now I am trying it at chapters.gnu.org. <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 guix.sjd.se also. <a_e>So it is not a hydra.gnunet.org 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 chapters.gnu.org has succeeded. <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>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. <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 hydra.gnunet.org 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. <petter>i should do a full update and reboot <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? <NiAsterisk>oh, i just found pjort's guix-notes. whished I discovered this earlier :) but taking notes myself isn't so bad either <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>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>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. <a_e>mark_weaver: I do not think I have access to hydra.gnunet.org, 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>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) <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 <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
***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
***francis7 is now known as fchmmr
***fchmmr is now known as francis
***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>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. <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 ...)) <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. <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. <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>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 <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... <nckx>530 "Sorry, the maximum number of allowed clients (10) are already connected.\\r" <nckx>Good thing I'm not in a rush. <a_e>nckx: 10 for the upstream texlive sources? <nckx>a_e: ftp://tug.org/, 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? <bavier>(version-major+minor (package-version <foo>)) <roelj>Can I use #:make-flags for compiling a different make target? <bavier>it might be abusing the flag though <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>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>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). <bavier>my firefox is blocking a lot of "insecure content" <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. <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>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 <civodul>fhmgufs: yeah we'll have to do something about it <a_e>Very nice that page! <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 :-) <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. <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? mpfr.org, gimp.org, r-project.org, ... <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. <a_e>On the contrary, it is amazingly sleek. <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>so I'm also curious why it causes lookups to other sites. <a_e>They appear for mpfr and r, for instance. <a_e>mark_weaver: I am also curious where the information comes from. <bavier>mark_weaver: we lookup logo url from directory.fsf.org 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. <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>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? 
