IRC channel logs

<suitsmeveryfine>mkinitrd -c -k 4.2.5 -f ext4 -r /dev/cryptvg/root -m usb-storage:xhci-hcd:usbhid:hid_generic:mbcache:hid:jbd2:ext4:i915:hid_apple:ohci-hcd:evdev:uas:xhci_pci:xhci_hcd -C /dev/sda5 -L -u -o /boot/initrd-4.2.5.gz

<Jookia>That makes sense

<Jookia>Does Guix have a place to put initramfs modules?

<Jookia>In the system config

<suitsmeveryfine>yes, I've been told so

<suitsmeveryfine>Jookia: is the part "usb-storage:xhci-hcd:usbhid:hid_generic:mbcache:hid:jbd2:ext4:i915:hid_apple:ohci-hcd:evdev:uas:xhci_pci:xhci_hcd" just a list of modules in that particular order?

<NiAsterisk>looks like it

<Jookia>That part's just a list of modules in that order, maybe the order matters? Not sure- it's separated by colons

<Jookia>You'll probably want usb-storage, xhci-hcd, usbhid, hid_generic, hid, hid_apple, ohci-hcd, evdev, xhci_pci, xhci_hcd

<Jookia>hid_apple seems pretty important

<NiAsterisk>the only slack user I know is not only atm :/ and I used it like 12 years ago

<suitsmeveryfine>OK. I'll reinstall the system with a barebone configuration, as suggested, and add these kernel module

<suitsmeveryfine>s

<Jookia>suitsmeveryfine: They have to be loaded in the initramfs, so make sure it's doing that :)

<NiAsterisk>i think a case like this would be nice to document, like "special use cases" in the manual or whereever

<suitsmeveryfine>sure. I'm a complete newb at this though so it's not so easy for me

<Jookia>Tis fine

<suitsmeveryfine>as long as there are people in the channel I have no trouble though

<mark_weaver>I'd be surprised if the order matters.

<mark_weaver>but some of those underscores (_) should be dashes (-_

<mark_weaver>(-)

<Jookia>mark_weaver: Me too

<mark_weaver>for purposes of GuixSD configuration, I guess that the name should match the filename of the .ko file

<suitsmeveryfine>The order of the hooks matter I know

<mark_weaver>and the filename of the apple-hid module is apple-hid.ko

<mark_weaver>order of the "hooks" ?

<mark_weaver>what is a "hook" in this context?

<suitsmeveryfine>if you need to add hooks in the initramfs

<NiAsterisk>you add elements to the hook :)

<Jookia>Other distros have hooks for adding stuff to the initramfs

<NiAsterisk>oh ,okay

<suitsmeveryfine>ok, well I tried this in parabola

<suitsmeveryfine>and had the same keyboard issue

<mark_weaver>well, I don't see anything that looks like a hook in https://www.linuxquestions.org/questions/slackware-14/macbook-pro-2015-keyboard-not-responding-after-install-4175553896-print/

<suitsmeveryfine>HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt lvm2 filesystems fsck shutdown"

<suitsmeveryfine>(parabola)

<mark_weaver>well, we don't have anything analogous right now

<mark_weaver>we could certainly easily add bits of scheme code to run

<mark_weaver>but that's not germane to following the recipe in that link I just pasted above, which seems to only add modules.

<suitsmeveryfine>ok, but interestingly 'keyboard' up there is supposed to work but doesn't

<suitsmeveryfine>yes, so adding this list of modules is the thing I haven't tried yet

<suitsmeveryfine>now you say that they should have different names also

<mark_weaver>see section 7.2.11 (Initial RAM Disk) of the Guix manual, and make sure that the strings you give correspond to the filenames of the *.ko files

<mark_weaver>I guess the only deviations will be "_" and "-" might be interchanged, which I find surprising

<mark_weaver>the *.ko files are in /run/current-system/kernel/lib/modules on a GuixSD system, and /lib/modules on most other systems.

<lfam>Somehow, my /tmp is full even though the total of all the files listed by `ls -la` is maybe 1 megabyte

<suitsmeveryfine>thank you mark. I might be too tired to try this tonight, but at least I know what to do next.

<mark_weaver>suitsmeveryfine: okay, thanks for your perserverance

<suitsmeveryfine>I hate giving up on these things

<lfam>I wonder if this has something to do with the zombie Zsh test that is running one of my cores 100%

<Jookia>lfam: It's probably nothing

<mark_weaver>lfam: if you delete files that are currently open by a process, then even though they don't show up on 'ls' they cannot yet be freed.

<mark_weaver>that might be what's happening here

<lfam>Something like that. I'm not actually running the Zsh test suite in any of my terminal emulators!

<mark_weaver>sometimes programs will create a file in /tmp, open it, and then delete it immediately.

<lfam>It's a runaway zombie and I am going to kill it

<mark_weaver>but then the file will still use of space on disk until the last process closes it.

<lfam>Yup, that test had consumed 3.3 gigabytes

<mark_weaver>ouch

<lfam>This Zsh issue is very annoying.

<mark_weaver>I wonder what changed. zsh works on the master branch.

<lfam>I can't make it pass in a pure guix environment either.

<lfam>I actually can't make it pass using the master branch

<mark_weaver>oh, interesting.

<lfam>So, something changed on master since the last hydra run

<lfam>How can I most closely emulate the build chroot? A pure environment? A container?

<mark_weaver>lfam: or it might depend on what system is doing the build.

<mark_weaver>network-manager consistently builds successfully on hydra, but on my X60 it consistently fails to build.

<lfam>As in, it's hardware dependent?

<mark_weaver>either the hardware or the kernel

<mark_weaver>or number of cores

<lfam>Huh. Do you know what kernel the hydra x86_64 machines are using?

