IRC channel logs

<ng0>Maybe it helps someone, with the additions of the work of Nix and Gentoo. I don't really have the time to work on this at the moment

<vagrantc>hrm. so ... on a fairly recently installed guixsd... guix pull just issues a backtrace about wrong type argument in position 1

<adfeno>vagrantc: Could you share the output?

<benny>vagrantc: I had that bug too, it's been fixed now

<vagrantc>benny: so... how do i get the fix?

<benny>well I was lucky, I had one user that could still do guix pull - I don't know how to manually fix it

<benny>what you could try is git clone https://git.savannah.gnu.org/git/guix.git to ~/.config/guix/pull/somehashhere

<benny>I don't know if the hash has to be something specific, I can tell you that commit 4564782c3dac66c9a8a764a696d8bbfb1f33e1ff on my system has the dirname pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq

<benny>I don't know how if that would work but depending on your guix gc usage maybe you can just change the symlink from ~/.config/guix/latest to a different guix-latest in the store which doesn't have that bug

<vagrantc> https://paste.debian.net/995255/ for the error, fwiw

<benny>this was my report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29238

<vagrantc>what took so long is a chain of events to get to something i could cut-and-paste from ... w3m apparently is hard-coded to use /usr/bin/vi or something

<vagrantc>gah. "sudo guix pull" complained about "guile-git" missing. ok. "sudo guix package --install=guile-git" downloads and builds a bunch of stuff. then running "sudo guix pull" complains about "guile-git" missing.

<adfeno>Hm...

<vagrantc>since, that was the only other user that might have had guix installed...

<adfeno>vagrantc: Does `sudo guix package -I | grep guile-git' show you something?

<vagrantc>also, since i'm in north america, is there a recommended mirror to use on the same continent?

<adfeno>... sorry, I mean: what does it show you?

<vagrantc>guile-git 0.0-3.e156a10 out /gnu/store/wgqsgjykxbfnqgzcdk5vdzvz90dxl8h9-guile-git-0.0-3.e156a10

<brendyn>Hmm. I opened up gnu/packages.scm, ran run-geiser and then geiser-eval-buffer but at least most of the definitons are not becoming available in the repl, like find-packages-by-name

<vagrantc>the short of it is i could just re-install, since this is just an experiment to try out guixsd, and hopefully it doesn't happen again

<brendyn>vagrantc: when you run `su' and login, do you have any problems running commands?

<benny>vagrantc: I started experimenting a few days before you and I hope currently it's just a bad time due to 0.13 being very old and some unfortunate timing with the guix pulls

<brendyn>Currently my root has an empty PATH variable for some reason I haven't been able to figure out

<vagrantc>brendyn: not follow what you mean regarding su and login

<brendyn>i mean use su to switch root and try running guix pull

<vagrantc>no root password set...

<benny>well if you have sudo then sudo su -l

<vagrantc>user has guile-git 0.0-4... and root has 0.0-3...

<benny>and both fail with guix pull?

<benny>if one works you can do what I did after the bug report and manually adjust the config symlink

<vagrantc>they fail differently ... the one with the backtrace, the other complaining about guile-git

<adfeno>What if you remove guile-git *from root's profile*?

<adfeno>In my case, I don't have guile-git in root's profile.

<adfeno>.... just in my user's.

<vagrantc>it still complains about guile-git when running guix pull

<vagrantc>specifically: guix pull: error: Guile-Git is missing but it is now required by 'guix pull'.

<adfeno>Are you running guix pull as root? (that is: switching to root login and then run guix pull).

<vagrantc>using sudo

<vagrantc>sudo guix pull

<adfeno>As far as I can tell, since I also need and use sudo, it deals with user-switches differently

