IRC channel logs

<sartre>The installation boot message is not very encouraging, "Thanks for being so brave."

<lfam>On a foreign distro, how can I use root's Guix packages from sudo? For example, if root has Vim in her profile, what is the proper way to do `sudo vim /etc/fstab`?

<iyzsong>lfam: `sudo -i vim` works.

<lfam>izysong: Thank you

<iyzsong>:3

<lfam>I tried to read the man page for sudo and realized that this Debian didn't want to let me read manpages with `less`. So I had to go down a rabbit hole.

<lfam>Do we have a working implementation of zsh completion? I have a package with bash and zsh completions.

<iyzsong>completions provided by zsh should work, I haven't try to use completions provided by other packages.

<paron_remote>hello, all

<lfam>What can I do on a foreign distro to make Guix packages available to remote connections over ssh? For example, if I use Guix to install rsync remotely, how can I invoke rsync locally such that it can find the remote rsync?

<lfam>The Bash manual says that ~/.bashrc can be sourced in that case, but our manual advises not to set $PATH in ~/.bashrc

<efraim>I've had to stick our path stuff in ~/.bashrc instead of ~/.profile

<lfam>I wonder about the effect on `guix environment`

<lfam> http://www.gnu.org/software/guix/manual/guix.html#DOCF12

<civodul>Hello Guix!

<Jookia>Hello o/

<sneek>Jookia, you have 1 message.

<sneek>Jookia, civodul says: unfortunately, no --keep-going yet

<Jookia>That's awesome.

<Jookia>The messages, no the response.

<civodul>indeed ;-)

<civodul>--keep-going would be very useful

<Jookia>I'm hacking it in to my version

<tsyesika>civodul: i'll try and test what you pushed, I'm not too sure how yet... but i'll try and figure a way out

<tsyesika>civodul: is it possibly for me to build an image similiar to 0.9? is the config you use to build the installation images somewhere?

<lfam>tsyesika: See section 7.1.5: https://www.gnu.org/software/guix/manual/guix.html#System-Installation

<tsyesika>lfam: great, don't know how i missed that

<tsyesika>thanks!

<civodul>hey tsyesika

<civodul>tsyesika: alternately, you could try to unload the usbkbd

<civodul>not sure if that's possible

<civodul>or you can do as noted in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20433#42

<tsyesika>ACTION nods

<tsyesika>i'll try and build and test an image tonight after work

<tsyesika>i'll report back to the mailing list

<civodul>great!

<civodul>just running 'guix system reconfigure' would be easier than building a new image

<civodul>so easiest is "rmmod usbkbd" and see what happens; 2nd easiest is 'guix system reconfigure'

<Jookia>I wonder how hard it'd be to get Guile running on Wine/ReactOS

<tsyesika>civodul: i don't have it installed

<tsyesika>civodul: i can't without the keyboard working

<tsyesika>civodul: the macbook air only has 2 usb ports and the internal network card doesn't work and the laptop doesn't have an eithernet port so i need to use usb network as well as the usb drive to boot from

<Jookia>Is there a way to specify a package repository for Guix to use? So far it seems to only let you use what's installed or guix-latest

<rekado>tsyesika: you could do without the network for a moment to check if "rmmod usbkbd" works.

<tsyesika>i could yep

<rekado>(I don't think it would work, though, because that would not necessarily make the internal keyboard be served by usbhid)

<rekado>Jookia: what do you mean by package repository?

<tsyesika>rekado: i'll build an image later tonight and test it

<rekado>Jookia: you can use a different set of recipes with GUIX_PACKAGE_PATH.

<Jookia>rekado: I have a custom Guix version that I want to install and use as my default Guix- I can also see this being the case if I want to edit package- GUIX_PACKAGE_PATH! That sounds like it

<Jookia>A little like it, I still have to package my custom Guix version

<rekado>I normally use a git clone of upstream Guix and have my own changes in the tree.

<rekado>maybe on a different branch.

<rekado>then I link ~/.config/guix/latest to the location of the clone.

<Jookia>Hmm, but that won't install it will it? Since the Guix package doesn't have the changes

<Jookia>Well, I suppose 'install' is the wrong idea here anyway ;)