<lfam>As for cores, I have been disabling parallel building while debugging.

<mark_weaver>there are multiple build slaves and I'd be surprised if they're all running the same kernel.

<mark_weaver>but they are probably fairly old

<mark_weaver>I would guess that most of them are somewhere between 2.6.x and 3.2.x

<lfam>Well, this is the Debian 4.3.0-1-amd64

<lfam>I will try to make the daemon emulate 2.6

<mark_weaver>lfam: zsh builds successfully on hydra at commit 80b64ee2d86b179cb92c2c66ea3a67c9d3b4cdab

<lfam>Okay, I will try checking that out

<lfam>Oh, that was just yesterday...

<mark_weaver>some package build systems try to detect details of the build machine. we should always try to disable that kind of thing, and instead arrange for it to build for the lowest-common-denominator of the architecture.

<mark_weaver> http://hydra.gnu.org/build/859347

<mark_weaver>^^ latest zsh build on hydra, for commit 80b64ee2d86b179cb92c2c66ea3a67c9d3b4cdab

<lfam>With the daemon impersonating linux-2.6 and with that commit checked out, it fails in the same way.

<mark_weaver>I don't know how good the impersonation is.

<mark_weaver>ACTION tries building zsh on i686

<mark_weaver>zsh-5.2 is available now. http://www.zsh.org/pub/

<mark_weaver>maybe that one works better?

<lfam>I tried it, there are even more test failures :(

<suitsmeveryfine>mark_weaver: I'm trying to modify the initial ramdisk configuration now

<suitsmeveryfine>I'm looking at the example from the manual

<mark_weaver>suitsmeveryfine: that's good!

<suitsmeveryfine>Can I copy that example code and only replace "foo" and "bar"?

<suitsmeveryfine> https://www.gnu.org/software/guix/manual/html_node/Initial-RAM-Disk.html

<mark_weaver>suitsmeveryfine: yes, and add more than two.

<suitsmeveryfine>yes, of course, but what about "file-systems . rest"

<mark_weaver>yes, the rest should be the same as in the example.

<suitsmeveryfine>ok, good

<mark_weaver>lfam: on my Libreboot X60 (i686) running GuixSD, zsh from current 'master' built successfully.

<mark_weaver>lfam: it might be that your kernel is missing some needed features.

<suitsmeveryfine>what about 'rest' at the end?

<mark_weaver>suitsmeveryfine: you should copy that (initrd ...) bit exactly as-is into your OS config, and change only the "foo" "bar" part.

<suitsmeveryfine>ok

<suitsmeveryfine>I can't so easily find all the .ko files

<suitsmeveryfine>they are listed under /run/current-system/kernel/lib/modules

<suitsmeveryfine>not listed i meant

<mark_weaver>suitsmeveryfine: cd /run/current-system/kernel/lib/modules; find . -type f

<mark_weaver>find . -type f | grep hid.apple

<mark_weaver>the '.' in the regexp means "any character", so if you put those in place of - or _, then it will find either

<lfam>Well, the configure phases of the hydra Zsh and my Zsh are identical at least

<suitsmeveryfine>great, thanks!

<suitsmeveryfine>hmm, coudn't find xhci-hcd

<mark_weaver>suitsmeveryfine: I found xhci-plat-hcd

<mark_weaver>(on my 4.4 kernel)

<mark_weaver>maybe it was renamed? dunno

<suitsmeveryfine>ok, I can always try and include it

<mark_weaver>although xhci seems to be for USB 3.0 host adapters, and I'm sure that your old MacBook 2,1 (or 1,1) doesn't have that.

<suitsmeveryfine>yes

<suitsmeveryfine>so I don't include it

<lfam>mark_weaver: I seem to remember that the hydra machines (at least the intel-compatible ones) are running trisquel. In that case, could you share the /boot/config-$version-amd64 file so I can compare my kernel configuration? I believe that is a standard file on Debian-derived distros

<mark_weaver>lfam: do you have CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

<suitsmeveryfine>should the file suffix be included in the config file?

<lfam>Well, if they are really running such a different version of linux, there may be too many differences to compare

<mark_weaver>suitsmeveryfine: no, it should be things like "hid-apple"

<suitsmeveryfine>ok

<lfam>mark_weaver: yes, that option is set to y

<suitsmeveryfine>so I'll include all the modules except those that start with xhci

<mark_weaver>lfam: it built successfully on my GuixSD machine, so you might as well look at the kernel config in gnu/packages/linux-libre-x86_64.conf

<lfam>Ah, thanks

<suitsmeveryfine>usb-storage, usbhid, hid-generic, hid, hid-apple

<mark_weaver>usb-storage and usbhid are already included by default

<suitsmeveryfine>ok, so I'll skip them

<suitsmeveryfine>hmm, the example code tells me to add the suffix

<suitsmeveryfine>"boo.ko"

<suitsmeveryfine>in the comments

<mark_weaver>trust me, leave the .ko off

<suitsmeveryfine>ok :)

<mark_weaver>I believe you are misinterpreting the comment. perhaps it could be worded more clearly.

<mark_weaver>ACTION goes afk for at least an hour. good luck!

<suitsmeveryfine>yes, it's not entirely clear

<suitsmeveryfine>thanks, bye

<suitsmeveryfine>I know what to do no wo

<suitsmeveryfine>see you maybe tomorrow night

<lfam>Somehow I don't think the Zsh people will appreciate me asking them what kernel features are required for Zsh... there are so many difference between my kernel and the Guix kernel

<lfam>I wonder what would happen if I rebooted Debian with the Guix kernel config

<lfam>Well, the tests do succeed in my QEMU virtualized GuixSD

<lfam>Very strange

<lfam>There are probably a few hundred differences between my Debian kernel and the GuixSD kernel and I don't know where to start looking