<adfeno>I find that you often have to do `sudo -i' alone in order to become and stay as root.

<benny>did you set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH properly?

<vagrantc>"sudo su -" gives the same bug backtrace

<benny>they are suggested at some point after guix pull

<vagrantc>i didn't set anything

<vagrantc>should rebooting be sufficient?

<Shion>I want to publish my project here to let more people know it, do not know if you agree

<benny>not sure if they are added to the global profile

<benny>> guix package -i guile-git

<benny>> export GUILE_LOAD_PATH=$HOME/.guix-profile/share/guile/site/2.2:$GUILE_LOAD_PATH

<benny>> export GUILE_LOAD_COMPILED_PATH=$HOME/.guix-profile/lib/guile/2.2/site-ccache:$GUILE_LOAD_COMPILED_PATH

<Shion>The project will go free software route

<Shion>No one opposed me and made it

<Shion>The final form of the keyboard = ShionKeys

<Shion> https://github.com/ShionAt/Keys

<adfeno>Shion: Hm... Interesting one... I wonder if we could add in the README file an email address or some page having plain text and easy access to it... so that people not using GitHub can also send patches.

<adfeno>.. and describe issues ti be openned.

<Shion>Oh, my English is not very good, I do not quite understand what you mean

<adfeno>Oh.... I found email :)

<adfeno>It's OK, I found email :)

<Shion>I hope someone can help me to promote this project because in the future to launch crowdfunding needs more people to see it

<Shion>Very helpless, I am destitute and destitute, no money to buy advertising

<vagrantc>hm. i've got 8 different versions of guix available, but they all appear to be the same version

<vagrantc>and they all have the same backtrace

<vagrantc>this is looking like reinstalling might be the way to go

<vagrantc>ACTION was hoping to do the next install by building a newer install image to avoid this sort of thing, but whatever.

<adfeno>Try removing the root profile generations that have guile-git

<vagrantc>i've got 4 generations, and they don't really look any different using list-generations, other than the upgraded kernel

<vagrantc>there are enough new concepts here... really guess i should read the manual all the way through

<adfeno>Hm.... so doing something like `sudo -i' (login as root); followed by `guix pull' still gives the same error?

<vagrantc>"sudo -i" gives the backtrace error, just like running as the user.

<vagrantc>"sudo guix pull" gives the guile-git issues

<vagrantc>"sudo su" and running guix gives command not found

<vagrantc>"sudo su -" gives the backtrace

<vagrantc>"sudo -E guix pull" has the backtrace

<lfam>Re: the discussion of how to use `su` and `sudo`, I recommend reading their documentation! The first page of the su manpage says "The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the superuser."

<adfeno>vagrantc: Could you share the backtrace/output?

<lfam>So, you have to use `su --login` in order for it do the right thing. Even on old-school systems that use '/usr', plain `su` rarely does the right thing

<lfam>If using `sudo`, you have to do `sudo --login` if you want to actually work as root

<vagrantc>ACTION hardly ever uses "su" in the last decade or so

<lfam>Same here, but I've seen people have this issue here before

<vagrantc>adfeno: i posted the backtrace a while back... i'll dig it up from backscroll

<adfeno>complementing lfam's last message (about sudo --login), -i is also shorthand for --login.

<vagrantc> https://paste.debian.net/995255/

<vagrantc>seems pretty much identical to the issue benny reported

<vagrantc> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29238

<vagrantc>which is apparently fixed/worked around in newer versions of guix and guile-git ... but with guix being unable to "guix pull" it seems a bit difficult to get the newer versions

<guoruei> https://www.gnu.org/software/guix/download/

<adfeno>vagrantc: Perhaps we can explore the suggestion given by benny...

<guoruei>is the download page no have mips or mipsel or mipsel64 ?

<adfeno>About having a symlink to a previous .config/guix/latest

<vagrantc>i've tried manually running each of the guix versions in the store by calling with full path, and they all have the issue

<adfeno>... I'll search to see what we can do

<guoruei>it have mipsel64 before

<vagrantc>adfeno: so, if i've manually called the binary directly, switching the latest link isn't likely to change much... or does it do more?

<vagrantc>ACTION was pretty aggressive with git gc

<vagrantc>er, guix gc :)

<adfeno>Hm...

<lfam>guoruei: The mipsel64 port is suspended until somebody volunteers to maintain it

<adfeno>I wonder how many guix-latest there are in your "/gnu/store"... at least in my case, I can do a variation of: ls -d "/gnu/store/"*"-guix-latest"

<adfeno>with this one can start comparing for example these by date of creation.

<vagrantc>adfeno: one

<guoruei>lfam: ok...can i use qemu volunteers to maintain it ? or i must have a hardware mipsel64

<adfeno>Oh... OK, so benny's suggestion can't be used here...

<vagrantc>really, this is my first guixsd install ... happy to try again :)

<guoruei>vagrantc: have a good day

<lfam>guoruei: This was the announcement of the suspension: https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00790.html

<adfeno>vagrantc: OK then, I hope you do consider trying again. :)

<lfam>guoruei: If you'd like to help with it, please write to guix-devel@gnu.org and say hello!