<Jookia>That solution works fine for me, thanks

<civodul>tsyesika: ooh, i see

<tsyesika>civodul: macbooks are a nightmare to run free software on >.< can't wait until i can justify the cost of getting a libreboot x200

<civodul>heh

<Jookia>Does anyone else find coreutils' test fail when building? I have a specific test and the source code itself seems like it's intended to fail

<Jookia>In addition, is there a way to step through a build's phases? Would I need to use Guile and breakpoints for this?

<civodul>Jookia: on which platform?

<civodul>(the coreutils failure)

<Jookia>civodul: x86_64

<civodul>oh, haven't seen that one

<civodul>could you paste the relevant part of the build log?

<civodul>mark_weaver: apparently both gettext/armhf and coreutils/mips64el are built now on Hydra, so i guess these were transient failures?

<Jookia>civodul: http://paste.rel4tion.org/216

<civodul>Jookia: what file system are you using?

<Jookia>civodul: btrfs

<civodul>that could be related, given that this test is looking at low-level FS details

<civodul>also, you seem to be using an "old" guix-daemon, which leaks the real name of the build directory (/mnt/scratch/...)

<civodul>i'd recommend using the latest one in master

<civodul>that way, you'll be using the same build directory name as everyone else

<Jookia>civodul: Does that help reproducibility or is it just for logs?

<civodul>in some cases, that can avoid obscure failures (related to file name limits, etc.)

<civodul>so that helps reproducibility

<civodul>though i think the problem here is due to btrfs

<Jookia>hmm

<Jookia> https://lists.gnu.org/archive/html/bug-coreutils/2015-05/msg00036.html Seems to be documented upstream maybe

<Jookia>I'll check to see if https://lists.gnu.org/archive/html/bug-coreutils/2015-05/txtowqOSi7s4D.txt fixes it

<civodul>yeah

<Jookia>Where do patches go in the guix tree?

<civodul>i think it'll have to wait until the next full-rebuild cycle tho

<Jookia>Oh, patches

<civodul>exactly :-)

<Jookia>civodul: It's cool, I'm building it all myself because I'm stubborn

<Jookia>Patches don't require hashes? Interesting

<lfam>Jookia: Patches are applied to sources and thus change the hash of the source

<Jookia>Oh, cool

<lfam>Or not of the source but of whatever goes into the store

<lfam>It is accounted for ;)

<Jookia>It bothers me a tad that NixOS doesn't have a way to verify the image you download

<Jookia>Or stable releases for people that don't want to compile constantly

<Jookia>Sorry to bother with all the questions- now my build is failing because of a hash mismatch I assume, is there a way to find out the new hash?

<lfam>Usually in that case it tells what hash it expects and also the hash it actually computes

<Jookia>I get "builder for `/gnu/store/788sjp611abfscl8bb88vnm7j2ppx4lp-coreutils-8.24.tar.xz.drv' failed to produce output path `/gnu/store/g0sn86663570x3jkrl2qmks2n4hqbqhs-coreutils-8.24.tar.xz'" after applying the final patch

<lfam>Is there more?

<Jookia>Yeah, I'll paste my log

<rekado>when there's a hash mismatch Guix reports both hashes.

<rekado>if you don't see both hashes reported then maybe it's not a hash mismatch.

<Jookia>It's not a hash mismatch then, and I'm unsure what's going on- looking at other logs doesn't show patches being applied so I'm not sure what I'm looking for. http://paste.rel4tion.org/217

<civodul>Jookia: "patch: **** Only garbage was found in the patch input."

<Jookia>civodul: Yeah, that looks suspicious

<Jookia>But I don't have the log for a normal .tar.xz build (not sure how to get it either)

<Jookia>Is there a way to get a build log for a tarball?

<civodul>guix build --log-file /gnu/store/g0sn86663570x3jkrl2qmks2n4hqbqhs-coreutils-8.24.tar.xz

