IRC channel logs

2013-10-28.log

back to list of logs

<a_e>Does it have a release yet?
<wm4>yes https://github.com/mpv-player/mpv/releases
<a_e>Thanks for the info!
<viric>civodul: o/
<civodul>Hello Guix!
<viric>mi atendis vin jam semajnon
<viric>:)
<civodul>mi feriis lasta semajnon :-)
<civodul>*lastan
<viric>homoj kutime duobligas sian ĉeeston ĉe irc, en feritagoj
<viric>:) gratulon
<viric>civodul: how can I run guix in nixos? I don't want to break the store, but I want prebuild binaries
<civodul>viric: "nix-env -Ai guix"
<civodul>if you want pre-built binaries, you need Guix's substituter
<viric>from a guix checkout
<civodul>so basically you need to run guix-daemon
<civodul>or set NIX_SUBSTITUERS accordingly
<civodul>ah
<civodul>well, if you want ot keep running nix-daemon, you need to have NIX_SUBSTITUTERS point to Guix's substituter
<viric>I know how to build guix (with myEnv)
<viric>Ok. and localstatedata=/nix/var
<viric>localstatedir, whatever
<civodul>yes
<civodul>right
<viric>and the guix substituter will be in the checkout
<civodul>yep
<civodul>if you run "make install" it goes to libexecdir
<viric>if I want to hack some guix expressions...
<viric>can I use an installed guix, yet modify guile files of a checkout?
<viric>or I've to run the guix from the checkout?
<civodul>run the "guix" commands from the checkout, like "./pre-inst-env guix build my-package"
<civodul>see "Running Guix before it is installed" in HACKING
<civodul>so you don't have to run 'make install' every time
<viric>yes, I tried that. But I want the substituter thing too, and nix-daemon is started by systemd
<civodul>so you'll have to change your configuration.nix to set NIX_SUBSTITUTERS, or otherwise stop nix-daemon and start it manually
<viric>would the substituter of nixpkgs' guix (0.3) work enough?
<viric>and then call guix from the checkout
<civodul>we should update Guix in Nixpkgs...
<civodul>but it may work well enough yes
<viric>I tried to update simply the tarball, and it fails at one test
<civodul>hm, i should try
<viric>FAIL: tests/nar
<viric>FAIL write-file + restore-file
<viric>FAIL write-file + restore-file with symlinks
<civodul>ouch
<civodul>BTW if you want to add expressions, don't miss "guix import" :-)
<viric>I've yet to understand anything about guix
<viric>I'm only trying to hit as much problems as I can
<civodul>"guix import" allows you to steal expressions from Nixpkgs
<civodul>well, just the base of it
<civodul>:-)
<viric>steal expressions? calling nix-instantiation, or you have a nix parser?
<viric>nix-instantiate
<civodul>yes, via nix-instantiate --xml
<viric>ha, so you have the tools. You only need to write the 'migration guide'
<civodul>heh
<civodul>"guix import" doesn't convert any of the more complex things, like modified phases etc.
<civodul>so you still have to do the hard work
<civodul>but in simple cases, it helps
<viric>clear
<civodul>Steap: you didn't commit the CMake upgrade, did you?
<Steap>civodul: no, Andreas wanted me to make sure it did not break Qt
<Steap>but the thing is, Qt is already broken
<Steap>and we need to fix pulseaudio to fix Qt
<Steap>so I just got drunk instead.
<civodul>ah ok
<civodul>he told me PulseAudio is broken because of me ;-)
<Steap>erf
<Steap>Would be nice to fix this
<Steap>so I can push Cmake
<Steap>and then, Nikita can push gfortran + lapack
<civodul>looks like we have a biiig build log for PA: http://hydra.gnu.org/build/25370/nixlog/1/raw
<civodul>and of course it builds on my machine...
<sdgfgdfgd>civodul: welcome back!
<sdgfgdfgd>I'm planning to finish with the front-ends tonight. I'll send a patch to the list.
<sdgfgdfgd>civodul: FYI, the latest version of gccgo still requires the -g flag. I think I'll add the front-ends in master and bump gcc in core-updates. What do you think?
<Steap>civodul: this can't happen, it's functional programming!
<civodul>howdy sdgfgdfgd!
<civodul>sdgfgdfgd: i'd bump 4.8.2 in master, so we can use it/check if it works
<civodul>and then in core-updates we'll switch to it as the default compiler
<viric>what is the -g flag?
<civodul>debug
<civodul>Steap: does PA fails to build on your machine?
<Steap>civodul: lemme see
<Steap>I think so
<Steap>but I'm not sure
<Steap>civodul: Only one test fails on my box
<Steap>How the fuck is taht possible ?
<civodul>which one?
<civodul>it seems to fail reproducibly on hydra.gnu.org: http://hydra.gnu.org/build/25370/log/tail-reload
<Steap>memblock-test
<civodul>ah, not the same :-/
<Steap>Oh, maybe that's some thread-related issue
<civodul>on hydra it's thread-test.c and volume-test.c
<Steap>civodul: http://lists.gnu.org/archive/html/emacs-bug-tracker/2013-10/msg00056.html why did you close this ?
<civodul>Steap: see the followup at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15564#11
<civodul>well, http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15564#8
<Steap>sure, but that does not tell me how to compile PA...
<civodul>that tells you to fix the /dev/shm symlink
<civodul>which will allow you to build PA
<civodul>:-)
<Steap>yeah, well, that's not exactly user-friendly
<Steap>but I guess we can't do better ?
<Steap>If so, I'd be in favor of disabling the test
<civodul>well i don't really know how, but i'm open to suggestions
<civodul>ah noo, definitely not
<civodul>perhaps guix-daemon could emit a warning when /dev/shm is a symlink, something like that
<Steap>The thing is, as a user, this is __not__ what you want
<Steap>People should not have to mess with /dev/shm
<mark_weaver>I suppose guix-daemon could make a separate bind mount for the target of the /dev/shm symlink.
<Steap>just to install PA (while they are mostly likely willing to install something else)
<mark_weaver>welcome back, civodul! :)
<civodul>hello, mark_weaver!
<civodul>looking at build.cc, the daemon should actually be mounting a new tmpfs on /dev/shm in that case
<civodul>in initChild
<mark_weaver>partly, it depends on how much we care about Guix being meant for running on other distros, or whether we are just aiming for it to be a standalone distro.
<civodul>a bit of both currently, which means we should welcome simple fixes that help other distros
<civodul>Steap: could you run "sudo strace -o log guix-daemon --build-user..."
<mark_weaver>civodul: but you can't make a new mount point on top of a symlink.
<civodul>Steap: err, strace -f
<civodul>Steap: and then "guix build pulseaudio"
<mark_weaver>(afaik)
<civodul>Steap: just to see the lstat("/dev/shm") and what follows
<civodul>mark_weaver: right, but build.cc should fail in that case, and apparently it doesn't
<mark_weaver>hmm
<mark_weaver>given that we are aiming for bit-for-bit reproducable (and thus verifiable) builds, then I wonder if we should be creating our own /dev from scratch anyway, instead of bind mounting it from the host system.
<mark_weaver>and that would solve this /dev/shm neatly, as a side effect.
<mark_weaver>s/neatly/problem neatly/
<civodul>that would even be better, but more work
<sdgfgdfgd>mark_weaver: Have you recieved a reply from RMS regarding FFmpeg?
<Steap>civodul: this seems stalled after "set-paths"
<mark_weaver>I decided not to ask him. It's not worth wasting his time about. I'm reasonably sure that I'm right about that particular point.
<sdgfgdfgd>mark_weaver: I believe that Jason thinks that you don't like the name because of MPEG-LA, but you seem to not like it because of MPEG. Right?
<mark_weaver>I'm not sure that I'm right about the overall decision, but I'm sure that MPEG is an organization worth disliking, and that this belief of mine does not demonstrate that I'm conflating MPEG and MPEG-LA.
<sdgfgdfgd>civodul: Have you read the logs regarding FFmpeg vs. Libav? What do you think?
<civodul>sdgfgdfgd: the IRC logs, no
<civodul>any pointers?
<mark_weaver>Yes, the fact that I count as a (possibly weak) argument against ffmpeg (vs libav) that it promotes the name of a codec family and standards organization that makes free-software-hostile standards, seems to convince jason that I must be confusing MPEG and MPEG-LA.
<sdgfgdfgd>civodul: Sure, wait a second.
<mark_weaver>because he apparently cannot understand why I would have anything against MPEG (Motion Picture Experts Group).
<mark_weaver>well, the part of the discussion relevant to this point are on gnunet_bot logs, but I can't remember the URL and sneek is not around.
<mark_weaver>where are the gnunet logs again for this channel?
<sdgfgdfgd>gnunet.org/bot/log/guix
<mark_weaver>civodul: https://gnunet.org/bot/log/guix/2013-10-27 starting from [21:50:03]
<mark_weaver>civodul: I'm not sure it's worth your time, though.
<civodul>heh, thanks anyway
<civodul>the only question is which one of FFMPEG and libav should be the default in our distro
<mark_weaver>the bad thing is that since our conversation (where he thought I was conflating MPEG and MPEG-LA), jxself left and has not yet returned.
<civodul>the criteria ought to be mostly technical, assuming both are free
<civodul>ok
<mark_weaver>if I see him again, I will try to make peace with him.
<sdgfgdfgd>civodul: IIUC, there are no significant technical differences.
<civodul>mark_weaver: good idea :-)
<civodul>sdgfgdfgd: so we can choose the one that comes first alphabetically :-)
<civodul>(or last)
<sdgfgdfgd>Haha
*civodul remains consensual
<viric>sensual?
<civodul>:-)
<civodul>sdgfgdfgd: how hard would it be to switch to a newer kernel on hydra.gnu.org?
<civodul>it's up to the sysadmins, right?
<sdgfgdfgd>civodul: I think they only manage the firewall. But we'll definitely need their help in case anything goes wrong.
<sdgfgdfgd>civodul: What's wrong with the kernel?
<civodul>it's kinda old, and it might be part of the reason why PA fails there
<sdgfgdfgd>What version are we currently using?
<sdgfgdfgd>civodul: Can we use KVM over IP?
<sdgfgdfgd>Ah, it's a VM, so it won't help, I think.
<civodul>2.6.32
<sdgfgdfgd>viric: Have you managed to install Guix?
<mark_weaver>you don't have any sort of console access that would give you access to grub?
<sdgfgdfgd>I don't think that we have any.
<sdgfgdfgd>civodul: Should I send a letter to Ward?
<viric>I didn't try further
<civodul>sdgfgdfgd: hmm maybe not now
<viric>if I'm silent, it means I don't do much
<civodul>maybe we'll have to actually fix PA instead ;-)
<sdgfgdfgd>civodul: OK.
<sdgfgdfgd>civodul: I've just sent a patch to the list.
<sdgfgdfgd>It builds. I also compiled a simple C program. Should I do anything else to test it?
<civodul>well, install it in your profile, but that should be OK
<civodul>so you can go ahead!
<sdgfgdfgd>Ok, I'll push it soon, then.
<civodul>thanks!
*davexunit learned that debian is choosing between whether to adopt systemd or upstart to replace sysvinit.
<davexunit>what will/does guix do for an init system?
<sdgfgdfgd>dmd
<davexunit>oh yeah. I totally forgot about that.
<davexunit>I hope that works out.
<wm4>what is dmd? I know it as the digital mars d compiler
<sdgfgdfgd>wm4: I'll try to find a link.
<davexunit>wm4: http://www.gnu.org/software/dmd/
<sdgfgdfgd>davexunit: Thanks!
<davexunit>"Daemon managing daemons"
<wm4>thanks
<sdgfgdfgd>wm4: I think you could try it if you check out our QEMU image.
<sdgfgdfgd>But I haven't tried it myself.
<davexunit>I think this has been discussed before, but gnome has a growing systemd dependence which is a bit alarming.
<davexunit>gnome is a GNU project still, right?
<TaylanUB>wm4: Wait, are you actually interested in Guix ? I assumed you just joined the channel for the ffmpeg/libav discussion. :P
<wm4>I did; I just asked because I knew dmd as something else
<wm4>also the systemd drama is somewhat interesting
<sdgfgdfgd>davexunit: http://wingolog.org/archives/2009/12/13/gnu-gnome-and-the-fsf grep for "GNU and GNOME."
<TaylanUB>wm4: Hehe, OK
<davexunit>sdgfgdfgd: interesting
<davexunit>I want to like gnome, I stuck by it after 3.0 happened, but I'm starting to develop negative feelings.
<sdgfgdfgd>davexunit: I don't use GNOME myself, but I think that I'll install to show others that it's possible to have a free and user-friendly system.
<sdgfgdfgd>it*
<TaylanUB>How much are GNOME and GTK tied together ? Perhaps with Guile+GTK, GNU could start a new DE. :P
<davexunit>we could use GTK without the GNOME DE
<gzg>davexunit: I actually very-much like 3.10 -- that being said, I'm to used to my StumpWM, Emacs, Conkeror setup, to seriously consider something so drastically different.
<gzg>TaylanUB: A fair-amount, GTK is moving more and more into the usability paradigm in-which the GNOME project has taken to define.
<davexunit>I also enjoy gnome, though debian doesn't have 3.10 yet (or even 3.8?)
<davexunit>I just find that the term "usability" has come to mean "dumbed down"
<gzg>If we really "shun" GNOME from being officially promoted via GNU, I think Guile-WM looks promising for a general and flexible toolkit/environment -- especially if we can port it to a Wayland Compositor.
<davexunit>I like stumpwm, but I haven't had the time to configure it much. is there a place where I can find some extensions similar to emacs package repositories?
<gzg>davexunit: Not that I'm aware.
<davexunit>I feel like I'm starting from square-one too much with it.
<davexunit>it can be overcome if I spent more time with it, but that's my impressino.
<davexunit>impression, even.
<gzg>davexunit: Well guile-wm is like a 1000x "worse" in that regard ... :^P Skim around for config files? I can post mine thus far, but it's like only half finished and I'm using waiting on guile-wm, for me to port it over as an excuse not to finish it. :^P
<davexunit>gzg: I would be happy to get in on the "ground floor" with guile-wm though because i'm a huge guile fan, but only lukewarm about common lisp.
<TaylanUB>Hrm, I'm realizing just now that WMs are more like X-interaction shells than window managers.
<gzg>davexunit: Well feel free to have at it! It's been about a month since there's been any work on it. I'd love to see and I probably will (need to pull myself out of this pity-pot first ...) to implement a ratpoison like wm in it.
<TaylanUB>For some time I lamented on the fact that they take a lot of WM-irrelevant functionality, like binding keyboard shortcuts, but now that I look at them as an X-interfacing tool it makes sense.
<TaylanUB>I should see if I can replace ratpoison with guile-wm some time.
<davexunit>my knowledge of X is low, but I did discover guile with the idea of writing a scriptable WM in Scheme.
<davexunit>so I'm glad to see that someone has already started the project.
<a_e>df -h
<civodul>hey there
*civodul oO( we need a news item for the MIPS port )
<sdgfgdfgd>civodul: I can't make your frontend code work.
<civodul>then it's probably not mine
<civodul>;-)
<civodul>can you copy/paste the code and the error?
<sdgfgdfgd>civodul: I get "ERROR: Unbound variable: remove". I tried to import SRFI-1, but it didn't help.
<sdgfgdfgd>Frankly, I don't understand why it fails, but it's probably connected with the host/build distinction.
<civodul>sdgfgdfgd: you need srfi-1 on the build side
<civodul>that is, #:modules (... (srfi srfi-1))
<sdgfgdfgd>Ah.
<civodul>replace the ellipsis with the other modules
<sdgfgdfgd>OK, I'll try that.
<civodul>i think there are examples around
<civodul>well, the one in base.scm
<sdgfgdfgd>Thanks, I'll take a look.
<sdgfgdfgd>It's frustrating that I can't do lots of things on my own. Sorry about that.
<civodul>i understand the frustration, but no need to be sorry
<civodul>surely that also means we can improve on things like error reporting
*civodul posted a news item
<sdgfgdfgd>Hah, Mark definitely did a lot of work, not sure about the other person, though.
<civodul>com'on, be kind to that person ;-)
<civodul>that person initiated the whole process and probably sweat a lot
<sdgfgdfgd>Haha
<sdgfgdfgd>civodul: Will we remove the mips64el branch?
<sdgfgdfgd>It seems useless.
<sdgfgdfgd>I'm using Mark's branch on my YeeLoong.
<civodul>sdgfgdfgd: probably yes
<civodul>you might want to double-check to make sure nothing's missing in the new branch
<Steap>civodul: so, what was interesting to know about /dev/shm in the log ?
<Steap>I've located 'lstat("/dev/shm"/, ...)
<Steap>'
<mark_weaver>has anyone tried to build gdb recently? it fails for me in such a way that I doubt is platform-specific.
<mark_weaver>the failure is due to something trying to run /bin/sh
<sdgfgdfgd>mark_weaver: I could try to build it if you want.
<mark_weaver>please do. I guess I should try on my x86_64 box too.
<sdgfgdfgd>Will do shortly!
<mark_weaver>sdgfgdfgd: if you build for MIPS, make sure to pull the latest 'loongson', which includes a fix to the opcode table for Loongson-specific SIMD fused multiple-add instructions.
<sdgfgdfgd>civodul: I still can't make it work. I've tried ((#:modules _) '((srfi srfi-1))).
<civodul>mark_weaver: gdb builds on Hydra, FWIW
<sdgfgdfgd>I'll try on i686, it should be much faster.
<mark_weaver>civodul: okay
<civodul>sdgfgdfgd: that should be #:modules ((guix build gnu-build-system) (guix build utils) (srfi srfi-1))
<civodul>as for gcc-cross-boot0 in base.scm
<mark_weaver>sdgfgdfgd: makes sense.
<civodul>Steap: it's about line 2125 in libstore/build.cc
<civodul>Steap: do you see mount(2) after that?
<sdgfgdfgd>civodul: Ah, should I specify the first two whenever I change the build-side code?
<Steap>civodul: yes, it returns 0
<civodul>Steap: can you paste that line?
<civodul>sdgfgdfgd: yes, because gnu-build-system.scm provides %standard-phases, and the other one is a dependency of gnu-build-system.scm
<Steap>mount("none", "/nix/store/7arwrl93qdnby42nd2jpca6z6hf80mim-pulseaudio-4.0.drv.chroot/dev/shm", "tmpfs", 0, NULL) = 0
<civodul>interesting
<civodul>indeed, mounting on a dangling symlink works
<civodul>woow
<sdgfgdfgd>civodul: I think we've already discussed it, I just forgot. But is there a way to make it work without the first two modules (in theory)?
<civodul>ah no, wait
<mark_weaver>Here's the tail of my failed gdb build log: http://paste.lisp.org/+2ZS6
<civodul>mark_weaver: on MIPS>?
<civodul>i think that's because mips uses cgen-produced stuff
<civodul>whereas intel doesn't
<sdgfgdfgd>civodul: I think mark_weaver was building on MIPS.
<civodul>mark_weaver: indeed ↑ http://hydra.gnu.org/build/24408/log/raw doesn't enter sim/testsuite
<mark_weaver>ah, okay
<mark_weaver>yes, that was on MIPS.
<civodul>(and cgen = Guile, so yeaaah for MIPS ;-))
<civodul>Steap, mark_weaver: got it: mount(2) in build.cc succeeds, but mounts on the symlink's target, leaving the symlink unchanged; thus, after the call to chroot(2), we still have a dangling symlink
<mark_weaver>civodul: ah, good hunting!
<mark_weaver>maybe we should do the mounts after chroot instead of before?
<civodul>what we could/should do is ensure that /dev/shm is a real directory
<mark_weaver>well, I guess that still won't work.
<civodul>hmm
<mark_weaver>but how can we do that if /dev is a bind mount from somewhere else? we'd mess up /dev/shm for the outside system, wouldn't we?
<mark_weaver>(that's in response to "ensure that /dev/shm is a real directory)
<civodul>well, currently we just ensure that it exists ('pathExists')
<mark_weaver>I guess this once again comes back to: don't bind mount /dev from the outside system. synthesize it from scratch instead.
<civodul>instead we would lstat and check the st_type
<civodul>yeahh
<mark_weaver>civodul: is it expected that several "Makefile"s in the failed gdb build directory contain "SHELL = /bin/sh" ?
<civodul>mark_weaver: no, this is normally handled by the patch-makefile-SHELL calls
<civodul>from the patch-generated-file-shebangs phase
<civodul>but presumably those makefiles you see were created in a later phase
<civodul>(like "make" runs ./configure in a sub-dir)
<mark_weaver>civodul: indeed, several configure scripts are run after the 'patch-generated-file-shebangs' phase. what do you recommend?
<mark_weaver>what's the usual way of dealing with that, I mean.
<mark_weaver>'make' runs configure in: ./libiberty ./intl ./bfd ./opcodes ./etc ./libdecnumber ./readline ./sim ./gdb
<mark_weaver>all of that happens after the 'patch-generated-file-shebangs' phase.
<mark_weaver>in case it helps, the full build log is here: http://www.netris.org/~mhw/wlzkfpfvbi8cazmpqr339c8z73dw1gdl-gdb-7.6.1.drv.bz2
<civodul>i think i had such a case already
<civodul>lemme check
<civodul>mark_weaver: in gdb itself there's already an additional phase for that patching
<civodul>perhaps you can just augment it?
*mark_weaver looks
<mark_weaver>ah, okay. thanks!
<mark_weaver>civodul: should I patch every Makefile.in that corresponds to an unpatched 'Makefile' in the failed build dir? or should I just patch the one in sim/testsuite and incrementally add more as I run into problems?
<mark_weaver>(the others are in ./etc ./bfd/po ./sim/common ./sim ./opcodes/po ./readline ./readline/shlib ./readline/doc ./readline/examples)
<mark_weaver>sorry, not ./sim. but the others, yes.
<mark_weaver>I guess the advantage of doing them all is it makes us more robust if one of those other Makefiles starts to use SHELL in a later version.
<civodul>mark_weaver: yes, you could patch (find-file "." "Makefile\\\\.in")
<mark_weaver>okay, thanks!
<civodul>i think i had a good reason not to do that by default
<civodul>(exercise left to the reader)
<mark_weaver>heh :)
*mark_weaver tries to build gdb again with that fix.
<mark_weaver>going afk for a while...
<sdgfgdfgd>mark_weaver: I'm building gdb and see lots of errors, like "no fileid for localhost". How bad is this?
<mark_weaver>sdgfgdfgd: I didn't see those errors. I don't know how bad they are.
<mark_weaver>but it's interesting that you see them and I don't.
<mark_weaver>sdgfgdfgd: but maybe I didn't see them because I didn't get that far, or because I never built on 686 (or even x86_64 yet)
***Infiltra1or is now known as Infiltrator
***Infiltrator is now known as Infiltra1or
***Infiltra1or is now known as Infiltrator
<civodul>Steap: i was preparing a bug report, but the PA build eventually passed on Hydra...
<civodul>i think it's a timing issue
<mark_weaver>sdgfgdfgd: I checked my gdb-7.6.1 build log on my x86_64 box, and "fileid" doesn't appear anywhere in the log.
<mark_weaver>though I built it on Oct 6. Maybe something changed since then.
<Steap>civodul: I still won't be able to build Qt :/
<sdgfgdfgd>mark_weaver: I could try on the other system of mine later. I assume the problem is on my side.
<civodul>Steap: why? /dev/shm?
<sdgfgdfgd>mark_weaver: How long does it take to build gdb on your x86_64 machine?
<sdgfgdfgd>Mine is running the testsuite, but the CPU usage is too low. I assume that something is wrong.
<sdgfgdfgd>Here's the third from last line: "Running ./gdb.gdb/xfullpath.exp ..."
<sdgfgdfgd>I've stopped it. Unless I forget, I'll test on the other machine tomorrow.