<lfam>A lot of the differences look like hardware drivers. I guess the GuixSD kernel tries to be more one-size-fits-all whereas the Debian kernel is a little more tailored

<lfam>Or it could be something completely different

<iyzsong>ACTION pushed 'gstreamer-update' branch

<lfam>Shit, my last commit had junk from my work tree. Reverting.

<lfam>Well, Zsh builds find on my other machine with the same architecture and kernel config, both up-to-date Debian. So, who knows

<mark_weaver>sneek: later tell civodul: the #:virtio? keyword argument to base-initrd is documented as defaulting to #f, but in fact it defaults to #t

<sneek>Got it.

<mark_weaver>sneek: botsnack

<sneek>:)

<calher>I did $(guix download https://github.com/mumble-voip/mumble/releases/download/1.2.13/mumble-1.2.13.tar.gz) and got nothing in standard output.

<calher>Is this normal?

<mark_weaver>are you actually typing the "$(" and ")" ?

<mark_weaver>there should definitely be output

<mark_weaver>I see output

<mark_weaver>two lines should be sent to stdout: the resulting filename in /gnu/store, and the hash. some other stuff is sent to stderr.

<calher>mark_weaver, no.

<calher>$ guix download https://github.com/mumble-voip/mumble/releases/download/1.2.13/mumble-1.2.13.tar.gz

<calher>$

<calher>Okay, I got something once I tried it in a real terminal instead of M-x shell.

<calher>Is (sha256 (base32 "0ih108bc8xccldrifh5asf10svw6q2xahhhiz2jvc33nqf7p1nxp")) correct?

<mark_weaver>fwiw, I do almost everything within M-x shell, including this, and it works for me. not sure what's going wrong on your end.

<calher>mark_weaver, thanks a lot for making me feel inadequate.

<calher>0ih108bc8xccldrifh5asf10svw6q2xahhhiz2jvc33nqf7p1nxp

<mark_weaver>that was not my intent

<mark_weaver>but I've consistently felt like I'm getting bad vibes from you, and that doesn't usually happen. I interact with a lot of people on IRC.

<calher>0ih108bc8xccldrifh5asf10svw6q2xahhhiz2jvc33nqf7p1nxp

<mark_weaver>anyway, yes, that looks right, assuming that string is what was output by "guix download" or "guix hash"

<calher>Ugh, I'm going into a depressive state again...

<lfam>Tone is really hard to get right through written communication. It's much harder communicate one's intent and to understand somebody else's intent with writing than with speaking.

<mark_weaver>lfam +1

<calher>lfam, I've been told I have Asperger's, so you may not even be able to tell then.

<mark_weaver>calher: it's not important. if you are interested in Guix, then I'd like to welcome you to our community, and I'm sure we'll learn to communicate better in the future.

<mark_weaver>when i wrote that it works for me and that I'm not sure what's going wrong on your end, I did not mean to imply anything beyond what I literally wrote. I did not mean to imply that it was somehow your fault.

<mark_weaver>mainly I wanted to make it clear that these commands normally work within M-x shell

<mark_weaver>anyway, I have to go afk for a while. good luck

***TML-prv is now known as TML

<Jookia>calher: That output is the hash of the tarball I think

<vaeringjar>how does one change the hostname of the system in guixsd? every time I reboot it reverts.

<mark_weaver>vaeringjar: the 'host-name' is a field in the OS configuration. to change it, modify your OS configuration and run "guix system reconfigure <config>"

<vaeringjar>ah, okay that makes sense

<vaeringjar>thanks

<mark_weaver>np!

<mark_weaver>in core-updates, polkit fails to build, even on x86_64, because its configure script doesn't think that mozjs-17 is available, although it is an input. not sure what's going on there, but if someone is looking to help, fixing it would be helpful :)

<mark_weaver> http://hydra.gnu.org:3000/build/954826

<lfam>mark_weaver: What is the difference between hydra.gnu.org:3000 and hydra.gnu.org?

<mark_weaver>ah, sorry, I meant to omit the :3000 from that URL

<mark_weaver>the :3000 bypasses the nginx caching proxy in front, which sometimes I need to do

<lfam>Ah, that makes sense

<lfam>I like that mozjs is a Javascript engine, apparently written in C *and* C++, and it depends on Perl and Python. I guess it could also depend on Bash since that's an implicit input

<mark_weaver>heh :)

***victor is now known as Guest64151

***mog_ is now known as mog

<lfam>It's strange that all the file names in mozjs-17 look like this: "js-." "libmozjs-..so"

<civodul>uh, indeed

<sneek>civodul, you have 1 message.

<sneek>civodul, mark_weaver says: the #:virtio? keyword argument to base-initrd is documented as defaulting to #f, but in fact it defaults to #t

<civodul>oh

<civodul>yeah, this was to allow people to boot the thing in a VM, commit e26d507

<civodul> https://savannah.gnu.org/forum/forum.php?forum_id=8446

<NiAsterisk>does the guixsd installation image ship git or could I just 'guix package git' before I init the base system?

<NiAsterisk>*guix package install git i meant of course

<fps>NiAsterisk: to have git installed on the target system?

<fps>you can just "guix package -i git"

<NiAsterisk>to use git to pull the package configs from an intranet git server

<NiAsterisk>okay

<NiAsterisk>*system config

<cehteh>apropos .. was a 'per-group-profiles' discussed once?

<rekado>cehteh: I manage per-group profiles for some groups here at the institute.

<cehteh>how?

<rekado>you can just do "guix package -p /var/guix/profiles/per-group/name -i whatever you want"

<rekado>and then change group ownership of the profile.

<cehteh>ah guix handles setting up PATH for that?

<rekado>no, you'd have to go "guix package -p /same/path --search-paths" to get all environment variables you need to set