<civodul>so the error here is that the patch you added is malformed

<Jookia>civodul: I mean logs from other people's builds of the tarball. And yeah, maybe it's malformed- it'd be helpful if I could step through the build phases and use a shell to see what's going wrong

<civodul>"guix build -S --log-file coreutils" will give you the build log on hydra.gnu.org

<civodul>but no, it's not possible to step through the build phases

<civodul>but i don't think it would help in this case :-)

<Jookia>Ugh

<civodul>ACTION goes afk for a while

<Jookia>In NixOS I often step through the build phases when debugging builds since rebuilding is often costly :\\

<efraim>I'm working on python2-jsonschema atm

<efraim>looks like its going to be a very large commit message

<Jookia>Does anyone know of a command line tool to format a Guile/Lisp document?

<rekado>Emacs in batch mode?

<Jookia>So complicated x_x

<lfam>I used paredit in Vim. It's probably not as good as what you get in Emacs but it helps and it's easy to install

<lfam>use*

<Jookia>Trying to debug a builder

<Jookia>So I figure I'll use Guile to debug the build script

<civodul>Jookia: re formatting, see http://www.gnu.org/software/guile/manual/html_node/Pretty-Printing.html

<Jookia>civodul: Thanks, I'm on my way to hacking together what I want to debug builds

<jubalh>hello

<davexunit>hello

<mark_weaver>civodul: yes, those builds were successful on the second try. I saved the failed logs though. now util-linux on i686 is a problem; it has failed twice in a row. http://hydra.gnu.org/build/934705

<jin_>hi tsyesika, i test with the command 'rmmod usbhid' and the keyboard of the mackbook working fine.

<jin_>the command 'rmmod usbkbd' not working in my macbook.

<civodul>mark_weaver: ok, thanks for letting me know

<civodul>i'll try util-linux/i686 later on

<paron_remote>heya

<paron_remote>if I'm adding a comment above a package ddefinition

<paron_remote>should it be ;; or ;;;

<paron_remote>(explaining why we're keeping the older linux-libre around)

<paron_remote>ACTION guesses 2

<paron_remote>and puts together ptch

<paron_remote>patch

<civodul>paron_remote: roughly two semicolons for line comments, one semicolon for margin comments

<civodul>see "Formatting Code" in the manual ;-)

<paron_remote>right...

<paron_remote>I'm just not sure if this is considered a line comment or a toplevel comment.. :)

<efraim>i'd go with 2

<paron_remote>efraim: thanks :)

<paron_remote>that's what I was thinking as well

<paron_remote>If I'm submitting a patch to follow up to a bug

<paron_remote>I attach that to the bug thread

<paron_remote>and not to devel, right?

<efraim>sounds good

<paron_remote>ahhhh

<paron_remote>so I looked at packaging procmail

<paron_remote>but it's sooooo unmaintained

<paron_remote>so I looked at packaging maildrop, but it has a lot of complexity to package, and when I configured it it tried looking for a directory in /var/ to see if there was a default mail spool (I could fake this I guess)

<paron_remote>and so then I tried fdm

<paron_remote>and that one has a dependency on tdb which can't determine its host type for some reason

<paron_remote>annoying

<paron_remote>ACTION goes back to packaging

<francis7>mark_weaver, I don't think linux is at fault with that epoch thing

<francis7> https://review.coreboot.org/#/c/11853/

<francis7>have a look at this

<francis7> <romanis> hello, i've got a warning message in my dmesg and wanted to know if it's harmless

<francis7>[18:37] <romanis> WARNING: Persistent clock returned invalid value!

<francis7>[18:37] <romanis> Check your CMOS/BIOS settings.

<francis7>[18:38] <romanis> i'm on a t400 using some patches from libreboot

<francis7>[18:42] <icon> romanis: that is a known issue and was fixed recently in upstream coreboot. coreboot accidentally overwrote the century byte on many systems (including all supported thinkpads)

<francis7>[18:43] <icon> romanis: https://review.coreboot.org/#/c/11853/

