[04:52] <Mithrandir> good morning
[06:13] <fabbione> morning
[06:15] <Mithrandir> getting up late, fabio? ;-)
[06:16] <Mithrandir> bah, leaving for airport
[06:17] <fabbione> Mithrandir: ehehe later :)
[09:34] <chmj> morning 
[10:10] <infinity> fabbione : Dude, why does linux-headers-2.6.12-3 have a versioned dependency on libc6?
[10:11] <fabbione> infinity: because the headers contains a bunch of executable in script/
[10:11] <fabbione> same reason why they are arch: any
[10:11] <fabbione> and not arch: all
[10:12] <infinity> Ugh.  Okay, the better question is "why are we shipping script/"?
[10:12] <infinity> scripts, even.
[10:12] <fabbione> because they are required for linking
[10:12] <fabbione> at MODPOST stage 2
[10:13] <fabbione> the same reason why ppc64 headers are borked
[10:13] <infinity> Including the binaries?
[10:13] <fabbione> yup...
[10:13] <infinity> Cock.  That's retarded.
[10:13] <fabbione> the binaries are little utilities very arch specific required for linking
[10:14] <infinity> We should at least move scripts/ to the flavour-specific packages, then, and make the big linux-headers arch:all, no?
[10:14] <fabbione> infinity: that's basically required...
[10:14] <fabbione> to unfuck ppc64
[10:14] <fabbione> but i need to review the overall build process
[10:14] <fabbione> because the binaries are built once from another source dir :/
[10:14] <fabbione> this system is sick
[10:15] <fabbione> breezy+1 must be a royal cleanup
[10:15] <fabbione> otherwise you can do it while i will be VAC
[10:15] <fabbione> or start now? ;)
[10:15] <infinity> If I do it, we'll end up with something much sicker. :)
[10:15] <fabbione> ahaha
[10:15] <infinity> Mostly because the current situation just looks SO EFFIN WRONG to me.
[10:16] <fabbione> infinity: ideally we should switch to the new debian build system
[10:16] <fabbione> but i don't have the time/power atm
[10:16] <infinity> (This arose from a desire to install headers on hoary, which is impossible, for no sane reason other than upstream crack)
[10:17] <infinity> Is Debian's new system nicer to work with?
[10:17] <fabbione> why on earth do you want to do that?
[10:17] <fabbione> infinity: i know they are working on a much cleaner build system similar to our but sane
[10:17] <infinity> Because I'm running a stock breezy kernel on hoary on my laptop, because the hoary kernel suck monkey balls on my new hardware.
[10:17] <fabbione> i had really no time to look at it yet
[10:17] <infinity> (WiFi drops out constantly, machine crashes, my grandmother gets cancer, y'know.. the usual)
[10:18] <fabbione> yeah yeah... time to change hw
[10:18] <fabbione> the kernel is fine :)