<rekado>you can eval a variant of this command.

<cehteh>methinks that would be nice to have this as buildin feature

<Jookia>Perhaps an odd question- Does Guix use bootjdk to bootstrap Javascript, or GHC binaries to bootstrap GHC?

<taylan>Jookia: we do download some binaries for self-hosting compilers. I don't know if it's the case for either of the examples you mention.

<taylan>examples I know of include GCC and CCL (Clozure Common Lisp)

<taylan>and in gnu/packages/haskell.scm I see mention of bootstrap GHC binaries

<Jookia>Hmm

<Jookia>From what I know there's no bootjdk on ARM

<rekado>Jookia: for Java we use GCJ to bootstrap the OpenJDK (in the IcedTea distribution)

<Jookia>Ah, cool

<rekado>but GCJ itself needs a binary of ecj.jar

<rekado>I don't know if it can be avoided at all. I don't think ECJ can be built at all with an older version of GCJ.

<Jookia>Hmm

<rekado>that's undesirable but I don't know any way around it.

<Jookia>I'd be interested to know if we could somehow bootstrap from Debian packages

<rekado>how would that be an improvement?

<rekado>these are also just binary artifacts.

<Jookia>Well, Debian generally has already done the hard work and bootstrapped packages for other architectures

<NiAsterisk>who was it asking for an email address without previous email providing? I just remembered mailchuck.com or bitmessage.ch, getting a one time address at one of them, then providing this at an email hoster of their choice this would work if the email provider does not save the one time address after the signup is done.

<Jookia>I've always used guerillamail or ruggedinbox for that kind of thing

<Jookia>Tutanota also works

<NiAsterisk>i knew none of them, next time someone asks I might have more than A/I and riseup, if those are okay. thanks

<NiAsterisk>maybe i knew guerillamail. idk

<Jookia>guerillamail is disposable, ruggedinbox is IMAP, tutanota is web based

<Jookia>All good for staying anonymous :)

<rekado>I'm trying to use autoconf/automake for the first time.

<rekado>when in "guix environment" I can do "make install" just fine, but on an older system I get "build-aux/missing: line 81: aclocal-1.15: command not found"

<rekado>"WARNING: 'aclocal-1.15' is missing on your system."

<Jookia>What's the environment of?

<rekado>in the environment I have all packages I need including autoconf/automake etc.

<rekado>on the target system I only have aclocal-1.11

<rekado>is this important?

<Jookia>Well, is the older system the target system?

<rekado>yes

<rekado>I thought the configure script and generated Makefile would be self-contained

<Jookia>I think you still need the right version of autotools to run the configure script

<rekado>oh.

<Jookia>You could try generating the configure script with the older aclocal

<rekado>so, I'd need an older autotools on my dev machine to make sure it runs on the target system.

<rekado>bleh

<Jookia>What's the target system?

<rekado>CentOS 6.x

<Jookia>Hmm. You could instal Guix on the target system ;)

<rekado>well, I'll have a Guix package for this tool anyway, but right now ./configure && make install won't work

<rekado>I did this whole autotools thing only to appease the non-Guix users.

<civodul>rekado: you only need autoconf/automake if you modify the .ac, .am, or similar files

<rekado>but I did not modify them :-/

<rekado>I added the generated configure script, Makefile.in, build-aux/ and so on to the repository

<civodul>it would not try to rerun aclocal if the mtimes were older :-)

<civodul>hmm

<civodul>when starting a project one just provides a .ac and a .am file, say

<civodul>and then run: autoreconf -vfi

<rekado>yes, that's what I did.

<civodul>ok

<civodul>but you shouldn't copy generated files manually

<civodul>it's best to run 'make dist' on the machine that has the environment set up

<civodul>and to send the tarball to the machine that lacks the tools

<civodul>(IIUC what you're doing)

<rekado>okay, I'll try again with make dist

<civodul>i can feel your frustration ;-)

<rekado>thanks for the help. I think it's working with using the tarball generated by "make dist". Not quite sure why the git clone doesn't work.

<rekado>I'd like to add the generated "configure" to the repo so that people don't need to bootstrap when cloning.

<civodul>some projects do that, notably libc/gcc/gdb/binutils

<NiAsterisk>what services does `services desktop` pull in? I need to remove everything a server does not need, but I am unsure what's left if I just remove desktop. is base + dbus + networking + optional others enough then to not pull in slim and xorg etc

<NiAsterisk>barebones.scm looks like it would be okay for this I guess. should've read examples first before looking at services subdir

<rekado>I see that the ghc-package-cache derivation is always built. Could we make this conditional?

<mark_weaver>rekado: in the tarball, the modification times of the files are preserved by tar.

<mark_weaver>rekado: when you check out with git, afaik there's no guarantee what the mtimes will be of the unpacked files.

<mark_weaver>well, they will be roughly the time that you checked out, but their times will differ because it takes time to check out all the files

<mark_weaver>and I'm not sure there's any guarantee what order they will be unpacked in.

<mark_weaver>so the ordering of their mtimes will not be guaranteed, and it may end up that your .ac/.am files are slightly newer than the files generated from them.

<mark_weaver>and when that happens, 'make' will decide that it's time to rerun some of the autotools programs to regenerate files.

<mark_weaver>ACTION dislikes the practice of including auto-generated files in the git repo

<mark_weaver>(when avoidable)

<davexunit>same.

<rekado>mark_weaver: I see. Thanks for the explanation.

<mark_weaver>NiAsterisk: you can run "guix package -i git" from the USB installer.

<NiAsterisk>realized so, after deco start cow-store

<NiAsterisk>thanks though :)

<mark_weaver>NiAsterisk: %desktop-services is defined in gnu/services/desktop.scm and %base-services is defined in gnu/services/base.scm, so you can see for yourself what's in them.

