IRC channel logs


back to list of logs

<sartre>The installation boot message is not very encouraging, "Thanks for being so brave."
<zacts>hi guix
<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
<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`
<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:
<tsyesika>lfam: great, don't know how i missed that
<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
<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>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
<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?
<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> Seems to be documented upstream maybe
<Jookia>I'll check to see if fixes it
<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.
<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
<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 :-)
<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
<Jookia>Trying to debug a builder
<Jookia>So I figure I'll use Guile to debug the build script
<civodul>Jookia: re formatting, see
<Jookia>civodul: Thanks, I'm on my way to hacking together what I want to debug builds
<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.
<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>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
<civodul>paron_remote: roughly two semicolons for line comments, one semicolon for margin comments
<civodul>see "Formatting Code" in the manual ;-)
<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>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>ACTION goes back to packaging
<francis7>mark_weaver, I don't think linux is at fault with that epoch thing
<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:
<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
<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,
<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?
<calher>So nice...
<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.
<giammi_>hello, wanted to download 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 :)
<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 >Example.txt
<petter>ACTION reads up on Privoxy
<civodul>i was looking at implementing 'ftp_proxy' for Guix
<calher> <> says "Support for the Logical Volume Manager (LVM) is missing."