<guoruei>lfam: ok ,,thanks..

<adfeno>I must go now, have to sleep....

<guoruei>adfeno: good night

<vagrantc>wow, didn't see the boot logo of the installer the first time just running in a virtual machine ... quirky :)

<lfam>vagrantc: I can fix the w3m editor issue, but I'm not sure how to test the fix. How can I make w3m invoke an editor?

<lfam>Ah, one of the configure options of w3m: --with-browser=BROWSER default browser (/usr/bin/firefox)

<lfam>I thought it *was* a browser ;)

<lfam>I figured out how to invoke the editor

<vagrantc>lfam: go to paste.debian.net and enter something in the text box

<lfam>vagrantc: I can make it use $EDITOR

<lfam>We don't usually hard-code this sort of relationship between end-user applications, so I think using $EDITOR is a good solution for the missing /usr/bin/vi

<vagrantc>it was the first thing i tried and it ignored it, yeah

<vagrantc>or rather, i tried setting EDITOR

<lfam>It describes its behavior regarding the editor in the FAQ: http://w3m.sourceforge.net/FAQ

<lfam>Basically, if there is no hard-coded filename, it uses EDITOR

<lfam>The filename can be hard-coded at compile time or in the runtime configuration

<lfam>We can leave it unset while building

<vagrantc>well, that's responsive ... i mumble about a bug/issue on irc and someone works on a fix :)

<lfam>I wish I had a solution for your actual problem (broken installation)!

<vagrantc>ACTION has a reinstall running

<vagrantc>which i'll use to generate another encrypted install

<bms_>Hello.

<lfam>Hi bms_

<bms_>How are you? And what's happenning here today?

<lfam>I'm alright, trying to use my idle time at work on some Guix stuff :)

<bms_>Cool.

<guoruei>yeah

<guoruei>lfam: is the armhf supp raspberry pi?

<guoruei>i no have mipsel64 hardware ,but i have a raspberry pi

<lfam>guoruei: Yes for Raspberry Pi 2 (armhf) and Raspberry Pi 3 (aarch64), but not the first Raspberry Pi (armv6)

<guoruei>o ,,,no

<guoruei>ok, ihave a raspberry B and B+ and 2B

<lfam>guoruei: Okay, we support the 2B, but not the B or B+

<lfam>Currently, we support using the Guix package manager on another GNU / Linux distro on the 2B. Hopefully the full GuixSD will be supported on the 2B someday, too

<guoruei>lfam: thanks, will try in 2b late

<brendyn>This program looks for the python binary but it's called python3 in guix, and pathshebangs doesn't change python to python3. How do i make it work?

<benny>brendyn: python-wrapper can be installed so python points to python3

<guoruei>I lost contact with all people who use gNewSense .

<guoruei>is one distribution this page https://www.gnu.org/distros/free-distros.html

<guoruei>o my god

<Digit>hmm?

<brendyn>Bleh I've spend ages trying to figure out how to compile this c++ program with debugging symbols but it's still not working.

<brendyn>Can anyone spot why this c++ snippet would cause a segfault? https://paste.debian.net/995288

<taylan>brendyn: out isn't initialized?

<taylan>the compiler should warn about that even

<brendyn>I think I had that before but it only issued a warning

<taylan>also the out = "" wouldn't help either, even if it weren't commented out

<taylan>well, "" isn't a char** anyway

<brendyn>does it need to be char** out = ""; ?

<taylan>that won't compile I think, because "" is a char* not a char**

<brendyn>Hmm that caused an error

<taylan>are you sure it must be char** and not char* anyway?

<slyfox>you need to allocate memory for 'char** out;'

<taylan>I'd have thought: char* out = malloc(...)

<taylan>no need for the additional layer of indirection

<taylan>well, does C++ even use malloc? more fundamentally, maybe you want std::string not char*

<brendyn>Well I've never written any C/C++ before I got my friend to help me with this but it segfaults and I'm left trying to debug it

<taylan>C/C++ aren't very friendly for beginners

<taylan>ACTION needs to reboot

<OriansJ>brendyn: this would probably be closer to what you want https://paste.debian.net/995300/

<fps>this is not idiomatic c++

<fps>oh, they're gone already

<janneke>fps: yeah, that's C

<lfam>Sometimes Guix is trying to download a source file that is brand new, and may not be available on all the upstream mirrors yet. The HTTP/S links fail quickly, but the FTP links take a looooong time before giving up

