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