IRC channel logs


back to list of logs

<karhunkynsi>yes, there are two in /etc/configuration
<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>oh, he already left...
<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
<davexunit>are the locales actually there?
<davexunit>I install the glibc-utf8-locales package
<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?
<mark_weaver>how are you launching guix-daemon?
<spwx>mark_weaver: i used the systemd service file
<mark_weaver>okay. alas, I don't know much about systemd
<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
<davexunit>surely systemd has a directive for htat
<mark_weaver>I would guess so
<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.
<mark_weaver>but setting LOCPATH would be preferable.
<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?
<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>maybe root's profile
<mark_weaver>well, there are arguments for both sides.
<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>using a profile simplifies this, obviously
<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!
<mark_weaver>spwx: sounds 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.
<mark_weaver>only "guix gc" removes things 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>search for 'git-fetch' in gnu/packages/*.scm
<spwx>ok thanks!
<mark_weaver>we don't currently have a backend for bazaar, but we have support for git, svn, and cvs.
<mark_weaver>it's not hard to add more
<mark_weaver>however, by policy, we usually prefer to build from tarballs
<spwx>that makes sense
<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
<mark_weaver>to authenticate the downloads
<spwx>Sounds very cool
<spwx> guix environment emacs is installing the linux kernel? is that right?
<spwx>oh sorry lol
<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.
<sneek>Will do.
<mark_weaver>sneek: botsnack
<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.
<mark_weaver>rekado: can you post to the ML about it?
<civodul>Howdy, Guix!
<mark_weaver>hi civodul!
<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_: what error?
<mark_weaver>anthk_: blocks tor uses, which includes me. can you use a different paste site please?
<civodul>mark_weaver: good point
<civodul>anthk_: such as
<civodul>argh, cherry-picked wrong commit
<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?
<anthk_>civodul: I think not
<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.
<mark_weaver>anthk_: what kind of file system is /gnu/store on?
<anthk_>mark_weaver: ext4, under trisquel
<mark_weaver>s/timestamps/modification times/
<civodul>on my machine, i have Epoch + 1 for both files
<mark_weaver>civodul: why Epoch + 1 and not just Epoch?
<civodul>i wonder!
<civodul>in const time_t mtimeStore = 1; /* 1 second into the epoch */
<anthk_>mark_weaver: any fix?
<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
<mark_weaver>I wonder how this happened
<civodul>anthk_: did you install from the binary tarball?
<anthk_>civodul: yes
<mark_weaver>ah, yes, of course!
<civodul>well, still, both should be set to 0
<civodul>we should fix the binary tarball though, for consistency
<mark_weaver>anthk_: try this:
<mark_weaver>find /gnu/store/nh2j35psyyjpvlbv2yswwjx0b25klyk3-guile-2.0.11 -exec touch --date=@1 {} +
<mark_weaver>that should reset the timestamps
<anthk_>mark_weaver: with sudo privileges?
<mark_weaver>anthk_: yes
<anthk_>it works
<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>karhunkynsi: good question!
<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>some other date would not seem good
<civodul>i prefer to keep the zip workaround than to use a random date in the 1980s :-)
<mark_weaver>hmm, I may raise this on the ML.
<mark_weaver>I think I disagree.
<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
<mark_weaver>given its widespread use, e.g. within python eggs.
<mark_weaver>anthk_: ah, good!
<mark_weaver>glad to hear it :)
<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>oh, ok
<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>karhunkynsi: yes, that should be possible
<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>thanks, i better understand the problem now.
<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>I expect it is not difficult
<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>sorry, I meant --localstatedir=/var
<karhunkynsi>ok, i'll look into what that means
<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.
<karhunkynsi>i was planning on building from another system
<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>yeah, I think so
<mark_weaver>and then you can remove it later
<mark_weaver>so maybe put it at the end :)
<mark_weaver>(of the disk)
<mark_weaver>so the encrypted partition can later be expanded to use the whole disk
<mark_weaver>s/whole/rest of/
<karhunkynsi>i have reserved 13GB at the end for other operating systems
<mark_weaver>ah, perfect
<karhunkynsi>experimenting and such
<karhunkynsi>can i then mount the encrypted partition and replace f.ex. initrd directly?
<karhunkynsi>is that a good approach?
<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>sorry, I meant "guix system init"
<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: ah yes, you're using Libreboot.
<mark_weaver>so nevermind
<mark_weaver>karhunkynsi: i recommend against running "make install" on GuixSD. instead, run it using 'pre-inst-env' (see the docs)
<civodul>mthl: look at the nicely rendered Texinfo at :-)
<civodul>see emacs-debbugs for example
<mthl>This is nice indeed :)
<mark_weaver>civodul: very nice!
<mark_weaver>civodul: at the top of that page, it says "This is a complete lists [...]". it should be "list" (singular)
<civodul>oops indeed
<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)
<civodul>karhunkynsi: sounds similar to
<mark_weaver>civodul: fwiw, I also think it would be good for our generated html to have newlines, and ideally even indented nicely
<mark_weaver>it's not a high priority though
<davexunit>newlines? like each paragraph of text wrapped in <p></p>?
<mark_weaver>davexunit: hmm, dunno!
<davexunit>civodul: why do some monadic procedures use past tense verbs like 'built-derivations'?
<mark_weaver>for <>, which is generated from a guile script using sxml, I took pains to add newlines and indentation to make the html source look nice.
<mark_weaver>I wouldn't be surprised if this is contrary to the usual practice of minimizing things.
<mark_weaver>davexunit: do you disagree? :)
<amz3>is frederico around?
<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
<davexunit>sxml->xml doesn't have a pretty printer
<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, 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, neat :-)
<davexunit>yes, that is neat. didn't know about that. :)
<mark_weaver>it's an MP3-podcast --> Vorbis-podcast converter.
<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.
<davexunit>mark_weaver: neat hack :)
<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>at present, they are synonyms
<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'
<amz3>it makes sens
<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>moyamo: the latter
<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>moyamo: yes
<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>or built time dependencies.
<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>moyamo: it has to be told to graft.
<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.
<civodul>yeah, this must be improved
<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>suppose a new glibc is grafted
<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 :)
<mark_weaver>(measured in number of commits)
<civodul>moyamo: see for an overview
<karhunkynsi>mark_weaver, i'm up and running now. "configure" has finished successfully, and i've mounted the encrypted partition to /mnt
<mark_weaver>karhunkynsi: great
<mark_weaver>so, there are two changes needed
<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
<karhunkynsi>ok, i'll see what i can find
<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.
<mark_weaver>e.g. there are security updates
<karhunkynsi>ok, i'll do that
<karhunkynsi>i get a lot of "note: source file ... newer than compiled"
<mark_weaver>karhunkynsi: oh wait.
<mark_weaver>karhunkynsi: you haven't run "make" yet?
<civodul>mark_weaver: luks-device-mapping has all the code to do that
<mark_weaver>civodul: ah!
<karhunkynsi>mark_weaver, no
<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
<civodul>see also
<mark_weaver>civodul: ah, interesting
<karhunkynsi>should i do "make", but not "make install"?
<karhunkynsi>you advised not to use "make install"
<mark_weaver>karhunkynsi: right
<mark_weaver>karhunkynsi: hmm, it seems that there's code you can use that I didn't know about. see
<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
<karhunkynsi> could have mentioned it
<mark_weaver>ah, you're right, it is missing there.
<mark_weaver>thanks for letting us know
<karhunkynsi>sure :)
<civodul>FWIW my config with an encrypted /home:
<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
<karhunkynsi>so, that would be with just with a proper config?
<mark_weaver>the kernel modules still need to be added manually, it seems.
<karhunkynsi>i haven't done the mapped-devices thing
<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
<mark_weaver>but see the bug report cited above
<karhunkynsi>i'll let "make" finish, then try this
<civodul>yes, cryptsetup and its deps will automatically be added to the initrd
<civodul>the modules need to be added "by handle" currently, indeed
<civodul>*by hand
<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
<karhunkynsi>what about "(define %linux-modules" ?
<mark_weaver>karhunkynsi: yeah, keep that too
<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>and of course udev is not yet running
<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
<civodul>did you try it?
<mark_weaver>I'm not really set up at the moment to try experimenting with an encrypted root
<civodul>yeah me neither
<civodul>we'd need more tooling
<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.
<karhunkynsi>i am, but i'm not very good at this ;)
<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
<mark_weaver>obviously my knowledge on this area is weak :)
<mark_weaver>ACTION looks at the cryptsetup source
<mark_weaver>ah, I see a potential problem.
<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.
<karhunkynsi>won't this redo the whole installation?
<mark_weaver>it's a new root 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>amz3: no
<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.
<mark_weaver>tronk: "sudo reboot" or "sudo halt"
<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.
<karhunkynsi>ok, good
<mark_weaver>namely that /dev needs to be mounted as a devtmpfs before an encrypted root can be mounted.
<mark_weaver>give me a few minutes to find out the next step
<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
<luk>ok, thanks mark
<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
<mark_weaver>tronk: interesting
<DusXMT>Also a possibility: $ su - # halt
<DusXMT>ACTION doesn't use sudo ever since he had issues with paths this one time long ago :)
<karhunkynsi>oh, sudo reboot works in a terminal for me
<mark_weaver>tronk: maybe some dmd service is stuck in its 'stop' action.
<mark_weaver>tronk: can you email about it?
<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)
<karhunkynsi>i don't know how to write that code
<karhunkynsi>remove i can do though
<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.
<karhunkynsi>(the desktop/login screen is at Ctrl-Alt-F7)
<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>change (scope "proc") to (scope "dev")
<mark_weaver>and the last argument to 'mount' should be "devtmpfs"
<mark_weaver>and delete the (make-essential-device-nodes) call and try again
<karhunkynsi>got it
<karhunkynsi>then: ./pre-inst-env make install ?
<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>karhunkynsi: no
<mark_weaver>karhunkynsi: ./pre-inst-env guix system init ...
<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
<mark_weaver>civodul: yes, they are definitely different
<civodul>ah ok
<tronk>mark_weaver, you're fkkin smart
<mark_weaver>e.g. see
<civodul>i guess it's an area i don't know much about yet :-)
<mark_weaver>devtmpfs is sort of "devfs light"
<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>I have *no* idea :)
<mark_weaver>but I recognize the quote, of course :)
<mark_weaver>african or european? :)
<karhunkynsi>WHAT, i don't know that. AAAAH
<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`: no, it should be mostly up-to-date now.
<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>when that happens, best to abort and try again
<mark_weaver>sorry that's not a great answer; there's definitely room for improvement here
<mark_weaver>lots to do
<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>but in this case, it's kind of a pain to debug this
<mark_weaver>I wonder if there's a better way
<karhunkynsi>is that also with ./pre-inst-env ?
<karhunkynsi>ah, i see
<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
<karhunkynsi>is that a binary in the source tree then, or?
<mark_weaver>it's a shell script in the source tree
<karhunkynsi>the guix.scm?
<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?
<karhunkynsi>it's taking a pretty lon.... and it's done
<karhunkynsi>hmf, i must rerun as root :/
<mark_weaver>ah yes
<mark_weaver>well, most of the work should be cached
<mark_weaver>next time should be faster
<karhunkynsi>looks like it, it's doing a lot of copying now
<karhunkynsi>previously it was downloading a lot
<karhunkynsi>ok, done
<karhunkynsi>then reboot i guess
<mark_weaver>most of the work went into downloading/building the needed components in /gnu/store
<mark_weaver>ACTION crosses fingers
<karhunkynsi>i get the same errors as before
<mark_weaver>does it leave you at a guile prompt?
<karhunkynsi>maybe i did something wrong when building
<karhunkynsi>do you want me to try some commands there?
<mark_weaver>yes, give me a minute please
<mark_weaver>karhunkynsi: please type: (use-modules (ice-9 ftw))
<mark_weaver>and then (scandir "/dev")
<karhunkynsi>will do
<mark_weaver>is "mapper" in there?
<karhunkynsi>is it possible to switch to dvorak here?
<karhunkynsi>(scandir "/dev/mapper") shows ".", ".." and "control"
<karhunkynsi>so not "guix" as i specified in the config
<karhunkynsi>can we put something obvious in the code, so we see my build process etc. is good?
<mark_weaver>sure, you could output a message
<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
<karhunkynsi>no, it's fine
<mark_weaver>well, I think this step was still needed.
<karhunkynsi>i thought maybe nothing happened
<mark_weaver>but there seems to be another problem as well
<mark_weaver>hmm, how best to debug this?
<mark_weaver>I guess we should try running the cryptsetup command again, manually
<karhunkynsi>maybe it's something near mapped-device
<mark_weaver>are you still at the guile repl?
<karhunkynsi>hang on
<karhunkynsi>i'll boot into it again
<karhunkynsi>i'm there
<karhunkynsi>some more error messages there: ERROR: In procedure scm-error: ERROR: pre-mount actions failed
<mark_weaver>ah, that's consistent with an error in 'cryptsetup'
<mark_weaver>give me a minute...
<mark_weaver>karhunkynsi: (use-modules (srfi srfi-26))
<mark_weaver>karhunkynsi: (scandir "/gnu/store" (cut string-contains <> "cryptsetup"))
<mark_weaver>does it output a directory name within parentheses?
<karhunkynsi>it's complaining about possibly unbound variable scandir
<mark_weaver>ah, (use-modules (ice-9 ftw))
<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>karhunkynsi: yes, command history and editing
<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>ACTION tries
<karhunkynsi>yes, it output: $1 = ("5vp..-cryptsetup-1.6.1")
<mark_weaver>karhunkynsi: okay, now: (define cryptsetup (string-append "/gnu/store/" $1 "/sbin/cryptsetup"))
<mark_weaver>oh, sorry
<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
<karhunkynsi><target> will be like "guix" i guess?
<karhunkynsi>which will make /dev/mapper/guix
<mark_weaver>maybe. honestly, I'm not sure
<karhunkynsi>i should quote them?
<mark_weaver>karhunkynsi: yes, I think <source> should be something like "/dev/sda<N>"
<mark_weaver>and <target> like "guix"
<mark_weaver>did it ask for a password before?
<karhunkynsi>before guile prompt i'm asked about passphrase once
<karhunkynsi>the messages with wrong password to this last command is equal to the one in the boot process
<mark_weaver>you might be missing a needed kernel module
<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>and try again
<karhunkynsi>how do i use lsmod on a mounted partition?
<karhunkynsi>maybe just look through /proc/modules
<karhunkynsi>hm, no, doesn't exist
<mark_weaver>you are booted back into guixsd?
<mark_weaver>ah, so 'lsmod' is not in your PATH?
<karhunkynsi>do you mean lsmod on the unencrypted one?
<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>(some of them may have been auto-loaded)
<karhunkynsi>ah, i see
<mark_weaver>after that, we just run 'lsmod' from the unencrypted system.
<karhunkynsi>i only identify 'dm-crypt' as crypto/hash
<karhunkynsi>in the lsmod output
<karhunkynsi>in the config.scm i have dm-crypt.ko
<karhunkynsi>mismatch with - and _
<mark_weaver>look in /run/current-system/kernel/lib/modules/*/kernel/crypto/
<mark_weaver>karhunkynsi: ah, good catch!
<mark_weaver>that might have been the problem
<karhunkynsi>i'll change to dm_crypt.ko and try again then
<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>but yeah, it might be that '-' vs '_' mismatch
<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)
<karhunkynsi>ok, adding: arc4, gf128mul
<karhunkynsi>ERROR: module not found "dm_crypt.ko"
<karhunkynsi>guess i'll be putting back the -
<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>i'll try again, now with arc4 and gf128mul
<mark_weaver>sounds promising
<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>it might be. can you try again?
<mark_weaver>maybe we need to call 'cryptsetup' in a loop to handle this case more gracefully
<mark_weaver>it says the passphrase is wrong?
<mark_weaver>what do the error message(s) say, roughly?
<karhunkynsi>no, it has never said that. It just shows some errors
<karhunkynsi>it's the same as usual
<mark_weaver>pre-mount actions failed?
<karhunkynsi>i'll write them in a paste
<mark_weaver>karhunkynsi: when you mount this partition from GuixSD, what is your precise "cryptsetup" command?
<karhunkynsi>sudo cryptsetup open /dev/sda1 guix
<mark_weaver>karhunkynsi: (use-modules (ice-9 ftw))
<mark_weaver>karhunkynsi: (scandir "/dev")
<mark_weaver>is "sda1" in there?
<mark_weaver>I see that "cryptsetup" has "--verbose" and "--debug" options
<mark_weaver>I think we should run it manually with those options
<mark_weaver>what do you think?
<karhunkynsi>previosly it was "temporary-cryptsetup-116" i think, other than that it's the same always
<karhunkynsi>yeah, let's see what we can find out
<mark_weaver>"Error allocating crypto tfm"
<karhunkynsi>yes, i have: sda, sda1, sda2 and sda3
<karhunkynsi>shown with scandir
<mark_weaver>sounds like a missing crypto module
<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)
<mark_weaver>some of them may not look in crypto modules
<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?
<mark_weaver>and the set of modules you have currently added?
<mark_weaver>sorry, I meant "lsmod"
<karhunkynsi>i see another module, xts
<mark_weaver>ah, good
<karhunkynsi>that should be it, there was 73 modules in lsmod before mounting, 76 after
<karhunkynsi>currently added modules:
<karhunkynsi>my config.scm:
<karhunkynsi>so, add xts, retry, and do some cryptsetup --verbose --debug then
<mark_weaver>sounds good
<mark_weaver>xts seems like a good bet
<karhunkynsi>HURRA, i'm in the login screen now :D
<karhunkynsi>..and there was much rejoice
<civodul>karhunkynsi: so you just booted on an encrypted root?
<karhunkynsi>encrypted root, boot and everything :D
<karhunkynsi>one partition
<civodul>ACTION thinks karhunkynsi & mark_weaver deserve big kudos :-)
<rekado>karhunkynsi: is this an encrypted partition with LVM?
<karhunkynsi>rekado, no
<karhunkynsi>i guess we should see what we can take away then
<karhunkynsi>in the end i think we just added three modules: arc4, gf128mul and xts. And added devtmpfs to linux-boot.scm.
<karhunkynsi>not sure if arc4 and gf128mul contributed anything
<karhunkynsi>did mark pass out with excitement?
<civodul>heheh :-)
<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.
<mark_weaver>karhunkynsi: ah, very good, thanks!
<karhunkynsi>this is the git diff for linux-boot.scm:
<mark_weaver>karhunkynsi: thanks!
<karhunkynsi>11 hours boiled down ;)
<mark_weaver>heh :)
<mark_weaver>this has been very helpful, thank you!
<karhunkynsi>it's been an enjoyable experience mark :)
<mark_weaver>I'm glad :)
<davexunit>great work!!!
<paroneayea>hey, welcome simonft !
<paroneayea>simonft is a friend of mine, volunteer sysadmin on mediagoblin, does other cool things, is interested in guix and deployment stuff
<paroneayea>simonft: welcome to #guix :)
<davexunit>welcome simonft!
<karhunkynsi>Hello simonft :)
<simonft>wow, I get an introduction. Thanks!
<simonft>and hello!
<davexunit>ACTION plays simonft's theme song
<mark_weaver>welcome, simonft! :)
<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?
<davexunit>it is.
<davexunit>it is named simply 'python'
<simonft>oh, I think misread
<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?
<davexunit>karhunkynsi: sudo is the typical way
<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.
<karhunkynsi>i've tried all "sudo su" variants i can think of
<davexunit>is sudo installed and are you in the "wheel" group?
<karhunkynsi>and i'm in xfce if that matters
<karhunkynsi>"sudo su" gives a password challenge, that doesn't accept empty or my user's password
<mark_weaver>karhunkynsi: sudo -s
<karhunkynsi>never seen that
<mark_weaver>or, just "su -"
<karhunkynsi>"su -" doesn't work for me
<mark_weaver>sudo -s will want your normal user password, su - will want the root password
<mark_weaver>it may balk at the empty password, dunno
<mark_weaver>you should set the root password anyway
<karhunkynsi>yeah, it seems it doesn't approve empty 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>'sudo -i' as well
<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
<mark_weaver>it will include patches or snippets that we specify
<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?
<simonft>ACTION reads up on "the store"
<mark_weaver>simonft: if you don't use substitutes from hydra, then the answer is "yes"
<mark_weaver>and that does indeed sometimes bite us
<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"
<davexunit>it's rarely an issue.
<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.
<simonft>I was mostly just curious though.
<karhunkynsi>oh, wait. It did. Nevermind
<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.
<mark_weaver>it would be good to have automated checking of this
<simonft>mark_weaver: are you able to go back and fix old versions of the url?
<mark_weaver>simonft: yes
<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.
<mark_weaver>one of two ways: guix download <URL>
<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
<mark_weaver>and will proceed with the build
<davexunit>karhunkynsi: known issue
<paroneayea>I think it would be nice in the future
<davexunit>I don't know why
<karhunkynsi>davexunit, ok
<paroneayea>to have a mirror of all things mainline guix packages
<davexunit>karhunkynsi: it's very strange
<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 :)
<simonft>Is guix a rolling distribution?
<mark_weaver>simonft: yes
<davexunit>paroneayea: the mirror is hydra, basically.
<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
<paroneayea>or whatever :)
<mark_weaver>indeed, we could do that, if we had more disk for hydra
<davexunit>maybe when we have more resources
<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.
<davexunit>simonft: when we further along, sure.
<paroneayea>simonft: well it's still relevant I think because
<mark_weaver>simonft: yes, I'd like to provide stable branches at some point
<simonft>that makes sense.
<davexunit>when we are
<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.
<xanthippe>Is it possible to just donate disks/money?
<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
<xanthippe>paroneayea: thanks!
<davexunit>xanthippe: disks: yes, money: not at this moment.
<paroneayea>xanthippe: thanks for considering your donation!
<xanthippe>sounds good
<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
<paroneayea>so it could accrue donations
<paroneayea>mediagoblin does that
<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
<mark_weaver>paroneayea: I already did, thanks
<paroneayea>mark_weaver: ah great :)
<davexunit>mark_weaver: oh, really? I had no idea!
<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>hmm, well, I guess I should clarify
<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.
<davexunit>that's good.
<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.
<mark_weaver>davexunit: sure, that would be nice I suppose
<davexunit>not needed now, of course.
<davexunit>one step at a time.
<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?
<simonft>sorry. :P
<simonft>also, by guix I think I mean GuixSD
<davexunit>simonft: yes, and it works.
<davexunit>not in master yet.
<davexunit>no cgroups or network virtualization support yet, but the most important stuff is in place.
<davexunit>where 'most important stuff' is namespaces