<mark_weaver>rekado: iiuc, ghc-package-cache will only be built if there's a package in your profile whose name starts with "ghc".

<mark_weaver>it's not a great solution, but I'm not sure how to do better.

<rekado>oh, right, there is a propagated ghc-pandoc in the profile.

<rekado>never mind then.

<mark_weaver>NiAsterisk: when you asked about what `services desktop` pulls in, I was not sure what you meant. first I thought you meant %desktop-services, but the quoting seems to suggest otherwise. did you mean to ask: what does (use-service-modules desktop) pull in?

<NiAsterisk>my question was a bit off. I think I solved it by myself by looking further at the source

<mark_weaver>okay

<NiAsterisk>not so easy.. if I export SSl_CERT_DIR before I do init system, will it influence the system init somehow, do I have to revert the path? i can't clone via https with what I've got, and cloning via ssh is not effective.

<NiAsterisk>nvm, something else is broken

<fps>NiAsterisk: git? try git clone -c http.sslverify=false ...

<fps>or was it verifyssl?

<fps>oh well :)

<fps>all the ssl stuff was quite wonky when i played more with guixsd (when i had some spare time ;))

<NiAsterisk>git with a runni8ng guixsd is okay. git in a running just started guixsd is barely working

<NiAsterisk>even with all the assumed additional packages pulled in

<NiAsterisk>i did it with wget and ignored certs now

<davexunit>I can't parse that.

<civodul>anyone looking at GDM and GNOME? iyzsong?

<civodul>would be nice to have a ready-to-use GNOMish solution for the next release

<civodul>well, as ready as possible

<NiAsterisk>i booted into a new guixsd setup. then I tried to clone a repository I needed, installed git, openssl, etc etc, ended up with wget --ignore-ssl-certs or what it was to get the master.tar.gz instead of cloning the repo

<davexunit>NiAsterisk: then you didn't set the correct environment variables.

<NiAsterisk>i changed the variables in the end, still didn't work

<davexunit>then you did it wrong. not sure what to tell you.

<NiAsterisk>possibly

<davexunit>all my SSL stuff works well.

<civodul>NiAsterisk: maybe see https://www.gnu.org/software/guix/manual/html_node/X_002e509-Certificates.html

<NiAsterisk>ahh. okay, i did not know about git_ssl_cainfo

<NiAsterisk>thanks. i'll try and take better notes next time

<civodul>it may be that nss-certs is not installed globally on your system, and that /etc/ssl/certs is consequently empty

<jin>hi , try to build nautilus for gnome, i have error 'guix build: error: #<unspecified>: not something we can do '.

<NiAsterisk>it was ignored even with SSL_CERT_DIR="/root/.guix-profile/etc/ssl/certs"

<jin>this is the nautilus.scm: paste.debian.net/367199

<civodul>jin: there's an unbalanced parent

<civodul>on this line: (home-page "http://www.gnome.org";)

<civodul>the semicolon at the end introduces a comment, and thus hides the closing parent

<civodul>*paren

<jin>ok, how can i show a description of frecuently errors?

<calher>Crap, Mumble needs Linux Standard Base and that hasn't been packaged.

<mark_weaver>calher: Linux Standard Base is probably not something that can be put into Guix. It presumes things like that we follow the Filesystem Hierarchy Standard, which is fundamentally incompatible with the design of Guix.

<mark_weaver>I think Mumble would need to be modified to conform with Guix.

<calher>O_O

<NiAsterisk>what exactly is the standard base?

<calher>IDK.

<mark_weaver> https://en.wikipedia.org/wiki/Linux_Standard_Base

<NiAsterisk>ah

<mark_weaver>it standardizes things like the filesystem layout (which we *must* deviate from to accomplish the special features in Guix and NixOS), the RPM package format (from Red Hat), etc

<mark_weaver>even Debian dropped support for the LSB recently.

<mark_weaver>it was basically an effort to standardize on the details of the Red Hat distros.

<calher>But the Debian package for Mumble has lsb-*.

<mark_weaver>and yet, Mumble is still in Debian

<CompanionCube>Doesn't the LSB even specify RPM *shudder*

<bavier>the mumble website contains the "by accessing this website you agree to our services-agreement" verbiage

<mark_weaver>bah

<bavier>which is silly

<bavier>how do I even know you have such an agreement if I don't access your website?

<CompanionCube>ACTION might've found a reason to actually try guix

<mark_weaver>anyway, we often have to make modifications to software to adjust it for the way Guix does things. the most common cases of this are automated, but occasionally we need to make package-specific adjustments.

<calher>Mumble is the one thing stopping me from going to Guix.

<calher>I didn't know how hard it was to package stuff.

<CompanionCube>does guix's git come with the git info manual?

<calher>Even with the nice Scheme abstractions, it's still hard.

<NiAsterisk>calher: i found it rather easy on gentoo and archlinux. guix is a challenge.

<mark_weaver>CompanionCube: yes

<NiAsterisk>I love challenges

<CompanionCube>neat, arch's doesn't

<mark_weaver>CompanionCube: oh, I may have misunderstood your question. did you mean to ask if it comes with the "git info manual" or the "guix info manual" ?

<CompanionCube>the former

<mark_weaver>As in, the documentation for Git in texinfo format?

<CompanionCube>yes

<mark_weaver>I didn't know such a thing existed, but I'd like to have it. Where can I find it?

<CompanionCube>mark_weaver, I also did not know it existed

<CompanionCube>until I was reading the magit manual in emacs

<mark_weaver>CompanionCube: what does the magit manual say that led you to believe that the git manual is available in texinfo format?

<mark_weaver>can you tell me what section of the magit manual says so?

<CompanionCube>Appendix A, section 10

<bavier>calher: where do you read that mumble requires LSB?

