IRC channel logs

2015-04-20.log

back to list of logs

<pooooooo>hh
<pooooooo>oh
<pooooooo>ohhh
<pooooooo>my anus is so wet
<ijp>guix has officially made it to the big time when you get random pointless trolling like that
*kete did good by ignoring it.
<les>the linux-libre download was indefinetly hanging (or at least hanging for longer than my patience allowed) when a guix pull tried to download it from alpha.gnu.org via ftp
<les>the host i'm doing the guix pull on has both ipv4 and v6 connectivity, I got around it by adding the ipv4 address for alpha.gnu.org to my hosts file
<les>I don't know the proper channels to notify the admins of alpha.gnu.org but it appears their ipv6 ftp configuration is broken
<civodul>Hello Guix!
<rekado_>the only difference between the working and the failing gcc command for awt_Font.o is "-I/usr/include/X11/extensions -c -o ..." and "-I -c -o ..."
<rekado_>so, there's an include without path.
<rekado_>if the path is missing, the -I should not be there either.
<rekado_>(re failing icedtea7 build)
<civodul>rekado_: so the -I "swallows" the -c, which is why it ends up linking it instead of building the .o
<civodul>there you go!
<civodul>it sounds like an empty makefile variable or something
<civodul>could you check that?
<rekado_>it's probably some variable that happens to be empty under guix build
<rekado_>(oops, didn't see your messages)
<rekado_>with all these makefile includes it's going to take me some time to find the offending variable, but I'm happy I finally have something to look for :)
<iyzsong>And about the name of 'icedtea', how about call it 'openjdk'? AFAIK, both debian and archlinux use 'openjdk'. But wikipedia mention something called 'OpenJDK trademark notice', I have no clues ;-)
<rekado_>Gentoo's ebuilds are called icedtea, afaik.
<rekado_>what we deliver with the icedtea packages is not exactly the openjdk.
<rekado_>it's sanitised.
<iyzsong>ok :-
<rekado_>woo, I think I found it! CPPFLAGS += -I$(firstword $(wildcard A) $(wildcard B)) where A and B are both global paths.
<rekado_>neither returns a path, so firstword picks an empty string.
<rekado_>oh, sweet! Ardour 4.0 has been released.
<rekado_>as existing ardour sessions are best opened with the version of ardour that created it I'll just create a new ardour package inheriting from the existing one.
<civodul>rekado_: good news for icedtea! :-)
<rekado_>and it actually builds now!
<rekado_>I see that I can't take over all test-fixing phases from icedtea6.
<rekado_>but this should be easy to figure out.
<civodul>rekado_: excellent :-)
<civodul>you've been very brave ;-)
<boegel>bavier: ping? care to join us in #easybuild?
<civodul>ha ha, competitors are hiring! ;-)
<Sleep_Walker>:))
<civodul>iyzsong: i just marked some of the RUNPATH bugs that you fixed as "done"
<civodul>i might have forgotten some, so don't hesitate to close them if that's the case
<iyzsong>ok
<iyzsong>civodul: the remain are still valid. I have no ideas why 'validate-runpath' phase was skiped for lilv, jack2, etc.
<civodul>i don't think it was skipped
<civodul>not sure what happened though
<iyzsong>I check the latest hydra logs for lilv, jack2, wxwidgets. end with 'skipping RUNPATH validation'. http://hydra.gnu.org/build/381606/log/raw
<civodul>oh
<civodul>ah i see, they use waf-build-system
<iyzsong>and the all have a '0s' duration ;-)
<civodul>that's because #:validate-runpath? defaults to #f in (guix build gnu-build-system)
<civodul>another thing to fix in core-updates
<rekado_>still running the test suites of icedtea7; will have to disable it as there are quite a few failing tests, even upstream. I want to include some information about the failures as comments before I submit my patch.
<rekado_>I just remembered a bug I failed to report officially: our custom GCC packages should not create "gcc" and other executables that are shared among all GCC compilers.
<civodul>oh right
<civodul>i think there's already an open bug report
<rekado_>Installing GCJ, for example also installs a "gcc" executable which lacks a C compiler.
<rekado_>if nobody's working on fixing our racket package (loading some libraries upon eval'ing (require ...)) I'd like to give it a try tonight.
<rekado_>(another bug I just remembered and didn't file a report for)
<civodul>rekado_: here's what i have: http://paste.lisp.org/+35N1
<civodul>preliminary patch, that is
<civodul>but it might be helpful
<civodul>at any rate, i'd be grateful if you work on it :-)
***fchmmr is now known as chmmfr
***chmmfr is now known as mmchrf
***mmchrf is now known as rmmhcf_
***rmmhcf_ is now known as chmmfr_
***chmmfr_ is now known as fchmmr_
***fchmmr_ is now known as iruntrisquel
***iruntrisquel is now known as libreboot
***libreboot is now known as rmmhcf
***rmmhcf is now known as fchmmr
***fchmmr is now known as apt-get
***apt-get is now known as fchmmr
***fchmmr is now known as whois
***whois is now known as rsync
***rsync is now known as fchmmr
***fchmmr is now known as not_not_fchmmr
***not_not_fchmmr is now known as fchmmr
***fchmmr is now known as guix
***guix is now known as fchmmr
<rekado>The Open Tech Summit 2015 (Berlin, May 14) is looking for speakers: http://opentechsummit.net/CallSpeakers.pdf
<rekado>maybe a good opportunity to talk about Guix?
<rekado>I have not been successful so far in getting ibus-setup-pinyin to work :-/
<rekado>ibus-engine-pinyin starts fine.
<rekado>(can't test it all so well because I'm packaging this on Fedora.)
<rekado>with ibus-setup-pinyin I always get this error: "NotImplementedError: structure type 'GVariant' is not supported yet"
<rekado>something to do with gobject introspection, it seems.
<rekado>but I don't know enough about this to fix it.
<rekado>geda-gaf and pcb both come with /share/mime/ stuff that conflicts with what's offered by shared-mime-info
<civodul>maybe it should be removed?
<rekado>hmm, looking at the files they really do add something new.
<rekado>e.g. application/x-geda-gsch2pcb-project:*.gsch2pcb
<rekado>and things like that.
<rekado>can share/mime be merged in profiles automatically?
<civodul>heheh, it could, yes
<civodul>but that doesn't sound so great
<civodul>oops, we don't have any libc.mo
<rekado>civodul: is there an alternative where the additional mime types are preserved? Or is the right way to handle this to just drop the new mime stuff from these two packages?
<civodul>rekado: is it one file per MIME type?
<civodul>if yes, we could keep only the new files in ged
<civodul>*geda