<francis7>[18:43] <romanis> thanks for the info!

<francis7>[18:45] <icon> romanis: you'd need that patch and have to reset the century byte manually (at least I did it somehow with nvramtool)

<francis7>I'll work on merging this into libreboot now

<francis7>libreboot uses an older coreboot revision. I'll update it eventually, but for now I'll backport this patch

<francis7>actually, looks like I'll have to update the coreboot revision

<paron_remote>francis7: then why is it fine on some kernels and not others...?

<paron_remote>is it hitting a bug in certain particular cases?

<calher>francis7: Does GuixSD run on Libreboot?

<paron_remote>calher: it can

<paron_remote>I run it on libreboot

<calher>yay!

<petter>calher, of interest to you may be that you can run a fully encrypted GuixSD with Libreboot (you can encrypt /boot and everything)

<francis7>paron_remote, that is still unknown

<francis7>and still possible to bisect (linux kernel git repository)

<francis7>according to coreboot though, it's coreboot's problem

<francis7>however, the bug obviously wasn't exposed, and the kernel was changed somehow in later versions exposing the bug. we've seen this before

<paron_remote>I'm not going to have time to bisect it unfortunately

<paron_remote>I think I've done the most I can to identify it and provide a kludge for now

<calher>petter: Wow! Link?

<petter>calher, i don't know of a good link for this. Closest i could find right now is, https://libreboot.org/docs/gnulinux/encrypted_trisquel.html

<petter>The special thing here is that you can put your Grub config file etc in your boot firmware, Libreboot (and Coreboot i guess). Usually Grub would need to get some resources from a partition (/boot)

<petter>i run a fully encrypted GuixSD myself, so i can vouch for that it works :)

<calher>petter: You use GuixSD for everyday stuff?

<petter>Yes

<calher>OMG!

<calher>So nice...

<petter>:)

<petter>Is there something particular holding you back in this regard?

<calher>petter: Not sure how to configure WiFi with command line; can't get Ethernet.

<efraim>wicd-ncurses?

<paron_remote>hm

<giammi_>hello, wanted to download ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.9.0.i686-linux.xz through tor

<giammi_>gives me error: 425 Security: Bad IP connecting.

<giammi_>just want to inform about that

<civodul>giammi_: weird; with "torify wget ..." i get: "Error in server response, closing control connection"

<civodul>giammi_: it works if you replace "ftp" with "http" though

<petter>it works for me with ftp:// in IceCat

<petter>at least it's not all Tor nodes, "just the bad ones"

<giammi_>petter, I tried with tor browser bundle and with tor on firefox

<petter>maybe it will work if you restart Tor or somehow get another exit node

<giammi_>will try again. I can also download it without tor. But I just wanted to give a heads up

<petter>i've restarted Tor twice, which changed exit node each time. From the third node i get a 425 as well

<petter>Yeah, thanks for mentioning it :)

<giammi_>petter, you have more luck than me, tried already 5 times, no success :)

<petter>do you verify you get a different IP?

<giammi_>worked now

<petter>seems like a significant share of Tor exit nodes are currently blacklisted then :(

<giammi_>seems so, it seemed strange to me, that there was a blacklisting on the FSF website

<petter>yeah, i'm pretty it has nothing to do with Tor per se

<giammi_>petter, ok, thanks for your help - will then give guix a go - have a good one - bye

<petter>Great. Good luck, have fun :)

<giammi_>thanks

<civodul>what do people use as an FTP proxy to route FTP traffic through Tor?

<calher>Why proxy?

<civodul>i use Privoxy for HTTP(S), but that doesn't handle FTP

<civodul>calher: because it's easily set up

<calher>torify curl ftp://example.net/example.txt >Example.txt

<petter>ACTION reads up on Privoxy

<civodul>i was looking at implementing 'ftp_proxy' for Guix

<calher> <https://www.gnu.org/software/guix/manual/html_node/System-Installation.html> says "Support for the Logical Volume Manager (LVM) is missing."

IRC channel logs

2016-01-18.log