<mark_weaver>CompanionCube: ah, thanks for pointing that out!

<mark_weaver>at the moment, we only have 'git-manpages' as a separate package.

<mark_weaver>and we don't even generate them from the git source. we download the pre-generated git man pages, I guess because it was a pain to get the asciidoc stuff working right.

<mark_weaver>it would be great if someone was willing to work on improving this. Many (most?) Guix developers prefer to work in Emacs and prefer to read docs in Info format, so we would be grateful.

<CompanionCube>haven't had an opportunity as such to try guix yet

<mark_weaver> https://lists.fedoraproject.org/pipermail/scm-commits/2010-August/483111.html

<mark_weaver>"Actually removed the requirement for redhat-lsb"

<mark_weaver>(from mumble)

<mark_weaver>that's from 2010

<mark_weaver>a web search for "LSB site:mumble.info" couldn't find anything.

<mark_weaver>and a search for "mumble requires lsb" turned up the commit above

<mark_weaver>calher: ^^

<mark_weaver>calher: where did you read that mumble requires LSB ?

<mark_weaver>ACTION goes afk

<jin>hi guix, i need some help to build a package, yet..

<jin>i cant´n find my error

<alezost>jin: yes, paste your package please :-)

<jin>i run the command 'guix build -f nautilus.scm', and show output error: 'guix build: error: #<unspecified>: not something we can do '

<jin>alezost: this is paste.debian.net/367310

<lfam>jin: What is the path of nautilus.scm? I believe the module path (line 1 of nautilus.scm) should match the filesystem path. So, nautilus.scm would have to be at "gnu/packages/nautilus.com". Another example: Change the module path to (jin packages nautilus) and put the file at "jin/packages/nautilus.scm"

<lfam> https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#DOCF22

<alezost>jin: for 'guix build -f' command you need to specify a file with a last expression that returns a package. Put "nautilus" in the end