<lfam>I think I'm gonna put the FTP links closer to end of the mirror lists

<civodul>lfam: there are (normally) connection timeouts for FTP and HTTP

<civodul>but maybe it's hanging after a successful connection?

<civodul>would be good to see if there are timeouts we could add

<lfam>The FTP timeouts seem to be longer than the HTTP timeouts

<lfam>But I'll take a closer look to see if it's just a particular server

<lfam>It feels like whenever I notice a source download "hanging", it seems to be FTP

<civodul>in (guix build download) it's 10s for both

<civodul>but again, it's only a connection timeout

<civodul>so if the connection succeeds, then there's no timeout

<lfam>Right, this is akin to a 404

<lfam>The connection itself seems to work fine

<civodul>not even, it's just for servers too slow to accept(2) incoming connections

<civodul>(or firewalls)

<lfam>Okay, <ftp://sunsite.icm.edu.pl> returns code 550 right away

<civodul>ok so that's a bad example, right? :-)

<lfam>It might just be ftp.nluug.nl in this case (ImageMagick)

<lfam>No, sunsite is a good example :)

<lfam>Yeah, they don't have the file, but more than 90 seconds have passed with the connection closing

<lfam> http://ftp.nluug.nl/ImageMagick/

<lfam>It finally closed with ERROR: In procedure connect: Connection timed out

<lfam>Heh, the mirror that has the file soonest is go-parts.com, an automotive parts store

<civodul>heh

<civodul>both URLs return immediately for me

<lfam>Huh

<civodul>or did you mean ftp://ftp.nluug.nl/ImageMagick/ ?

<civodul>or does it depend on the client?

<civodul>like 'guix download' vs. wget?

<lfam>This does nothing for a long time for me: `guix download ftp://ftp.nluug.nl/pub/ImageMagick/ImageMagick-6.9.9-23.tar.xz`

<lfam>It's super fast to use the same URL over HTTPS

<mb[m]1>lfam: That throws a 550 immediately on a server behind a properly configured firewall, but hangs "forever" behind a badly configured one.

<lfam>Ah, you mean the local firewall? ;)

<mb[m]1>Errh, yes. s/server/client, even.

<civodul>lfam: i can reproduce it!

<civodul>i don't know if i have anything badly configured here, but i can reproduce the problem :-)

<mb[m]1>FTP is weird :) Many servers only accept "active" FTP, in which case the server initiates the data connection to the client, after the initial establishment of the "control" channel (from client to server).

<civodul>i think it's stuck while in PASV

<mb[m]1>So in "active mode", the local firewall needs to pre-emptively open "all ports" and wait for the server->client connection.

<lfam>It doesn't sound like a configuration one can expect to rely on, in general

<mb[m]1>No, I get hit by it regularly, as my home connection is behind a double NAT (don't ask...) in which case active FTP is flat-out impossible.

<civodul>anyway, we can probably move ftp:// URLs to the bottom of mirror lists and/or remove some of them

<mb[m]1>So I keep adding HTTP mirrors before FTP ones..

<lfam>I can move them to the end of their respective lists now

<civodul>yeah

<lfam>What about this issue on Hydra with the kernel?

<lfam>The xorg mirror is organized geographically!

<civodul>lfam: hydra, well!

<lfam>Can we just try building and installing a new one?

<civodul>not really

<lfam>I have to admit, I don't really understand why the evaluation fails like that

<lfam>I guess something from core-updates did get built?

<civodul>wait, it's the builds that fail, right?

<lfam>Yeah, for example: https://hydra.gnu.org/build/2349297

<mb[m]1>"FATAL: kernel too old"

<civodul>really cool

<civodul>:-)

<civodul>i suppose it's from ld.so

<civodul>these "module-compiled" derivations are not offloaded, hence the failure

<mb[m]1>Right.

<civodul>so yeah, we need to do something :-)

<civodul>we could also get berlin started on core-updates

<civodul>ACTION -> zZz

<civodul>good night/day!

<mb[m]1>gn!

<lfam>I could use a boilerplate response for questions about "guile: warning: failed to install locale"

<mb[m]1>"Remember to export GUIX_LOCPATH for the daemon and the invoking user"

<vagrantc>after some guix operations, i've often seen things suggest to export some variable or another ... does that mean just in the local session? would logging out and logging back in again fix it? or do i need to add it to /etc/environment or /etc/profile or something?

IRC channel logs

2017-11-12.log