IRC channel logs

2018-12-09.log

back to list of logs

***lostcoffee is now known as atw
***rekado_ is now known as rekado
<tuete>Hello. I'd like to install GuixSD with disk encryption. My perfect setup would be an encrypted LVM partition with root, swap, and home in it. Since LVM is not supported yet, I like to encrypt at least root and swap with a password that needs to be typed in at boot time. The encrypted home can be mapped later on. I would like to avoid typing in a password twice at boot for root and swap. My main question is how I can make hibernation to work
<tuete>properly in that setup. Any ideas? :)
<roptat>tuete: we support full-disk encryption, but you have to type the password twice, once for ggrub and once for the partition
<roptat>I don't have a swap space anyway, so I don't know if hibernation is supported
<roptat>how do other distros manage to do that?
<tuete>The contents of RAM(+swap) are written into the swap space and then can be re-written at boot time. Basically the same as sleep, but it doesn't consume energy.
<vagrantc>typically, by not having an encrypted /boot and using lvm
<tuete>Why do I need to type a password for grub as well?
<vagrantc>but guixsd currently needs /boot to be on the same partition as /gnu/store
<vagrantc>so if / is encrypted, then it needs to decrypt the partition /boot is on from grub in order to load the kernel+initrd
<tuete>and grub can do that?
<vagrantc>probably the way to work around it is if grub could append the decrypted key to the initrd at boot time, and then the initramfs could decrypt the partition without further interaction
<tuete>What about copying the kernel and initrd to an unencrypted /boot?
<vagrantc>technically possible, but a separate /boot partition is currently not well supported in guixsd
<vagrantc>that's basically how Debian does it out of the box.
<vagrantc>or, just deal with the fact you have to type a password twice :)
<vagrantc>then your only unencrypted boot is the inital first-stage of the bootloader
<tuete>OK, so bascically the "downer" is to type in the password twice?
<rekado>we will need that for ci.guix.info anyway, because the device holding the store is not available before the system boots.
<vagrantc>ah, here's to real-world need!
<vagrantc>it's also sometimes needed on arm systems, and i've beenmeaning to file a bug report about it
<vagrantc>systems that can only boot from microsd or usb, but have sata or some other real storage for the OS
<rekado>unfortunately, merely copying the initrd and the kernel isn’t enough
<rekado>we need to keep track of the copied files so that we can do garbage collection
<vagrantc>ah.
<vagrantc>seems like treating it like a second "store" woudl get you that
<rekado>currently I copy the kernel and the initrd on ci.guix.info to the local partition manually…
<rekado>yes, that’s right
<vagrantc>for one of the systems i set up, i just rsync'ed the /boot partition and then the relevent /gnu/store bits
<vagrantc>i even pondered parsing the boot config to make sure i got the right bits
<g_bor>hello guix!
<janneke>hey g_bor!
<g_bor>janneke: nice work with the shells.
<janneke>g_bor: thanks...yes much progress, we have a real big puzzle though how to combine them
<tuete>Thanks vagrantc and rekado. I'll give it a try. I hope hibernation will work, though.
<g_bor>openjdk doc is now reproducible, but the jdk output still differs...
***w2gz is now known as w1gz
<roptat>g_bor: nice!
<g_bor>roptat: they have fixed it partially upstream, now only the idl compiler injects timestamps.
<roptat>I've built about ten more dependencies for the maven-build-system yesterday
<g_bor>roptat: very nice!
<g_bor>I was thinking about the scala bootstrapping issue recently.
<g_bor>It might be easier to get some parts of the bootstrap compiler in clojure. WDYT?
<roptat>I don't know
<roptat>does clojure have more facilities to build compilers?
<roptat>it's not impossible to do in Java, but it's certainly not very nice
<trasto>Hi , I'm new in guixsd , I installed emacs with guix package -i emacs but I can't start app in terminal console and when search for it with whereis emacs nothing do , what is the problem?
<roptat>trasto: do you have ~/.guix-profile/bin in you $PATH?
<trasto>roptat: I don't have the directory ~/.guix-profile
<roptat>mh... that's weird
<roptat>that's where guix should put things
<roptat>did you install with root?
<trasto>yes
<roptat>so emacs is in root's profile, but your user can't access it (probably)
<roptat>you should run giux package -i as user
<trasto>ops ok try this now
<trasto>roptat: nice this is the problem , thanks for the help :)
<roptat>you're welcome :)
<g_bor>roptat: not exatly, but clojure is functional, so we have more similar facilities in the base language. And clojure is already bootstrapped...
<g_bor>I am having a look at the openjdk packages now. Do we have any better way to get this configure phase?
<roptat>g_bor: if I did that, I guess gnu-build-system's configure phase is not working
<roptat>but you could try for yourself :)
<roptat>maybe that's from a previous attempt and I didn't try to simplify that phase
<g_bor>roptat: ok, I will have a look at that.
*janneke has bootstrapped sed-1.18, by writing a bootstrap.sh to replace configure, make
<g_bor>roptat: now I see what's up.
<g_bor>The configure script misses executable permission in the tarball
<civodul>hey Guix!
<user_oreloznog>Hi :) Thank you for this nice system
<user_oreloznog>GuixSD
<civodul>:-)
*janneke just bootstrapped gzip-1.2.4!
<efraim>:)
<janneke>hey civodul!
<civodul>howdy janneke!
<civodul>looking at the bootstrap tarballs again!
*civodul is really lagging behind
<civodul>i actually have to catch my train soonish...
<efraim>can I run guix pack against a package created with 'guix build -f guix.scm'?
<efraim>just saw the '-e' option
<efraim>"-e 'guix.scm'" doesn't work, unsuprisingly once I think about it
<divansantana>getting xbj4fhad0lnz0ziflwi90gyqbls8ains-nss-certs-3.39 0 hash mismatch with latest update.
<divansantana>Is anyone else getting this?
<rekado>divansantana: please see https://issues.guix.info/issue/33603
<divansantana>rekado:thanks will check!
<jlicht>hey guix!
<g_bor>hello guix!
<g_bor>I1ve run into a problem
<g_bor>It seems that there are some default configure flags.
<g_bor>It would be nice if we could disable some of these for packages with configure not supporting them and erroring on configure.
<g_bor>Am I missing something?
<jlicht>g_bor: could you elaborate? Are you working on a package with non-autotools configure script?
<g_bor>jlicht: openjdk11 configure does not know --enable-fast-install
<jlicht>you could always override the configure phase, but I guess your goal is to remove _only_ the --enable-fast-install, but leave the other defaults intact?
<g_bor>actually yes, that would be more elegant...
<g_bor>roptat got around that in other openjdk versions by creating a configure phase, so it works ok
<joshuaBPMan>does anyone have a personal guix channel repo that I can look at? My current personal guix channel is not working.
<joshuaBPMan>thanks.
<efraim> https://gitlab.com/cbaines/guix-chromium.git
<pkill9>mbakke: i can't remember if you have a public build server, i think i added it, if you do does it include substitutes for your chromium channel?
<jlicht>sneek: later tell joshuaBPMan: It seems that the .guix-channel file serves a purpose now :). See commit af12790bdd3805bbd7bca2b7c1d9045666f377eb
<sneek>Will do.
<pkill9>nice
<imme>hey, it looks like i screwed up guix in my guixsd .. by doing guix pull with an older version of guix (i have no 'current' in my ~/.config/guix/)
<imme>so now any guix ... command gives me an error 'no code for module (gcrypt hash)'
<imme>any pointers for a direction to go to fix that?
<imme>it seems to be an issue with ice-9/boot-9.scm, or at least, that's what the backtrace starts with.
<g_bor>imme: you can try recovering using another guix, maybe from the system or the root user profile
<imme>ah .. yes .. so i probably shouldn't have done guix pull on root and 1000-user then xD
<imme>ah, i think i could try to fix it by downloading a new version of guix, and build that to do a better update.
<mbakke>imme: Do you have "~/.config/guix/latest"? If so, try removing it.
<mbakke>You could also try to `guix environment --ad-hoc guile-gcrypt -- guix pull`.
<imme>ha, that was way easier then i thought, thanks mbakke! (i removed the latest and now guix-cmd does not give an error anymore)
<imme>another question someone here can give a yes/no to; a package for all users, say a texteditor, would that be installed by each user individually? I mean, is that they-way-to-go(tm)?
<g_bor>I have to now, bye!
<mbakke>imme: I don't think there is a yes/no answer to that question :-)
<mbakke>I use both approaches, depending on the system.
<jlicht>is anyone using emacs-guix for managing their user profile? I get the most obscure errors when doing any of the equivalent of `guix pull' or `guix package -i <things>'
<efraim>For the machine my kids use I put a couple fonts and other packages in the OS config so I can update their software easily
<tune>regarding individual text editor install, I came across a config.scm the other day that had openssh, tmux, and neovim in the package list
<tune>probably so any user can remote in and edit files
<tune>an interesting idea
<rekado>roptat, g_bor: I’m on the bus to Paris now and hacking on a new Java bootstrap :)
<pkill9>jlicht: i wrote the guide: http://miha.info/2018-Dec-09/how-to-add-a-modified-kernel-built-using-a-previous-guix-commit-to-your-system-configuration/
<jlicht>rekado: be safe, and have and enjoyable summit :-)
<jlicht>s/and/an
<jlicht>pkill9: thanks! Very simple solution indeed
<jlicht>Does it effectively allow for customizing a version-pinned kernel, without keeping the rest of your guix installation outdated?
<pkill9>i would say no, because every time you modfiy the customization, you'll still need to recompile the whole kernel
<pkill9>modify*
<pkill9>this makes it so that when you get a newer guix revision, you won't need to recompile your custom kernel if any of it's dependencies are changed (e.g. updated) in the newer guix revision
<pkill9>so it's more suited to if your custom kernel package is one that inherits linux-libre, and has for example a phase added that patches the source somehow
<jlicht>pkill9: yeah that is what I meant; you pin the version of linux-libre that you depend on, while allowing the rest of guix to be updated
<pkill9>ah ok, yeah that's exactly what i did it for :)
<lsl88>hi guix!
<pkill9>hi
<lsl88>I am still facing issues with my VM with guixSD. I guess I am getting closer, but still facing issues
<lsl88>I installed xfce as GUI, and I am currently running my VM with the following commands: sudo qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 -boot menu=on -drive file=hda.img -redir tcp:3333::3333 -redir tcp:8888::8888
<lsl88>sorry! I managed to solve it :)
<imme>Is it an issue worth sharing and how you solved it ?