<alezost>jin: I mean put "nautilus" without double quotes in the end of this file (you'll probably get another error :-))

<alezost>jin: Try this file: <http://paste.debian.net/367315> (note: I added "photo", "glib" and "gnome" package modules)

<jin>ok, i trying...

<alezost>jin: actually the best for contributing would be to clone the guix source and set it up, so there will be no need to use "guix build -f" to test your packages. See (info "(guix) Contributing") in the manual.

<jin>ok, i begin to read, the manual

<jin>the script is running..

<jin>thanks lfam, alezost

<lfam>Cool!

<davexunit>calher: I have a WIP mumble package on one of my computers. I ran into some somewhat difficult problems, IIRC. I should post the recipe here next I'm back at that computer.

<calher>davexunit, cool. That's better than nothing.

<CompanionCube>ACTION is liking el-get so far

<suitsmeveryfine>Hi again friends! I've had some progress with installing guixsd with full disk encryption on a macbook2,1+libreboot

<petter>Hey suitsmeveryfine

<suitsmeveryfine>having included the modules hid-generic, hid and hid-apple in initramfs the keyboard is finally recognized at boot

<suitsmeveryfine>I only installed a base system this time and ended up with a scheme prompt. Is this normal?

<suitsmeveryfine>I got the feeling that this is some kind of debugging mode because I was never asked for a LUKS password

<lfam>suitsmeveryfine: You are correct, that is a debug mode that you get when something (not sure what) fails

<suitsmeveryfine>ok. After pressing ctrl+D I exited guile and the boot process continued a bit but then froze

<suitsmeveryfine>so I just did a hard shutdown

<lfam>Can you share your OS declaration?

<mark_weaver>suitsmeveryfine: that's good news about the keyboard!

<petter>suitsmeveryfine: i landed there a couple of times when i didn't have the correct encryption modules in initrd. Did you add or set the modules?

<petter>(set as in other modules are lost)

<mark_weaver>suitsmeveryfine: I guess we should add those modules to the set of modules included in the initrd by default.

<suitsmeveryfine>yes, that would be useful I think

<suitsmeveryfine>The error I get is: 'fsck.ext4' exited with code 8 pn /dev/sda1; spawning REPL

<mark_weaver>suitsmeveryfine: can you show us your OS configuration?

<petter>hm, the ext4 isn't on /dev/sda1, it's on /dev/mapper/guixsd or similar

<suitsmeveryfine>well, I can't boot the system and copy it too you but I can easily explain it

<mark_weaver>it sounds like you were missing the crucial 'mapped-devices' section and the correct /dev/mapper/XXX device in your file-system spec

<mark_weaver>crucial bits needed for using an encrypted root partition

<suitsmeveryfine>Oh, I believe that I did:

<suitsmeveryfine> (file-systems (cons (file-system

<suitsmeveryfine> (device "/dev/mapper/guixsd")

<suitsmeveryfine> (title 'device)

<suitsmeveryfine> (mount-point "/")

<suitsmeveryfine> (type "ext4"))

<suitsmeveryfine> %base-file-systems))

<suitsmeveryfine>but I'll start the installer and double-check

<mark_weaver>I suspect that you're mistaken about that 'device' field.

<mark_weaver>based on the error message you got.

<suitsmeveryfine>ok, I hope you are right!

<suitsmeveryfine>Let's see in a few minutes

<mark_weaver>I vaguely remember you saying that you were going to switch back to the bare-bones configuration that we provide, that lacked the bits needed for encrypted root.

<petter>mark_weaver: what do you mean? That it lacks (mapped-devices ...) or intrd modules? (or something else)

<mark_weaver>yesterday, suitsmeveryfine wrote: <suitsmeveryfine> OK. I'll reinstall the system with a barebone configuration, as suggested, and add these kernel module

<mark_weaver>maybe based on this: <petter> if he'll be reinstalling a couple of times i guess he could base his config off the bare-bone example instead - less packages to install

<mark_weaver>and I worry that some of the important bits needed for encrypted root were lost in what suitsmeveryfine's ended up with.

<suitsmeveryfine>You were right: I wrote "/dev/sda1" instead of /dev/mapper/guixsd" after device

<mark_weaver>suitsmeveryfine: also, do you have the 'mapped-devices' section that was in petter's example config?

<mark_weaver>or his HOWTO

<suitsmeveryfine>mark: I discovered the error ^^

<mark_weaver>both are needed.

<petter>mark_weaver: ok, so just a config issue. I was worried that bare-bones was incapable of pulling up a fully encrypted system

<mark_weaver>suitsmeveryfine: okay, that's good, but I'm just pointing out another possible omission to save you the trouble of more iterations of this.

<suitsmeveryfine>you mean that the bare-bones might be a problem

<suitsmeveryfine>shall I switch to a desktop configuration perhaps?

<petter>suitsmeveryfine: ignore me, i misunderstood

<mark_weaver>suitsmeveryfine: you need this, or something like it:

<mark_weaver>(mapped-devices (list (mapped-device

<mark_weaver> (source "/dev/sda1")

<mark_weaver> (target "guixsd")

<mark_weaver> (type luks-device-mapping))))

<suitsmeveryfine>yes I had that; everything else was correct in the file

<mark_weaver>okay

<suitsmeveryfine>I had only made that error

<suitsmeveryfine>now the question: for the new system init, bare-bones or desktop?

<mark_weaver>okay, then I'd recommend fixing that and avoiding any other changes for now.

<suitsmeveryfine>ok

<suitsmeveryfine>can I simply run system init from here?

<suitsmeveryfine>and thus overwrite the system

<mark_weaver>I don't know where "here" is :)

<suitsmeveryfine>from inside the installer

<mark_weaver>yes, although you might need to wipe the target device first (making sure not to lose your config file)

<mark_weaver>well, if you didn't wipe the last time you reinstalled, then I guess you don't have to this time either.

<suitsmeveryfine>what is the best way to wipe otherwise?

<mark_weaver>to be honest, I'm not sure if wiping is needed or not at this point.

<suitsmeveryfine>I'll try without wiping

<mark_weaver>suitsmeveryfine: sounds good.

<CompanionCube>so if you get a repl when the system fails/has an error during booting, does that mean a scheme interpreter is baked into the initramfs or something?

<suitsmeveryfine>yes

<suitsmeveryfine>see the manual

<mark_weaver>CompanionCube: yes, guile is in the initramfs

<suitsmeveryfine>statically linked guile

<petter>since the issue with the keyboard has been resolved, isn't it just as well to go for the desktop config?

<CompanionCube>neat, I should use guix but am not actually sure what I would end up using it for

<mark_weaver>petter: the important thing is to get a working system to begin with. after that, it is trivial to switch to a full desktop config, without the risk of pain if it doesn't work.

<mark_weaver>basically, we are very good at allowing free experimentation with new configs once you have a working system installed.

<petter>right, right

<mark_weaver>but if there are problems with the initial install, it's a major pain to redo it.

<mark_weaver>(we should look into ways to improve that)

<mark_weaver>I have to go afk for a long while. good luck!

<suitsmeveryfine>thank you!

<mark_weaver>suitsmeveryfine: you're welcome, and thank you too! you've helped us fix GuixSD on MacBooks.

<mark_weaver>we should be able to fix https://bugs.gnu.org/20433 now

<mark_weaver>ACTION goes afk

<petter>yes, good going suitsmeveryfine :)

<suitsmeveryfine>:D

<suitsmeveryfine>petter: if this works I'd also like to try adding the keyfile in initramfs

<suitsmeveryfine>so that it isn't necessary to type in the LUKS password twice

<petter>suitsmeveryfine: that would be very interesting! Do you have any idea how to go about this?

<suitsmeveryfine>the guixsd manual doesn't explain how this can be done

<suitsmeveryfine>I can show you how it's done in parabola

<petter>yes, please

<suitsmeveryfine>Go to https://libreboot.org/docs/gnulinux/encrypted_parabola.html and scroll down to " Bonus: Using a key file to unlock /boot/"

<petter>thanks

<petter>neat, there's a "luksAddKey", i was not aware of this

<suitsmeveryfine>would you be able to add this to the guide?

<suitsmeveryfine>I'd be happy to test it once again

<petter>we should include this if we can get this working

<suitsmeveryfine>yes, that's what I meant

<suitsmeveryfine>but I don't know how to add config files to guixsd initramfs

<suitsmeveryfine>it's not documented

<petter>i don't either, but if we ask nicely i'll bet we'll get help :)

<suitsmeveryfine>Yes I'm sure

<suitsmeveryfine>you also mentioned yesterday that one could have different GRUB entires for standard boot and second grub

<suitsmeveryfine>by creating a symlink

<suitsmeveryfine>that should go into the guide as well I think

<petter>yes, it's possible to refer to, hm, either current or latest. And we know already how to load the grub.cfg

<petter>i don't have this information now though

<suitsmeveryfine>that's fine. I'd be happy to spend some time configuring my new guixsd system :)

<suitsmeveryfine>besides, I need to finish that macbook unbricking guide that I'm working on

<petter>i believe it was alezost that showed me this some months ago. Maybe they can show us again.

<alezost>petter: sorry, showed what? I don't remember :-)

<petter>don't you use a clever setup to boot current/latest version?

<petter>it must be in your grub configuration file

<petter>or do you use the generated one?

<fhmgufs>#join #raspberry

