IRC channel logs
2015-09-13.log
back to list of logs
<fredinsky>I edited the desktop one to make it akin to my own in hopes that it would override any mistake I may have made, but it still won't work, but this time it's another error: "guix system: error: failed to load '/mnt/etc/config.scm': ..... <fredinsky>same error at the same speed with and without --no-grub <fredinsky>gotta run for now, but will read any comments when I get back. thanks for the help guys :) <karhunkynsi>looks like you didn't name it config.scm and put it in /mnt/etc <amanwi>Hey guys, I need some help if anybody can. I think I got GuixSD installed but GRUB didn't install correctly. I have Trisquel on this same machine, and I'd like to use the GRUB2 from Trisquel. How do I add GuixSD to Trisquel's GRUB? <amanwi>the regular ole sudo update-grub doesn't see GuixSD by the way <mark_weaver>amanwi: one important feature of GuixSD is being able to roll-back at the system level, by booting into any earlier generation of the system. This depends on GuixSD creating a grub.cfg file with entries for each generation. <mark_weaver>I guess we should provide a way to create a grub.cfg without installing grub in the boot sector <spwx>Hello I just installed guix and set my locpath but i still get: substitute: warning: failed to install locale: Invalid argument <spwx>any idea whats going on witht hat? <davexunit>spwx: are you using the locales in your guix profile? <spwx>davexunit: i set it up for root and my user in my bash_profile <spwx>davexunit: yes i used that one <davexunit>which has a limited selection, but en_US is there. <mark_weaver>spwx: the substituter is run by the daemon, so LOCPATH needs to be set in the guix-daemon process <spwx>mark_weaver: ok thats what i read on the internet... but i guess i have a really dumb question... how do i set LOCPATH if the user doesnt have a shell? <spwx>mark_weaver: i used the systemd service file <spwx>ok well i think you pointed me in the right direction, thanks a lot! <davexunit>ah, I guess the systemd service file needs to specify the env var <spwx>stackoverflow says so... im gonna try it now <mark_weaver>spwx: if all else fails, another way is to make /run/current-system/locale be a symlink to a locales directory. <mark_weaver>that's the directory that is hardcoded into our libc, as a fall back when LOCPATH is not set. <mark_weaver>and maybe included even if LOCPATH _is_ set, I don't remember. <spwx>hello i figured out howto get rid of that error with systemd... under the [Service] section of the guix-daemon.service file i had to add Environment=/gnu/store/blahblahblah/locale <spwx>is there a better way to specify the directory with the locales? <spwx>Environment="LOCPATH=/gnu/store/5gz75n1yrcysrvm49lsd8m5ckmjlmws7-glibc-utf8-locales-2.21/lib/locale" <mark_weaver>spwx: looks good to me, except for one thing: it's probably better to refer to a profile somewhere, to make sure it's protected from garbage collection, and so that it will be updated when the profile is updated. <mark_weaver>if you want to refer directly to the store from the systemd file, that's fine too, as long as you remember to update it sometimes. <mark_weaver>but in that case, put a symlink in /var/guix/gcroots/ that points to /gnu/store/5gz75n1yrcysrvm49lsd8m5ckmjlmws7-glibc-utf8-locales-2.21 <mark_weaver>and remember to update the gcroot when you update the LOCPATH in the systemd file <mark_weaver>(and all of this is handled automatically in GuixSD, of course) <spwx>mark_weaver: i think pointing it to my root profile version of locale is pretty good! <spwx>havent learned about gcroot tet <spwx>and would definitely like to move to guixSD but i heard it was good to play around with the manager first <mark_weaver>sure, it's prudent to test the waters before jumping in :) <spwx>ok looks like setting LOCPATH to the root directory works! <spwx>mark_weaver: what were you saying about altering gcroot? would that help not remove a bunch of packages when i only try to remove one? <mark_weaver>spwx: well, first of all "removing" packages, e.g. with "guix package -r" doesn't remove anything from the store. <spwx>sorry, thats what i meant <mark_weaver>but "guix gc" refuses to remove anything that is reachable from /var/guix/gcroots <mark_weaver>which includes all profiles, because of the /var/guix/gcroots/profiles symlink <spwx>mark_weaver: hmm ok so i should be good with all of that then <spwx>looks like thats whats going on <spwx>mark_weaver: i also have a question ive been wondering about, in the Arch User Repository you can make a package which pulls down and builds stuff directly from git/bazar... is there anything like that for guix? <mark_weaver>we don't currently have a backend for bazaar, but we have support for git, svn, and cvs. <mark_weaver>however, by policy, we usually prefer to build from tarballs <mark_weaver>there's a bit of a trick to computing the sha256 hash of a VCS checkout <mark_weaver>Use "guix hash -r <directory>" to compute the hash, where <directory> is the checkout directory with .git or CVS or whatever removed. <spwx>mark_weaver: lol i think you are a bit over my head for now <mark_weaver>ah, nevermind, we'll cross that bridge when we come to it. <mark_weaver>our package definitions include sha256 hashes of the downloaded tarballs/git-checkouts/whatever <spwx> guix environment emacs is installing the linux kernel? is that right? <lfam>I'm curious, how does my system choose between GNU parallel and moreutils parallel? <lfam>I have both installed through Guix, but only GNU parallel is in my ~/.guix-profile/bin <davexunit>lfam: that's a collision and only one of them will end up in the profile. <lfam>If I lost my mind and wanted to use moreutils parallel, what would be the best way to get it on my PATH? <davexunit>the collision resolution is arbitrary. you should seek to avoid collisions. <davexunit>lfam: make a profile that didn't have gnu parallel in it <lfam>Okay. Funny story: I had meant to try nix/guix for a while but only bit the bullet when I wanted moreutils/sponge on Debian, and I didn't want to uninstall GNU parallel <lfam>So I installed Guix to get moreutils <mark_weaver>sneek: later tell lfam: in case of collisions between two packages in a profile, the package that was installed more recently via guix package -i takes precedence. when using "guix package --manifest" (recommended), then I believe packages listed earlier in the manifest take precedence. <mark_weaver>sneek: later tell lfam: prehaps in the future we'll have another mechanism to specify precedence explicitly, dunno. <rekado>this GTK_IM_MODULES_FILE thing is dangerous. <rekado>according to the Gtk docs there is no distinction between Gtk2 and Gtk3 modules in this file. <rekado>so when a programme uses Gtk3 and the file contains Gtk2 modules bad things can happen. <rekado>bad things did happen to me twice. <rekado>on the fresh installation I created an immodules.cache file by concatenating the output from various invocations of gtk-query-immodules-*. <rekado>then pointed to the resulting file with GTK_IM_MODULES_FILE, then started Emacs. <rekado>when clicking on the "new file" icon, a file dialogue pops up and then Emacs segfaults. <rekado>removing a couple of lines from the immodules.cache file fixes this. <rekado>I don't know how this is usually dealt with in other systems. Surely it should be possible to use input method modules with Gtk2 and Gtk3 at the same time. <rekado>when I only leave Gtk3 modules in the file Emacs does not segfault when opening the file dialogue, but other things like xfce4-keyboard-settings no longer start. Instead they show an error: "malloc(): memory corruption: 0x...." <rekado>this disappears when I uncomment the lines for the Gtk2 module of ibus. <rekado>it would probably work better if the cache files were located in $GTK_DIR/lib/gtk-$version/$version/, but then they would not contain references to external modules like the ibus IM module. <civodul>mark_weaver: looks like core-updates is in a good shape <civodul>should we merge master into it and get it built? <anthk_>Hello , I have an error with guix <mark_weaver>civodul: we might also consider updating libidn, but otherwise, sounds good to me! <mark_weaver>anthk_: pastebin.com blocks tor uses, which includes me. can you use a different paste site please? <rekado>mark_weaver: I'll try to play a little more with the many GTK-related environment variables and will later post to the ML. <civodul>anthk_: did you manually modify files in /gnu/store? <civodul>anthk_: could you paste the output of "stat /gnu/store/nh2j35psyyjpvlbv2yswwjx0b25klyk3-guile-2.0.11/share/guile/2.0/ice-9/boot-9.scm /gnu/store/nh2j35psyyjpvlbv2yswwjx0b25klyk3-guile-2.0.11/lib/guile/2.0/ccache/ice-9/boot-9.go"? <iyzsong>I update libtasn1 to 4.6 in 'core-updates', but it break a test of gnutls, with a report email sent to the gnutls and libtasn1 ML. If the full build of 'core-updates' start, I'll stop doing push packages updates, and better revert the libtasn1 update right? <civodul>iyzsong: yes; we can wait a bit longer for this issue to be resolved <civodul>maybe GnuTLS should be upgraded as well? <mark_weaver>anthk_: hmm, it's interesting that the *.scm file is indeed newer. the timestamps are not all zeroed out, as they should be. interesting. <anthk_>mark_weaver: ext4, under trisquel <civodul>on my machine, i have Epoch + 1 for both files <civodul>in local-store.cc: const time_t mtimeStore = 1; /* 1 second into the epoch */ <civodul>anthk_: could you try "sudo guix gc --verify=repair"? <civodul>this is going to take a long time though <mark_weaver>civodul: on my system they are both Epoch +1 as well. <anthk_>civodul: doesn't matter if it fixes it <civodul>anthk_: did you install from the binary tarball? <civodul>well, still, both should be set to 0 <civodul>we should fix the binary tarball though, for consistency <mark_weaver>find /gnu/store/nh2j35psyyjpvlbv2yswwjx0b25klyk3-guile-2.0.11 -exec touch --date=@1 {} + <anthk_>mark_weaver: with sudo privileges? <anthk_>now I am doing "guix pull" as unprivileged just to be sure <mark_weaver>civodul: in the next core-updates cycle, maybe we should change --mtime=@0 to something newer. maybe @1, or maybe even something in 1980 to avoid the difficulties with 'zip' and other software that doesn't like such old timestamps. what do you think? <mark_weaver>it would allow us to remove several workarounds currently in place <mark_weaver>e.g. the 'ensure-no-mtimes-pre-1980' phase in 'python-build-system'. <mark_weaver>and gnu/packages/patches/perl-autosplit-default-time.patch <mark_weaver>and maybe it would also avoid the annoying warnings from tar about implausibly old timestamps <karhunkynsi>what if someones CMOS battery runs out or something and their system thinks it's 1970 again <mark_weaver>ideally, our build container would make the clock deterministic <mark_weaver>but that's probably probably going a bit too far, and not easy (or efficient) to implement <civodul>mark_weaver: yeah @1 sounds good to me <civodul>i prefer to keep the zip workaround than to use a random date in the 1980s :-) <mark_weaver>things like @0 and @1 seem natural and fundamental in some way, but really the date is just as arbitrary. it's just an arbitrary date that was picked by somebody else long ago. <mark_weaver>to my mind, the posix epoch is an implementation detail that should buried beneath layers of abstraction and ignored in the stuff we build on top. <anthk_>thanks guix works, it's my only option to have mesa 11 without rebuilding it from git :p <mark_weaver>I think there is great value is choosing a date that is supported by all of the important date formats used within our system. <mark_weaver>and the format used within zip archives is an important date format, IMO <karhunkynsi>mark_weaver, i've been digesting your comments regarding full encryption and i'm confused. If i understand correctly i'm able to start the kernel within the encrypted partition. Is the problem then that initrd is unable to inherit/understand this environment? <mark_weaver>karhunkynsi: the kernel and initrd are loaded into memory by GRUB, which has its own code to access the encrypted filesystem. <mark_weaver>the code that runs within Linux (the kernel) has no access to that environment from GRUB <mark_weaver>so the initrd has to arrange to open the encrypted filesystem independently <karhunkynsi>i assume one could use a password file in the encrypted partition for this second open, so you don't need to type the password two times <mark_weaver>the first problem is that the initrd probably needs more kernel modules to handle the decryption <mark_weaver>and I guess maybe the initrd also needs to run "cryptsetup luksOpen" before trying to mount the root partition? I'm not sure. <karhunkynsi>This is a bit out of my league, but let me know if i can assist in any way. <mark_weaver>karhunkynsi: if you'd like to try implementing it, I would be glad to advise you on what needs to be done. <mark_weaver>the first step is to build guix from a git checkout, if you haven't already done so <karhunkynsi>i've got the code, and have been looking at a bit at the files you menioned previously <mark_weaver>this will allow you to make changes to it and later submit those changes to us <karhunkynsi>right, i'll get back to you when i'm up and running with this <mark_weaver>don't forget to pass --local-state-dir=/var to configure <mark_weaver>guix keeps an sqlite database and some other things in /var <mark_weaver>but localstatedir normally defaults to <prefix>/var, so unless <prefix> is the empty string, that won't be right <mark_weaver>it's important that the 'guix' you build from git uses the same sqlite database (and other local state) that your existing 'guix' is using. <mark_weaver>ah, well, in that case could you *could* put the sqlite database somewhere else, but I would strongly recommend always using /var <mark_weaver>e.g. the 'guix' package within 'guix' will always use /var, so if you want to use that package on your new system, the local state dir should be /var <karhunkynsi>would it be easier if i installed an unencrypted guixsd partition on the target computer? <mark_weaver>so the encrypted partition can later be expanded to use the whole disk <karhunkynsi>i have reserved 13GB at the end for other operating systems <karhunkynsi>can i then mount the encrypted partition and replace f.ex. initrd directly? <mark_weaver>from the unencrypted GuixSD system, I would build guix from source code, modify it to add support in the initrd for the encrypted root, and then use it to run "guix init" on the encrypted partition, and test. <mark_weaver>one note: "guix system init" will install a fresh grub that doesn't know about your unencrypted GuixSD install <karhunkynsi>i won't be adding it to libreboot at this time anyway, i'll just be manually booting it <mark_weaver>but you can still boot into the unencrypted GuixSD, using the 'configfile' command in GRUB to load the grub.cfg file from the unencrypted GuixSD partition. <mark_weaver>karhunkynsi: i recommend against running "make install" on GuixSD. instead, run it using 'pre-inst-env' (see the docs) <mark_weaver>civodul: at the top of that page, it says "This is a complete lists [...]". it should be "list" (singular) <karhunkynsi>civodul, maybe you could add a few newlines to the html code ;) <civodul>karhunkynsi: well it's not meant to be human-readable :-) <karhunkynsi>oh, i thought the free software movement was supposed to be a happy place, inspiring investigation and learning :P <karhunkynsi>i found a minor issue, after a fresh install and booting in to xfce the icons are barely working. But after going to settings->appearance and clicking around there they show up nicely <karhunkynsi>(i didn't notice if it was selecting a style or selecting already selected gnome icons) <mark_weaver>civodul: fwiw, I also think it would be good for our generated html to have newlines, and ideally even indented nicely <davexunit>newlines? like each paragraph of text wrapped in <p></p>? <davexunit>civodul: why do some monadic procedures use past tense verbs like 'built-derivations'? <mark_weaver>I wouldn't be surprised if this is contrary to the usual practice of minimizing things. <mark_weaver>I suppose if I worked as a paid web developer, clients would want to minimize the bandwidth <davexunit>mark_weaver: ohhh you mean the source code? sorry! <davexunit>I thought something was not pretty in the rendered html <mark_weaver>davexunit: well, it's not really source, because it's auto-generated, but the html, yes. <davexunit>just using 'source' to distinguish from the rendered thing <civodul>davexunit: the idea was to convey the functional meaning rather than the action <civodul>davexunit: probably not a good idea though <davexunit>civodul: okay. I'm writing a sort-of-monadic interface for one of my projects <mark_weaver>davexunit: indeed. for stallman.org, I sprinkled the sxml with string literals like "\\n " which is kind of gross. <davexunit>and I find myeslf having a hard time coming up with names. <mark_weaver>I would much rather sxml->xml to do that automatically <davexunit>mark_weaver: it wouldn't be too hard to add a pretty-printing mode. <civodul>mark_weaver: Guile code to generate pages at stallman.org, neat :-) <davexunit>yes, that is neat. didn't know about that. :) <amz3>it's seems like each time a new software needs a more recent version of a package, every package needs to be updated, is that correct? <davexunit>amz3: every package that depends on it gets rebuilt, yes. <amz3>this is can lead to problems <civodul>davexunit: naming is notoriously difficult ;-) <davexunit>amz3: but you see that it can work no other way, yes? <amz3>keep several version per software is a solution? <mark_weaver>amz3: I'm not quite sure I understand what you mean, but we certainly support multiple versions, and currently have multiple versions of selected packages. <amz3>so you say, that I can create a new package for a new version OR update the old package to the new version ? <mark_weaver>sometimes, we have a "fixed" (i.e. immutable) version of a package, to prevent too many rebuilds when the normal version of that package is updated. <mark_weaver>amz3: if I understand correctly, the answer is "yes", but you are speaking in a way that is too vague for me to understand clearly. <mark_weaver>but, for example, in gnu/packages/guile.scm, we have both 'guile-2.0' and 'guile-2.0/fixed'.. <mark_weaver>but the idea is to allow us to update 'guile-2.0' without rebuilding everything. <mark_weaver>that's because 'guile-2.0/fixed' is the one that is used as the basis for building packages, not 'guile-2.0' <moyamo>Hi, I've been interested in guix for some time now. I was wondering how guix handles updates to packages with a lot of dependencies. For example if bash updates do I need to redownload/rebuild all packages that depend on bash or will guix just dynamically link the existing packages to the new version of bash. <amz3>python's cffi changed the way, it works, now it requires to be able to load the dynamically linked library at build time <amz3>if dependencies did no change, you don't need to download it again <moyamo>So does guix differentiate between build dependencies and runtime dependencies? <mark_weaver>the runtime dependencies are automatically determined by scanning the build outputs for references to filenames in the store. <moyamo>How does it do this? I've seen it can be done for dynamically linked C programs, but how will it work for a python 'import' <mark_weaver>all files are scanned for strings of the form /gnu/store/<hash> <civodul>and for Python programs, packagers manually augment the set of run-time dependencies via the 'propagated-inputs' field <moyamo>So if runtime dependencies change, the program will need to be rebuilt. Since the program links directly to the guix store. <davexunit>if *anything* changes the hash of the package, it will be rebuilt. <mark_weaver>moyamo: yes, it is true that updating base packages is quite expensive for us. <mark_weaver>there is a mechanism to help with this called "grafting". <mark_weaver>the idea is that if we apply a security fix to bash, then all of the packages that depend on it are updated more cheaply as follows: each one is copied as-is, but with all references to the old bash rewritten to point to the new bash <mark_weaver>the cheaply-created updated packages have a new hash, as they must to preserve the immutability of the store and thus the needed reproducibility and roll-back features. <moyamo>That's cool. Does guix figure out when to graft automatically or does someone have to tell it to graph for a specific update. <mark_weaver>guix currently has an implementation of grafting, but unfortunately it's not quite right. <mark_weaver>and because of the reproducibility requirements, if it is told to graft, then it always grafts. <mark_weaver>it doesn't dynamically decide whether to graft, e.g. based on whether you already have a built version of the correct package that's not grafted. <mark_weaver>so, the idea is that if we have to apply a security update to glibc, we use a graft for our 'master' branch in git, to deploy the fix quickly, and then on another branch 'core-updates', we fix it without a graft, forcing a full rebuild. <moyamo>So users will get the full rebuild at a later date. <mark_weaver>but we can do that rebuild at our leisure and deploy only after it's fully rebuilt. <mark_weaver>so, iiuc, this is the way in which our current grafting implementation is deficient: <mark_weaver>a new libncurses is cheaply created by copying the old libncurses and rewriting references to the new libc. <mark_weaver>and a new mutt is created by copying the old mutt and rewriting references to the new libc. <mark_weaver>but this is not good enough. the new mutt must *also* have references to libncurses rewritten to point to the new libncurses <moyamo>Is it not possible to recursively graft the packages? <mark_weaver>more generally, we must rewrite references not only to the store items being grafted, but also to anything else that transitively depends on the store items being grafted. <mark_weaver>moyamo: it is possible, it just needs to be implemented correctly. <mark_weaver>it might not be that hard, I just haven't gotten around to digging into the current code <mark_weaver>I guess I was hoping that civodul would just fix it :) <mark_weaver>but he already does over half the total work on guix, so I can hardly ask him to do more :) <moyamo>Haha, okay. I wait in anticipation :) <karhunkynsi>mark_weaver, i'm up and running now. "configure" has finished successfully, and i've mounted the encrypted partition to /mnt <mark_weaver>first, you need to find out what kernel modules will be needed to mount the encrypted root filesystem <mark_weaver>and add them to 'linux-modules' in 'base-initrd' in gnu/system/linux-initrd.scm <mark_weaver>and the other thing is to modify 'mount-root-file-system' in gnu/build/linux-boot.scm to do what's needed to mount the encrypted filesystem. <mark_weaver>which maybe involves running "cryptsetup luksOpen", but I'm not sure. <mark_weaver>hmm, so 'cryptsetup' and its dependencies will also need to be added to the initrd. <karhunkynsi>one thing. Could different versions be a problem? Both the encrypted and unencrypted guix are now on the usb installation version. But the source is bleeding-edge i would presume <mark_weaver>ah, so 'helper-packages' also needs to be updated. it's just below 'linux-modules' <mark_weaver>karhunkynsi: it shouldn't matter, since the encrypted one is going to be a fresh install <mark_weaver>but still, you might want to run "./pre-inst-env guix system reconfigure <OS-CONFIG>" from your git checkout to update the unencrypted install to the latest versions. <karhunkynsi>i get a lot of "note: source file ... newer than compiled" <civodul>mark_weaver: luks-device-mapping has all the code to do that <civodul>it may be that that simply populating 'mapped-devices' would do the right thing <mark_weaver>karhunkynsi: sorry, you need to build it before running it! <civodul>i do that, but only for my /home partition <karhunkynsi>for running "make" i had to install texinfo as well. I don't think that was mentioned as a requirement in the manual <mark_weaver>karhunkynsi: it's not needed when building from the tarball <civodul>the theory is that something similar should work for "/" as well <civodul>although there are probably a few gotchas <mark_weaver>civodul: ah yes, I see now that the code is in place <mark_weaver>the kernel modules still need to be added manually, it seems. <mark_weaver>but it looks to me like cryptsetup should, in theory, be automatically added to the initrd, and invoked to open the root filesystem if the config is right. <mark_weaver>if you declare the root filesystem to be a mapped device <civodul>yes, cryptsetup and its deps will automatically be added to the initrd <civodul>the modules need to be added "by handle" currently, indeed <mark_weaver>karhunkynsi: see the config included in that bug report <mark_weaver>it might be a bit out of date, but maybe still of some use to you <mark_weaver>the 'initrd', 'mapped-devices' and 'file-systems' could be taken from the bug report and spliced into a more modern configuration <mark_weaver>civodul: I have an idea of what's wrong here: what handles creating /dev/mapper/main at this early stage in the boot? <mark_weaver>civodul: at this point /dev is not yet mounted as a devtmpfs filesystem <mark_weaver>I don't know off hand what is responsible for creating /dev/mapper/main, but whatever it is, I guess it's not set up yet when we mount the root partition. <civodul>mark_weaver: i think cryptsetup creates that node <mark_weaver>I'm not really set up at the moment to try experimenting with an encrypted root <civodul>karhunkynsi: if you could give it a try, that'd be great :-) <mark_weaver>but my suspicion is that cryptsetup doesn't create the /dev/mapper directory or the /dev/mapper/main node directly. <mark_weaver>I suspect that cryptsetup rather tells device-mapper in the kernel to create a new mapping, and then the kernel somehow arranges for /dev/mapper/main to appear, by some devtmpfs and/or udev magic. <mark_weaver>hopefully devtmpfs, since udev obviously isn't yet running at this point <karhunkynsi>how can i reconfigure for a different partition? I thought i would do "guix system reconfigure", but it doesn't accept a location argument like "guix system init" <mark_weaver>looks like 'cryptsetup' runs another program 'dmsetup' <mark_weaver>karhunkynsi: you can't. use 'guix system init' to install to a new partition. <mark_weaver>reconfigure is for updating an existing root partition that already has guixsd on it <mark_weaver>regarding 'cryptsetup' and 'dmsetup', actually it looks like it only uses dmsetup for the tests. <mark_weaver>civodul: fwiw, the string "mknod" does not occur anywhere in the cryptsetup source code <amz3>once i update the packages I need, I must run `guix refresh' to know whether something is broken? <mark_weaver>what do you mean by "update the packages I need"? do you mean change their package descriptions in the guix source code? or do you mean by "guix package -u"? can you be more clear? <amz3>I changed the version of some packages (cffi, xfficb and cairoffi), but that required to change caircffi to take into account the new way cffi works <amz3>I mean I did not only change the version number of cairocffi <mark_weaver>guix refresh -l can be used to find an approximation of the set of packages that would have to be rebuilt after changing a given package <mark_weaver>it can't determine whether something will become broken by your update <mark_weaver>"guix package -u" can be used to update every package in your profile, so it can be useful after updating your guix or making changes to packages. <tronk>anybody know if GuixSD supports encrypted drives yet? <karhunkynsi>well, it's certainly a step forward. I'm asked for passphrase in the GuixSD boot process now. But it won't accept my passphrase, and i get the same output whether i type correct* or something wrong <mark_weaver>tronk: it supports encrypted volumes, but not currently an encrypted root partition. your timing is good; we were just now talking about getting that working <tronk>ok cool. I've got a /home partition from another OS that's encrypted with LUKS and I want to be able to mount it from GuixSD. also, I'm having a weird bug where all the shutdown/restart buttons except logout are greyed out. anybody seen this? <karhunkynsi>(* i have a { in the passphrase in another keyboard layout than i'm used to, but it should be good) <mark_weaver>karhunkynsi, civodul: well, I'm fairly sure that cryptsetup doesn't create /dev/mapper/* directly. that seems to depend on having the devtmpfs mounted on /dev. in our case, /dev is not yet mounted when the root partition is mounted. <mark_weaver>tronk: we are still missing some infrastructure pieces that would make those buttons work. <tronk>awww ok. I suppose that's why "reboot now" does nothing in a terminal lol <mark_weaver>but using your existing encrypted /home partition should be fine, although GuixSD requires setting various environment various from ~/.bash_profile. <mark_weaver>I guess it should be possible to add some code there to detect whether GuixSD is currently running, and if so, use different paths. <mark_weaver>but sharing /home between GuixSD and non-GuixSD is, I think, a path not yet well travelled. <karhunkynsi>after inputting passphrase i get these messages: device-mapper: table: 253:0: crypt: Error allocating crypto tfm device-mapper: ioctl: error adding target to table device-mapper: reload ioctl on failed: No such file or directory Failed to open temporary keystore device. <karhunkynsi>mark_weaver, does this match up with what you're seeing? <mark_weaver>karhunkynsi: that is consistent with my theory, yes. <mark_weaver>namely that /dev needs to be mounted as a devtmpfs before an encrypted root can be mounted. <mark_weaver>currently, we use 'make-essential-device-nodes' in gnu/build/linux-boot.scm, to populate /dev with an ad-hoc collection of nodes. it is used to populate both /dev before mounting the root partition, and /root/dev after mounting the root partition. <mark_weaver>I guess that it should, instead, mount a devtmpfs pseudo-filesystem instead. <luk>Hello there. I am just configuring my second guix system and I am stuck beacuse I want / to be encrypted, so guix tells me it failed to install GRUP because /mnt/boot ist not readable by GRUB on boot. That’s fair, beacause it isn’t. But I fail to find any documentation on how to tell GRUB the --boot-directory flag to be /boot (where I mounted my boot partition. <luk>any help would be very welcome :) <mark_weaver>luk: we don't currently support a root partition, although we happen to be working on that right now <tronk>sudo reboot & sudo halt didn't do anything <mark_weaver>luk: sorry, we don't currently support an *encrypted* root partition, I mean :) <luk>yeah, got that allright. :) <mark_weaver>tronk: hmm. well, I don't use sudo, so I guess I can't assert that it works from personal experience. I typically run those commands from a root login from a text console. <mark_weaver>(and I'm not going to try "sudo reboot" right now, because, well, I don't want to reboot :) <tronk>that's what i'm doing, running the commands as root from a terminal. i tried "sudo reboot" "sudo halt" "reboot" "halt" and "shutdown" to no avail <karhunkynsi>tronk, to shut down or reboot i have closed desktop and hit Ctrl-Alt-F1 and done it from there <DusXMT>Also a possibility: $ su - # halt <DusXMT>ACTION doesn't use sudo ever since he had issues with paths this one time long ago :) <mark_weaver>tronk: maybe some dmd service is stuck in its 'stop' action. <mark_weaver>karhunkynsi: so, I guess maybe the answer is to mount devtmpfs on /dev from 'mount-essential-file-systems' (in gnu/build/linux-boot.scm) <mark_weaver>and maybe also remove the call to (make-essential-device-nodes) that has no arguments (line 389 of linux-boot.scm) <tronk>mark_weaver: yes I suppose I can. what should I include in the email? <tronk>karhunkynsi: by "from there" do you mean the login screen? <karhunkynsi>on the login screen (or wherever), hit Ctrl-Alt-F1, then you get another console, log in there and sudo halt/reboot <mark_weaver>tronk: I guess just mention that you're running GuixSD and that "reboot" and "halt" don't do anything, and maybe include your OS configuration file. <mark_weaver>karhunkynsi: in the definition of 'mount-essential-file-systems', duplicate the three lines dealing with "proc", and then change one of them to mount /dev instead <mark_weaver>and the last argument to 'mount' should be "devtmpfs" <mark_weaver>and delete the (make-essential-device-nodes) call and try again <mark_weaver>you may need to wipe the contents of the encrypted partition before running "guix system init" again. I don't remember off-hand how well "guix system init" copes with having to overwrite things. <mark_weaver>I wonder if we need to add a kernel module to the initrd to enable mounting devtmpfs early <civodul>'guix system' doesn't touch partitions other than / <civodul>mark_weaver: i think devtmpfs is built-in, so we could mount it early <civodul>but then we still need to populate it <mark_weaver>civodul: I think the kernel handles populating it, no? <civodul>i think it's usually udev doing that <civodul>i wonder if there's a difference between devtmpfs and tmpfs <mark_weaver>civodul: I looked at the kernel code, and there's definitely code in there for creating directories and nodes upon request <tronk>mark_weaver, you're fkkin smart <civodul>i guess it's an area i don't know much about yet :-) <mark_weaver>tronk: eh, I've accumulated a lot of knowledge, just like everyone else, I just happen to know about these particular things. <mark_weaver>(mainly because it's what I'm motivated to spend time on) <mark_weaver>I have many other embarrassing areas of ignorance, because I focus so much on computers :) <karhunkynsi>do you know the airspeed velocity of an unladen swallow? <mark_weaver>karhunkynsi: I'll be curious to know whether mounting devtmpfs early fixes the problem <yrns`>Why do I get very few substitutes when installing packages? Most of the inputs have to be built. Is hydra slightly out of date? <karhunkynsi>yeah, i'll let you know. It's still doing the guix system init <mark_weaver>yrns`: did you run "guix pull" or equivalent? is your guix up-to-date ? <mark_weaver>sometimes network problems can cause failures and consequent fallback to building from source. <mark_weaver>sorry that's not a great answer; there's definitely room for improvement here <mark_weaver>karhunkynsi: in most cases, debugging changes to the initrd is easy, because you can just use 'guix system reconfigure' which is relatively fast. <mark_weaver>and if it fails, you can just choose an earlier generation from the grub manu <mark_weaver>karhunkynsi: whenever you want to run the uninstalled 'guix' from your git repo, prefix the commands with ./pre-inst-env <mark_weaver>otherwise, you'll use the older, unmodified 'guix' from GuixSD <mark_weaver>it basically just sets some environment variables (mostly paths) to ensure that the code in the source tree is used instead of looking in <prefix> <karhunkynsi>will ./pre-inst-env guix system init ... be faster the next time around? <mark_weaver>most of the work went into downloading/building the needed components in /gnu/store <karhunkynsi>(scandir "/dev/mapper") shows ".", ".." and "control" <karhunkynsi>can we put something obvious in the code, so we see my build process etc. is good? <mark_weaver>karhunkynsi: the fact that /dev/mapper exists makes it reasonably clear that you successfully mounted /dev <karhunkynsi>mapper had a lot of company in there, lots of ttyX and such <mark_weaver>you could read /proc/mounts to verify that /dev is mounted, but I don't think there's a need <mark_weaver>I guess we should try running the cryptsetup command again, manually <karhunkynsi>some more error messages there: ERROR: In procedure scm-error: ERROR: pre-mount actions failed <mark_weaver>karhunkynsi: (scandir "/gnu/store" (cut string-contains <> "cryptsetup")) <karhunkynsi>it's complaining about possibly unbound variable scandir <mark_weaver>sorry, the lack of readline in that REPL is a pain, I know <karhunkynsi>is that what makes it possible to arrow-up for previous commands? <mark_weaver>maybe we should at least have an option to add that to the initrd, for debugging purposes <mark_weaver>actually, it's possible that it can be loaded into that REPL without much fuss, now that I think about it. <mark_weaver>karhunkynsi: okay, now: (define cryptsetup (string-append "/gnu/store/" $1 "/sbin/cryptsetup")) <mark_weaver>karhunkynsi: okay, now: (define cryptsetup (string-append "/gnu/store/" (car $1) "/sbin/cryptsetup")) <mark_weaver>(system* cryptsetup "open" "--type" "luks" <source> <target>) <mark_weaver>where <source> and <target> are substituted with the appropriate strings <mark_weaver>karhunkynsi: yes, I think <source> should be something like "/dev/sda<N>" <karhunkynsi>the messages with wrong password to this last command is equal to the one in the boot process <mark_weaver>it appears that the guile-readline library is not on the initrd. <karhunkynsi>in addition to messages i've told about earlier it also spams: device-mapper: remove ioctl on temporary-cryptsetup-116 failed: No such device or address <mark_weaver>karhunkynsi: here's an idea: boot back into the unencrypted GuixSD system, mount the encrypted partition, and then use "lsmod" to see the set of loaded modules. <mark_weaver>look through the modules for things that look like crypto or hash modules <mark_weaver>or anything that looks like it might be relevant to mounting an encrypted volume <mark_weaver>and then make sure those are all added to your OS config <mark_weaver>the reason I asked you to first mount the encrypted partition is to make sure that all of the needed kernel modules are loaded. <mark_weaver>after that, we just run 'lsmod' from the unencrypted system. <mark_weaver>look in /run/current-system/kernel/lib/modules/*/kernel/crypto/ <mark_weaver>but if you look in that directory I just typed, you'll see a list of all the available crypto modules <mark_weaver>if any of those are in the "lsmod" output, please add them as well <mark_weaver>I'd rather take the risk of adding more than we need at first, and then trim the list of added modules down. <mark_weaver>(the only reason I say "might" is because I have a vague recollection of some magic that makes these interchangeable, but I'm not sure) <mark_weaver>karhunkynsi: ah, so 'lsmod' output "dm_crypt", but the kernel module file is named "dm-crypt.ko" ? <mark_weaver>well, the filename is what's needed in the config file <karhunkynsi>same errors basically, and dropped to a guile prompt <karhunkynsi>i entered wrong passphrase but that shouldn't be a problem i think <mark_weaver>maybe we need to call 'cryptsetup' in a loop to handle this case more gracefully <karhunkynsi>no, it has never said that. It just shows some errors <mark_weaver>karhunkynsi: when you mount this partition from GuixSD, what is your precise "cryptsetup" command? <mark_weaver>I see that "cryptsetup" has "--verbose" and "--debug" options <mark_weaver>I think we should run it manually with those options <karhunkynsi>previosly it was "temporary-cryptsetup-116" i think, other than that it's the same always <karhunkynsi>i can't make sense of it, maybe it tells you something <karhunkynsi>nevermind, it was just a random hit when i did a search <mark_weaver>well, apparently that error message indicates a missing crypto module. <mark_weaver>can you double check to make sure you didn't miss a crypto module in the output of "lsmod" from GuixSD (after mounting the encrypted partition) <karhunkynsi>i ordered them alphabetically and looked at them one by one, but i may have missed one <mark_weaver>alternatively, we could try running "cryptsetup" manually from the initrd REPL, but adding "--verbose" or "--debug" to the argument list, and hope that it gives more clues. <karhunkynsi>i'll just run through the list one more time, then we can do that <mark_weaver>can you show me the output of "lspci" while the encrypted partition is mounted? <karhunkynsi>that should be it, there was 73 modules in lsmod before mounting, 76 after <karhunkynsi>so, add xts, retry, and do some cryptsetup --verbose --debug then <civodul>karhunkynsi: so you just booted on an encrypted root? <civodul>ACTION thinks karhunkynsi & mark_weaver deserve big kudos :-) <rekado>karhunkynsi: is this an encrypted partition with LVM? <karhunkynsi>in the end i think we just added three modules: arc4, gf128mul and xts. And added devtmpfs to linux-boot.scm. <civodul>he's more interested in the joy of debugging ;-) <civodul>iyzsong, mark_weaver: i merged master in core-updates, so to me it's ready to go, except for that libtasn1 issue <civodul>iyzsong, mark_weaver: maybe we should revert the libtasn1 upgrade <karhunkynsi>yeah, maybe he's already involved in debugging something else <karhunkynsi>i deleted everything on my encrypted partition and reinitialized it with only modules: dm-crypt.ko and xts.ko. And it worked. <paroneayea>simonft is a friend of mine, volunteer sysadmin on mediagoblin, does other cool things, is interested in guix and deployment stuff <freddy>hey guys, is there a place I can go for a basic intro to Guix? I was using it for a day before I found out that the programs I installed were only installed for one user rather than the whole system. I kinda feel like that should have been on the first page of the how-to but it's not. Is there a good source I can go to for familiarity? <davexunit>both pages talk about per-user package installation <simonft>is python3 not packaged for guix yet? <freddy>that's the kindof stuff I'm talking about, davexunit. I looked at the man guix page and it directed me to info guix, which wouldn't run <davexunit>freddy: you must not have INFOPATH set right <karhunkynsi>how do you change to 'root' user when logged in as a normal user? <karhunkynsi>if i log in as root from login screen there's no password, but i'm unable to switch to it from terminal <davexunit>an unprivileged user cannot elevate privileges without a privileged process doing it for you. <davexunit>is sudo installed and are you in the "wheel" group? <karhunkynsi>"sudo su" gives a password challenge, that doesn't accept empty or my user's password <mark_weaver>sudo -s will want your normal user password, su - will want the root password <simonft>Is the source code for a package cached anywhere in the guix build system? Do builds fails if the source system is offline? <davexunit>simonft: tarballs are kept in the store, yes. <mark_weaver>simonft: if you build from source on your own machine, then yes <mark_weaver>if you download binary substitutes, then probably not <mark_weaver>"guix build -S <package>" will download the source code <mark_weaver>or just tell you where it is, if it's already in the store <simonft>this means that guix is depending on upstream to keep their source in the same place, and to never change an already uploaded source? <mark_weaver>simonft: if you don't use substitutes from hydra, then the answer is "yes" <davexunit>ACTION notices that python 3.5.0 was released <mark_weaver>however, if you enable substitutes from hydra, then the source is effectively cached there and will be downloaded from there. <mark_weaver>so most users are effectively isolated from that problem in practice <simonft>I was thinking more from a guix developer standpoint that would be annoying. <karhunkynsi>i'm unable to lock the root account, shouldn't it be possible? "sudo passwd --lock root" <simonft>I'd imagine it's rarely an issue now, but I'm wondering if it's going to be an issue if someone wants to create another distribution based off guix in the future and pulls in older versions and rebuilds everything. <mark_weaver>simonft: a few of us build everything from source, and we tend to discover those issues and fix them eventually <mark_weaver>but it's true that the relatively rare testing of those URLs means that sometimes such stale URLs persist for a while before they are noticed. <simonft>mark_weaver: are you able to go back and fix old versions of the url? <simonft>actually, I don't know guix's release system yet <mark_weaver>also, even without modifying the package recipe, if you can find the source somewhere with a matching sha256 hash, you can manually import it into your store. <karhunkynsi>if i try to log in as root from login screen, fail, then login as my user i get to "Window Maker" rather than XFCE <mark_weaver>or use a different program to download and then: guix download file://<absolute-file-name> <mark_weaver>once it's in the store, then the next time you try to build, it will already be there so no need to download <paroneayea>to have a mirror of all things mainline guix packages <mark_weaver>having said this, it's obviously better to fix the package definition and send us a patch :) <paroneayea>it would maybe useful for free software history too <paroneayea>might be easier once there's something like gnunet integration :) <paroneayea>davexunit: right, though that doesn't keep around all old versions of packages guix has packaged <paroneayea>davexunit: and that might be nice to zoom back in time to 3 years ago <paroneayea>and be like, "hey, here's a profile with the free software universe of 2012!" <davexunit>we *could* protect source derivations from gc <mark_weaver>indeed, we could do that, if we had more disk for hydra <paroneayea>guix is resource-strapped, but hopefully as adoption grows <paroneayea>it'll be easier to take on noble tasks like that :) <mark_weaver>yeah, obviously it would be a nice service to provide <simonft>I guess this is less of an issue with a rolling release. <simonft>Is a stable branch something that people are interested in working on in the future? <davexunit>it's not an issue for normal users, and even most developers. <paroneayea>simonft: well it's still relevant I think because <mark_weaver>simonft: yes, I'd like to provide stable branches at some point <paroneayea>simonft: one feature of guix is you can run some software that's in a much more old version of guix and newer stuff at the same time <paroneayea>you can literally run multiple profiles with multiple guix profiles at the same time <paroneayea>so you can run some software from 2 releases behind if you really want to <simonft>paroneayea: right, but it's rare that you're going to want to rebuild old versions since the binary versions are already built. <simonft>although, it's nice to be able to verify old builds. <paroneayea>xanthippe: yes, in fact the guix devs have an active call for help on that <davexunit>xanthippe: disks: yes, money: not at this moment. <paroneayea>xanthippe: thanks for considering your donation! <davexunit>we don't have anything setup to handle monetary donations in a transparent way. <mark_weaver>xanthippe: actually, we can accept monetary donations via the FSF, I believe. <paroneayea>it would be good for guix to get set up with the fsf as a fiscal sponsor <mark_weaver>it would certainly help us acquire new hardware for the build farm <paroneayea>mark_weaver: yes you should email john sullivan about it, I talked to him and he said if one of the main guix devs was interested in it, he would be happy to work with you all <davexunit>that's excellent news. what do we need to do to make this official? waiting on FSF or something we need to do? <mark_weaver>first, I don't really want to handle the money myself. the idea is that the FSF would buy hardware for us, and if someone wants to donate to that cause, I can tell johns in advance and we can work it out. <mark_weaver>I guess if we wanted something more streamlined, that would require more discussion <mark_weaver>so the FSF would accept the money and then buy the equipment for us. <mark_weaver>or, people can just order equipment and have it shipped to the FSF. <davexunit>mediagoblin, octave, and some others have directed donation pages setup with the FSF. <davexunit>might be nice to have in the future if we ever decide to fundraise. <davexunit>just making sure we all know it's an option :) <simonft>davexunit: paroneayea mentioned that you're working to get nixos setup to work in containers? <davexunit>no cgroups or network virtualization support yet, but the most important stuff is in place.