[10:19] <infinity> I'm pretty sure it all comes down to the ipw2200 driver being in constant flux, and my 2915ABG being very poorly supported in hoary.
[10:19] <infinity> No big deal.
[10:19] <fabbione> yeah
[10:20] <infinity> If this mystical new Debian kernel build system works, I'll be happy to investigate a switch.
[10:20] <fabbione> infinity: it's in SVN
[10:20] <fabbione> it looks easier.. or it sounds like..
[10:20] <fabbione> but it's not stable
[10:20] <infinity> dilinger : ping.
[10:20] <fabbione> they are still fluxing around some stuff
[10:21] <infinity> dilinger : Make me your bitch.
[10:21] <infinity> Stable isn't such a big deal, as long as we can cut something useable for ourselves for breezy, and merge back in sync post-breezy.
[10:21] <infinity> It's not like what we HAVE is any good either.
[10:22] <fabbione> well it is.. they are still shifting pkgs name around :P
[10:22] <fabbione> we know that our work
[10:22] <fabbione> to a certain degree
[10:22] <infinity> With enough massaging.
[10:22] <fabbione> nah it doesn't need that much
[10:22] <fabbione> we were not ready to do cross-compiling.. that's all
[10:22] <fabbione> and these are bits and pieces that are coming while we grow
[12:51] <fabbione> infinity: i think scripts is the only thing that is more arch specific than the headers
[12:51] <fabbione> at least from a first check
[12:51] <fabbione> the reason why linux-headers (generic) is not arch: all is because we can apply (and we do) arch specific patches
[12:51] <fabbione> otherwise kernel and headers won't match
[12:52] <fabbione> so in theory fixing scripts/ should be enough
[01:38] <zul> hey
[01:58] <fabbione> hey zul
[02:09] <zul> hey fabbione how goes it?
[02:15] <fabbione> zul: no too bad.. going off line for a little nap now
[02:19] <zul> cool...am at work
[04:37] <zul> fabio im back as of tonight..
[04:38] <dilinger> fabbione: hey, did you see my config tool thingy?
[04:38] <dilinger> zul: you too..
[04:39] <zul> dilinger: nope i havent been busy getting settled in with my new job
[04:39] <dilinger> http://svn.debian.org/wsvn/kernel/trunk/scripts/?rev=0&sc=0
[04:39] <dilinger> initsplit for breaking up the configs, and split-config for managing them
[04:40] <dilinger> try it out, find bugs, fix or report them ;)
[04:40] <zul> ok cool...ill try it out tonight
[04:50] <fabbione> hey dilinger 
[04:50] <fabbione> no i had no time really..
[04:50] <fabbione> i am fighting with a bunch of things all together
[04:50] <dilinger> ok, well, when you get the chance..
[04:50] <dilinger> i'm already finding it hugely useful
[04:50] <fabbione> sure i will
[04:50] <dilinger> changing config options across 5 different archs, some 20-something flavours :)
[04:50] <fabbione> or better i must :)
[05:02] <fabbione> YAY
[05:02] <fabbione> finally i got to fix the ppc64 headers
[05:02] <doko> l-k-h?
[05:02] <fabbione> damn the header pkg is getting a mess
[05:02] <fabbione> doko: nope.. the real kernel headers
[05:04] <fabbione> doko: i just finished to build gcc 4.0.1 on sparc.. (test build)
[05:04] <fabbione> i am will soon let you know about the ICE and the LINKING thing
[05:05] <doko> any changes needed? I was going to make a new 4.0 upload today
[05:06] <fabbione> doko: no changes.. but i will not be able to build it until cairo and gtk+2.0 are rebuilt
[05:06] <fabbione> hi lamont
[05:07] <fabbione> there was a leak of libXrender.la in some /usr/lib
[05:07] <fabbione> that will make it FTBFS
[05:07] <fabbione> doko: if you can give me something like 30 minutes to check a couple of things i would be really grateful
[05:08] <doko> no problem, doing test builds on ppc and amd64 first
[05:08] <fabbione> doko: ok
[05:08] <lamont> morning fabbione
[05:08] <fabbione> i would like to be able to give you some more info on the ICE (if still there) and that LINKING thing..
[05:08] <fabbione> perhaps it's an easy fix (the latter at least)
[05:19] <fabbione> YAY 
[05:19] <fabbione> GO GCC!!!!!
[05:20] <fabbione> doko: now it fails on the same package with a more interesting message
[05:20] <fabbione> the 2 could be easily related tho..
[05:22] <fabbione> doko: is 4.0.1 more paranoid than 4.0.0 ??
[05:22] <fabbione> first log:
[05:22] <fabbione> util.c: In function 'timestamp':
[05:22] <fabbione> util.c:29: warning: format '%06ld' expects type 'long int', but argument 4 has type '__suseconds_t'
[05:22] <fabbione> second log:
[05:22] <fabbione> util.c: In function 'timestamp':
[05:22] <fabbione> util.c:24: error: storage size of 'tz' isn't known
[05:22] <fabbione> util.c:29: warning: format '%06ld' expects type 'long int', but argument 4 has type '__suseconds_t'
[05:22] <fabbione> util.c:24: warning: unused variable 'tz'
[05:22] <fabbione> note that this is the same code
[05:22] <fabbione> only change is gcc
[05:24] <zul> meh..
[05:25] <fabbione> libc6-dev: /usr/include/time.h
[05:27] <fabbione> bah it's even an used var
[05:28] <fabbione>        The use of the timezone struct is obsolete; the  tz_dsttime  field  has  never
[05:29] <fabbione> I CAN BLAME GTK!
[05:31] <doko> fabbione: hmm, should that be %p instead?
[05:31] <fabbione> there it is... _BSD_SOURCE is not defined
[05:32] <fabbione> doko: no that's just a warning and i don't care
[05:32] <fabbione> the failure there is due to -D_BSD_SOURCE not being there
[05:32] <fabbione> = struct timezone has no size
[05:32] <fabbione> JEEEE
[05:33] <fabbione> doko: the point is that _BSD_SOURCE is not defined in the previous log
[05:33] <fabbione> and it was passing this point
[05:35] <fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.1/../../../../lib/crt1.o:../sysdeps/sparc/sparc32/elf/start.S:60: multiple definition of `_PROCEDURE_LINKAGE_TABLE_'
[05:35] <fabbione> no
[05:35] <fabbione> it's not fixed
[05:35] <fabbione> doko: what do you want me to check to get this fixed?
[05:36] <fabbione> let's move to #toolchain
[05:36] <doko> hmm, I don't know ...