<fhmgufs>:(

<suitsmeveryfine>no, don't join them please :)

<fhmgufs>Excuse me, but I have one. Because it's cheep.

<fhmgufs>And, I'm trying to get GuixSD on it.

<fhmgufs>At least when there's the next release.

<alezost>petter: oh, you mean grub config. Yes, I always use my own grub.cfg and --no-grub option to "guix system" commands. Here is a part of my grub.cfg: <https://paste.debian.net/311412/>

<petter>alezost: yes, this. Thank you!

<alezost>no problem, I'm glad it may be useful for someone else :-)

<petter>we're thinking of adding 2 menu entries for fully encrypted systems on Libreboot. One, like this, and the other to the generated grub config.

<petter>(we're writing a guide)

<petter>though this issue isn't specific to that

<suitsmeveryfine>petter: I got a different error message now. I managed to enter the LUKS password

<petter>suitsmeveryfine: what does it say?

<suitsmeveryfine>device-mapper: table: 253:0: crypt: Error allocating crypto tfm

<suitsmeveryfine>device-mapper: ioctl: error adding target to the table

<petter>i haven't seen that one

<suitsmeveryfine>device-mapper: reload ioctl on failed: No such file or directory

<petter>hm, maybe there's an issue with the LUKS encryption, a quick web search may suggest this

<petter>the cryptsetup i put in the guide-draft is not the one i used

<suitsmeveryfine>petter: a gentoo user seems to have had this issue and did this to make it work:

<suitsmeveryfine>"Adding the XTS cipher (CONFIG_CRYPTO_XTS) to the kernel solved the problem. "

<suitsmeveryfine> https://forums.gentoo.org/viewtopic-t-716569-start-0.html

<petter>suitsmeveryfine: Do you know how to do that?

<suitsmeveryfine>no

<suitsmeveryfine>or, not yet anyway :)

<petter>i don't either

<suitsmeveryfine>maybe it's just the bare-bones configuration that's lacking it

<petter>you're also the first one (i guess) to use this particular cryptsetup command

<suitsmeveryfine>I thought you were using it too

<petter>no, i mentioned it briefly in chat. But i should have made a comment in the draft.

<petter>i ended up with one that's relatively weak because i'm not good at these things and used the first and best i found when i was at that stage

<petter>s/best/"&"/

<suitsmeveryfine>okay. Hmm, could you please compare the bare-bones and the desktop config files?

<suitsmeveryfine>to see if maybe the desktop config contains it

<petter>cryptsetup -v --cipher serpent-xts-plain64 --key-size 512 --hash whirlpool --use-random --verify-passphrase luksFormat /dev/<your-luks-partition>

<suitsmeveryfine>yes, it's the one I used

<petter>i suspect the problem you're facing now is the --cipher in the above command

<petter>i guess the proper fix is that the kernel supports it, maybe it's a Guix thing, or maybe it's a Linux-libre thing. I don't know

<suitsmeveryfine>I don't think it's a linux-libre thing because it has been tested on parabola

<suitsmeveryfine>you took that from the parabola guide, remember?

<petter>oh, yeah, right. Yes, i took it from Libreboot's parabola guide

<suitsmeveryfine>mark_weaver: I vaguely remember you saying that you were going to switch back to the bare-bones configuration that we provide, that lacked the bits needed for encrypted root.

<suitsmeveryfine>I will try to switch to desktop and see if it works

<petter>i think he suspected you had made an error in setting up the crypto stuff in the config, not that the bare-bones example is missing required modules for crypto

<suitsmeveryfine>could you check if it does?

<petter>here's their diff: http://sprunge.us/GSCE

<petter>it's nothing obvious to me

<suitsmeveryfine>I might as well try it

<suitsmeveryfine>still

<petter>sure

<suitsmeveryfine>some more writes to the SSD to make proper use of it :)

<petter>hehe ;)

<petter>if this doesn't work, i think we have 2 options. Add XTS to the kernel, or start over with another cipher

<suitsmeveryfine>or wait for somebody to explain how to add xts

<petter>yeah, i don't know. In the Guix manual i see a field "kernel-argumenst" but i can't find anyone enabling XTS through a kernel parameter

<suitsmeveryfine>if xts is a kernel module then maybe I can just add it?

<petter>How?

<suitsmeveryfine>just like I did to get the keyboard working: in the initrd configuration

<suitsmeveryfine>But I don't even know if it's a module

<petter>but isn't initrd only temporary?

<suitsmeveryfine>no it's in the system configuration file

<suitsmeveryfine>if you add it there it stays

<petter>oh, yeah. Maybe that's the problem. Initrd don't have XTS.

<petter>In my system now i have XTS loaded

<suitsmeveryfine>can you check which file it is?

<petter>but i don't add XTS in my initrd, so it seems weird

<suitsmeveryfine>I've already included "hid-generic", "hid" and "hid-apple" so why not a few others

<suitsmeveryfine>ah

<suitsmeveryfine>so maybe it's the bare-bones config then

<suitsmeveryfine>I'll just proceed with the desktop install then

<petter>ok

<suitsmeveryfine>If this works then we can add to the guide that copying the bare-bones file won't work

<petter>yes

<suitsmeveryfine>until we find something better to write

<petter>i don't know if XTS is a special case though

<suitsmeveryfine>no, maybe it's true for decryption in general

<suitsmeveryfine>I was asked to enter the LUKS password though

<suitsmeveryfine>and then the boot process continued a bit

<petter>now, based on the desktop example?

<suitsmeveryfine>no, before

<suitsmeveryfine>with bare-bones

<petter>i wonder what is responsible for decrypting the disk at that point. Maybe it's GRUB

<suitsmeveryfine>no It's initramfs

<suitsmeveryfine>because I was asked to enter the LUKS password the second time

<suitsmeveryfine>which I could do

<suitsmeveryfine>then I ended up in the guild recovery prompt and after exiting that I had a kernel panic

***l is now known as Guest66227

IRC channel logs

2016-01-22.log