IRC channel logs


back to list of logs

***Richus_Torvman is now known as Linard_Torvman
<divansantana_>Good early morning all (here in South Africa)
<divansantana_>guix pull is failing for me and not sure why. Any ideas?
<Rukako>divansantana_: it's a known issue
<Rukako>one sec, someone posted a solution a while ago
<Rukako>guix pull --commit=5d669883ecc104403c5d3ba7d172e9c02234577c
<divansantana_>Rukako: thanks a lot :)
<Rukako>you are welcome!
<brendyn>I tried guix pull --commit=5d669883ecc104403c5d3ba7d172e9c02234577c
<brendyn>before upgrading and now have some new errors
<civodul>Hello Guix!
<janneke>hi civodul!
<Rukako>civodul: c-could I ask for some help?
<Rukako>I have waitpid on handle-SIGCHLD fail with ECHILD for reasons that I can't comprehend
<Rukako>the fact that it waitpid is called with WAIT_ANY and WNOHANG makes it even weirder
<civodul>hi Rukako, sure!
<civodul>ACTION looks up the man page
<Rukako>I use make-forkexec-constructor with (list "sh" "-c" "echo 1 >> /home/user/test") as the command
<civodul>ECHILD -> "The calling process does not have any unwaited-for children."
<Rukako>yeah, this is weird considering that this happens in the sigchild handler
<Rukako>after echo exits sigchild is delivered to shepherd and waidpid fails somehow
<civodul>in this case ECHLD happens because the calling process has no child processes at all
<civodul>for example, if you spawn a new REPL and type: (waitpid WAIT_ANY WNOHANG)
<civodul>you'll see that you get ECHILD
<Rukako>yeah, I can understand that
<civodul>so perhaps your 'sh' process already exited by the time you call 'waitpid'?
<Rukako>what seems weird is that waitpid is called after the child that I started exited
<civodul>hmm actually no
<Rukako>huh? I thought that you were supposed to call waitpid after exiting, no?
<civodul>did you see 'waitpid*' in (shepherd service)?
<Rukako>this is where it happens
<civodul>ok, so you get that warning message, right?
<Rukako>warning: 'waitpid' -1 failed unexpectedly: No child processes
<civodul>it could be that it already happens on master, no?
<civodul>actually ECHILD is not all that unexpected because of the loop in handle-SIGCHLD
<Rukako>I could check it, but I don't think so
<Rukako>would it not return (0 . _)?
<Rukako>as per the manual
<civodul>what would return that?
<civodul>waitpid* never throws
<Rukako>> The process ID of the child process, or 0 if WNOHANG was specified and no process was collected.
<civodul>i suggest looking at waitpid(2) instead when in doubt :-)
<civodul>the Guile manual might not have as many details in some cases
<civodul>but yeah, like i wrote, it seems to me that waitpid* is bound to get ECHILD once in a while
<civodul>so perhaps it should not emit the warning when errno = ECHILD
<Rukako>the wnohang thing and waitpid returning 0 is also on the info page it seems
<Rukako>I will make a few tests with the one from master
<Rukako>okay, this is weird
<Rukako>waitpid still gives -1
<Rukako>but at least the respawning mechanism works
<civodul>Rukako: you get that on master, right?
<Rukako>well, the 4.0 tar actually
<civodul>again looking at the loop in handle-SIGCHLD, i think it's expected to get ECHILD
<civodul>you should consider cloning the repo :-)
<Rukako>my actual work is based on master
<civodul>so we can easily integrate your work
<civodul>ok, good
<civodul>ACTION prepares to push the new pull
<Rukako>civodul: is breaking compatibility ok?
<Rukako>and by breaking compatibility I mean letting respawn? take non-boolean values
<Rukako>right now I have simply added a second field in <service>
<civodul>Rukako: sure, i'd prefer to discuss the details of the API on the mailing list, but why not
<snape>Rukako: dumb question: why do you use 'make-forkexec-constructor' with a command that returns immediately?
<cbaines>Just looking at fixing the Rhythmbox package build, there is a patch in the upstream git repository. Is it preferred to commit it to guix, or use a (origin ...) record?
<cbaines>I thought it was possible to download patches, but I'm having trouble finding an example...
<Rukako>snape: I use it for the systemd ExecStart thing
<snape>make-forkexec-constructor's point is to handle commands that don't return
<snape>if yours returns, you should use system* instead
<civodul>cbaines: it's possible to download patches, but if you do so, make sure the URL is stable enough
<civodul>i think icecat and bash do that
<cbaines>awesome, I'll take a look at those
<snape>Rukako: and then you check its return value
<Rukako>system does not let you change user, group, env, workdir, etc, does it?
<snape>(or execl)
<snape>Rukako: system doesn't do that, but you can do it nonethelessa
<snape>there is an example here:
<civodul>dear Guix, the new 'guix pull' has landed
<snape>Rukako: the pg_ctl returns immediately but we wrap it so to change the user and group
<roptat>I don't know what it does yet, but I'm sure it's great :)
<snape>civodul: I'll test it now, thank you!!
<Rukako>snape: thanks for that
<Rukako>though, I do wonder, is there any negative in using make-forkexec-constructor with processes that exit?
<snape>yes it's very negative :-)
<snape>it just won't work
<Rukako>why though? just trying to understand
<snape>yes I'm thinking about how to explain
<snape>imagine 'system' were to spawn a non-returning command. It wouldn't return either and the whole Guile program would block endlessly. That's why 'make-forkexec-constructor' forks it. The child process runs the non-returning command, w
<roptat>civodul: it's still not enough to build with only 512 MB of RAM, right?
<civodul>roptat: probably not, but this part doesn't change compared to master
<snape>and the original process checks its PID to the guile program knows it
<roptat>civodul: ok
<snape>s/to/so that/
<snape>but if the process returns immediatly, the PID check will fail (because the child is dead already) and the Guile program never knows about the PID.
<Rukako>okay, I think I understand
<Rukako>thank you
<snape>which is fine because you never need the PID of a program that returns immediately
<snape>but you don't need the error
<roptat>civodul: can I still use a git checkout pointed to by ~/.config/guix/latest?
<civodul>roptat: no
<roptat>you broke my server then :/
<roptat>or maybe I can somehow bring ~/.config/guix/current over to my server
<roptat>what if ~/.config/guix/current doesn't exist?
<civodul>it's created
<roptat>I mean I can't run guix pull on my server, so what should I do?
<roptat>I used to send a git checkout that I built on another computer to the server to upgrade my guix
<snape>roptat: xD
<civodul>oh i see
<civodul>roptat: you can always offload, or use substitutes
<civodul>"make" uses as much memory as "guix pull" though, so how did you handle it?
<roptat>I built it on another computer, then sent the result to the server
<civodul>that's something you can still do
<roptat>sometimes it broke config.scm, but that's easy to fix
<civodul>so basically you can 'guix pull' on one machine, and then 'guix copy' the result
<snape>doesn't that build depend on store files that might not be on your destination server?
<civodul>or just run 'guix publish' on a pull-capable server
<civodul>snape: no
<civodul>well, 'guix copy' copies everything that's missing on the target anyway
<roptat>I see, since current is now a profile, I can use guix copy
<roptat>need to look in the manual
<civodul>when you give it a try, let me know how it goes
<roptat>although, how can I send the full profile?
<snape>civodul: I'm talking about the build roptat sends (scp or something?) to his server. I used to do that too and had issues because that build depended on store files.
<roptat>snape: I only had issues with config.scm sometimes
<roptat>I just replaced any store item that didn't exist with an (older) existing one
<cbaines>The guix pull progress indication seems pretty nice, I guess that's new :)
<cbaines>I haven't used guix pull in quite a while...
<civodul>roptat: that's terrible :-)
<civodul>ACTION has to go
<soundtoxin>roptat: finally got around to rebooting, mpd works right now but I have the pulse issue I mentioned in the past
<soundtoxin> here's a scrot of pavucontrol after a fresh boot
<soundtoxin>says it can't connect for some reason
<soundtoxin>but if I search 'pulse' in htop, it is indeed running
<soundtoxin>in the past I killed and restart pulse in this situation because something wasn't getting sound, but as long as stuff works I might leave it
<soundtoxin>is there a way to check if mpd is using alsa or pulse?
<roptat>soundtoxin: according to its configuraton, it's using pulse
<roptat>maybe mpd starts pulse before x11 and that leads to x11 not knowing where to find it?
<soundtoxin>ah that's an interesting thought
<soundtoxin>could be
<pkill9>soundtoxin: what's the mpd you fixed/are fixing?
<pkill9>mpd issue*
<soundtoxin>it wouldn't play songs, it'd be stuck at 0:00 with no sound
<soundtoxin>but for some reason running mpd and specifying the config from the store worked
<soundtoxin>and herd's mpd service wasn't working
<soundtoxin>I hadn't rebooted in a month, and now I did
<pkill9>oh so you're not using it through herd, just running it as a user?
<soundtoxin>no, I am using it through herd
<soundtoxin>it wasn't working before, but during testing I tried running it from a shell for debugging purposes
<soundtoxin>but then it just worked
<pkill9>ah, i'm currently just running it as a user, but i'd rather run the herd service but it doesn't work for me because it doesn't connect to my user's pulseaudio server
<soundtoxin>that is quite possibly the issue I was having
<pkill9>can you post the mpd config you configured it to use?
<soundtoxin>okay I'm gonna restart pulse and see if mpd keeps working
<soundtoxin>ACTION sighs
<soundtoxin>okay after restarting pulse it's broken again
<soundtoxin>should I file a bug report then? on fresh reboot, mpd works, but pulse can't be accessed by pavucontrol. after killing pulse and opening pavucontrol, I can see my volume controls, but mpd no longer works
<soundtoxin>oh I've got one more thing to test... I'll kill pulse and then try to play something with mpd instead of opening pavucontrol
<soundtoxin>that works
<soundtoxin>so basically mpd HAS to be the one to start pulse or it can't connect to it
<soundtoxin>and then again pavucontrol can't view my volume controls after mpd started pulse
<pkill9>yeah may as well
<pkill9>dunno if it's a bug with mpd or guix's mpd service
<soundtoxin>I think a time in the past when I brought up this issue, someone claimed to have a similar problem on Debian
<roptat>soundtoxin: can you try starting pulse as user, then restarting mpd? maybe it can find a running pulse process?
<soundtoxin>okay, done. same issue
<soundtoxin>what should be in my bug report aside from a description of the issue? do I need version numbers of stuff?
<soundtoxin>I'll list mpd version and my guix hash thing
<janneke>ACTION is again in libtool fighting country
<janneke>the good news is that i'm progessing into sources that use libtool
<janneke>but i have so much resistance to the "smartness" of libtool
<janneke>CC="gcc -static" -- this is essential
<janneke>but libtool finds and removes the -static flag
<janneke>i fixed/patched this for binutils-2.10.1, but that fix does not work for 2.14.0
<janneke>libtool is much more resilient there
<mbakke>Binutils 2.10? What kind of ancient toolchain are you working on? :)
<janneke>maybe i should ask a libtool developer for help
<janneke>mbakke: i am working to remove GuixSD's bootstrap binaries
<janneke>mbakke: i have just successfully compiled binutils-2.10.1/gcc-2.95.3/glibc-2.2.5 without using any gcc/glibc binary seeds
<mbakke>Right, of course. Strange that the fix differs between versions.
<mbakke>janneke: wooow, amazing :)
<janneke>thanks, yeah i think so too
<janneke>/bin/sh ./libtool --mode=link /gnu/store/d343dj62qy4blycp7y23d4dlnkwlykqk-tcc-boot-0.9.26-0.5d388ab/bin/tcc -static -static -D __GLIBC_MINOR__=6 -g -o size size.o bucomm.o version.o filemode.o ../bfd/ ../libiberty/libiberty.a ./../intl/libintl.a
<janneke>mkdir .libs
<janneke>/gnu/store/d343dj62qy4blycp7y23d4dlnkwlykqk-tcc-boot-0.9.26-0.5d388ab/bin/tcc -D __GLIBC_MINOR__=6 -g -o size size.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a ./../intl/libintl.a
<janneke>hmm, no-one present on #libtool
<janneke>"let me help you, you are probably stupid and erroneously added a `-static' flag -- i'll remove that for you"
<Rukako>would it stop you from making a script that calls gcc with -static?
<Rukako>something like #!/bin/sh\\ngcc -static $@ and call that from libtool?
<janneke>Rukako: that would work, yes
<janneke>howeve, to add such a wraper only to undo the possible damage that a libtool invocation does -- it feels so wrong
<janneke>i'm trying to read and patch the stupid libtool script
<ngz>In the store, within a package directory, where LICENSE.txt README and configuration files are expected to go?
<ngz>In prefix/share/package-name/ ?
<pkill9>i think something like prefix/share/doc/package-name
<pkill9>that's what other packages appear to use
<ngz>Even for configuration files? That's doubtful.
<pkill9>nah, for configuration files it looks like it's prefix/share/package-name
<pkill9>altho they seem to vary, idk
<pkill9>i was talking about the license text fiels
<hulten>Hello Guixers!
<hulten>I am trying to understand some basics in GuixSD.
<hulten>"which mount" gives me /run/current-system/profile/bin/mount
<hulten>In an example cron job, there is this line:
<hulten>(string-append #$findutils "/bin/updatedb")
<hulten>So I understand that, say, the "root GuixSD filesystem" is in /run/current-system/profile/. Is that correct?
<roptat>guix can manage multiple profiles
<roptat>one of these profile is the "system profile", located in /run/current-system/profile/ as you noticed
<roptat>other profiles are "user profiles" located in ~/.guix-profile (including root)
<hulten>OK, that's clear.
<hulten>What about if I use mcron, will I only have the system profile, or also e.g. root's profile (/root/.guix-profile)?
<roptat>none of them actually
<roptat>#$findutils is called a "G-expression", and it is replaced by the path in the store the "findutils" variable builds to
<roptat>so it doesn't need to be in any profile to work
<roptat>basically (string-append #$findutils "/bin/updatedb") translates to "/gnu/store/...-findutils-.../bin/updatedb"
<hulten>Does it need to be configured/"installed" through config.scm?
<roptat>the packages section in config.scm is to fill the system profile, so it's not necessary
<hulten>or can I use any package that is in /gnu/store/?
<roptat>you can use any package, and if it's not yet in the store, it will be installed there
<hulten>Great, this is useful to know, thanks roptat.
<hulten>That's even more fantastic.
<hulten>Now I think I know how to add mount.nfs4 in a crontab.
<hulten>It would be nicer to configure this more "natively" as a file-system thing, but this was difficult, I remember.
<roptat>well, you could use "/run/current-system/profile/bin/updatedb" of course, but if decide your system profile doesn't need findutils, it's broken
<hulten>Now roptat, don't confuse me now :-) What you said before sounds like the right way to do it!
<roptat>I tried to convince you that using "/run/current-system" is not a good idea :p
<roptat>what do you mean by "as a file-system thing"?
<hulten>Yes, then you succeeded (already before trying).
<hulten>So, in the file-systems section, local 'file-system's can be defined.
<roptat>oh I see
<hulten>But if I try to add here an NFS filesystem, my system doesn't boot anymore.
<hulten>And this is a known issue.. at least, it was discussed in this channel before (without a good solution).
<hulten>So for now I'll just add a cronjob @reboot.
<roptat>yes I remember it now
<roptat>I agree it would be nicer to add it in the file-systems section
***nordstrom_ is now known as nordstrom
<pkill9>I ran `guix pull` and now running `guix system reconfigure` returns this error message:
<pkill9>guix system: warning: /root/.config/guix/current not found: 'guix pull' was never run
<pkill9>guix system: warning: Consider running 'guix pull' before 'reconfigure'.
<pkill9>guix system: warning: Failing to do that may downgrade your system!
<pkill9>should I just rename 'latest' to 'current'?
<pkill9>in ~/.config/guix
<roptat>pkill9: you need to run guix pull twic
<pkill9>oh why is that?
<pkill9>i like the new output of guix pull
<roptat>the first one update .config/guix/latest to a version that can build .config/guix/current I think
<roptat>anyway, on the first pull, it didn't create .config/guix/current
<pkill9>it would be neat to have lots of mirrors like archlinux has
<roptat>I'm working on guile-torrent, that could make a nice mirror :)
<Linard_Torvman>bavier`: Are we going to have a qtwebengine package in the future? I thought qtwebengine was considered nonfree.