[12:45] <lamont> anyone know which driver provides rtc on amd64?
[02:52] <zul> there...quickcam and spca5xx playing together like two peas in  a pod
[05:17] <zul> bleah...i cant sleep
[05:26] <fabbione> morning
[05:26] <zul> hey fabbione 
[05:29] <fabbione> zul: 7808 is d-i related. we still need todo thed-i cleanup in the kernel
[05:29] <fabbione> see debian/TODO
[05:29] <zul> updated?
[05:29] <fabbione> Verify debdiff with previous kernel and add new drivers to d-i.
[05:32] <zul> okie dokie printk stuff...what do you want to cut down?
[05:33] <fabbione> there are a couple of printk during the boot that are marked as _ERRO or _CRIT
[05:33] <fabbione> the audit thing
[05:34] <fabbione> and the swsup wrong partition id
[05:34] <zul> ok i can look into that
[05:34] <fabbione> they should be changed to _INFO
[05:34] <fabbione> we don't want to lose them
[05:34] <fabbione> just make them less noisy
[05:36] <zul> so the audit: <blah blah>
[05:38] <fabbione> yes
[05:38] <fabbione> and the swsups one
[05:39] <zul> okie dokie
[05:55] <zul> so something like this? http://zulinux.homelinux.net/kernel-power-swsusp_shutup.dpatch  
[05:57] <fabbione> except you diffed it the wrong way yes
[05:57] <fabbione> but not all of the messages
[05:57] <fabbione> only the one that shows at startup
[05:57] <zul> ok...then it might be time get some sleep then
[05:57] <zul> ok
[05:57] <fabbione> some of them are important to have
[05:59] <zul> ill see you guys tomorrow
[06:00] <fabbione> night zul
[06:00] <zul> i added some more external drivers from the list but ill put them in my baz archive when i get up tomorrow
[06:01] <zul> late
[06:01] <zul> later even
[06:04] <fabbione> ok
[06:59] <fabbione> lamont: ping me when you are around again
[07:00] <lamont> ack
[07:01] <fabbione> lamont: i was wondering if we can integrate sparc build logs on people
[07:01] <lamont> yeah - that's on my list of things to ponder.
[07:01] <lamont> specifically, now to integrate them.
[07:02] <fabbione> i guess you have somekind of script that scp them from the buildd's to people
[07:02] <fabbione> we might just adapt it
[07:02] <fabbione> you probably have to change the permissions on the tree so that i can write there
[07:03] <lamont> actually, the copy on rookery is a mirror of the master, that lives elsewhere
[07:03] <fabbione> ah
[07:03] <fabbione> hmmm
[07:03] <fabbione> that makes it more complicate
[07:33] <Lathiat> mmm the ipw2200 driver has gone from crashing requiring a module reload to crashing requiring a reboot :\
[07:33] <fabbione> Lathiat: complain with upstream
[07:33] <fabbione> it's the latest version of the driver
[07:34] <Lathiat> yeh i know was just saying
[07:34] <Lathiat> is it hard to debug kernel drivers?
[07:37] <fabbione> pretty much yes
[07:46] <fabbione> how much do we care about the abi in 2.6.11.9* serie?
[08:03] <fabbione> there.... rh cluster suite updated
[08:04] <fabbione> lamont: i am still checking out linux-ipv6
[08:04] <fabbione> unbelievable
[08:04] <fabbione> more than 24 hours co
[08:04] <Lathiat> ouch, which project is that from?
[08:04] <fabbione> linux-ipv6/usagi
[08:04] <lamont> fabbione: I don't think we care about the abi version until 2.6.12-1.1
[08:04] <fabbione> ipv6 statefull firewall
[08:04] <Lathiat> yeh usagi
[08:05] <fabbione> lamont: yeah
[08:05] <lamont> esp since if we did, we'd be something like 2.6.12-22.1
[08:05] <fabbione> lamont: exactly :)
[08:25] <fabbione> lamont: btw.. why the kernel did build 3 times on ppc buildds???
[08:26] <fabbione> at least... there are 3 logs reported
[08:27] <lamont> fabbione: most likely situation was those wonderful SIGILL's that ppc likes to throw on big builds
[08:27] <lamont> it's also possible that I gave it back in the middle of a build
[08:27] <fabbione> ah ok
[08:37] <fabbione> hey
[08:37] <fabbione> doko, svenl: can we take a look to PPC64 kernel?
[08:37] <fabbione> i need to understand a few things
[08:38] <fabbione> right now we have 6 ppc flavours
[08:38] <fabbione> power3{,-smp}
[08:38] <fabbione> power4{,-smp}
[08:38] <fabbione> powerpc{,-smp}
[08:39] <fabbione> which one of these need to become 64bit?
[08:39] <fabbione> or do we need to add a complete new set of flavours?
[08:40] <fabbione> for me all this ppc magic is kinda unknow
[08:40] <fabbione> and i need to understand what needs to be done
[08:41] <doko> hmm, don't know, if I can help ...
[08:41] <fabbione> doko: well you were asking for a ppc64 kernel
[08:42] <fabbione> so where can i build a ppc64 kernel in the first plave
[08:42] <fabbione> place
[08:43] <doko> davis, breezy-ppc64 chroot
[08:43] <fabbione> ok.. 
[08:44] <doko> using gcc-3.4 -m64
[08:45] <fabbione> ok we are already using gcc-3.4
[08:45] <fabbione> i think the -m64 is added by the kernel automatically when exporting ARCH=ppc64
[08:46] <fabbione> yes
[08:46] <fabbione> that is done automatically...
[08:46] <fabbione> so now.. i need to understand what flavours need to be built that way
[08:48] <fabbione> GCC_BROKEN_VEC  := $(shell if [ $(GCC_VERSION) -lt 0400 ]  ; then echo "y"; fi ;)
[08:48] <fabbione> interesting :)
[09:23] <svenl> fabbione: basically, the only thing you need to do is to add ARCH=ppc64 when building.
[09:24] <svenl> fabbione: i guess for symetry purpose, you would need to do :
[09:24] <fabbione> svenl: yes.. i know that, but i am more interested to know what flavours i need to build
[09:24] <svenl> ARCH=ppc for powerpc flavour, and ARCH=ppc64 for the ppc64 flavours.
[09:24] <svenl> well.
[09:24] <fabbione> yeah i get that :)
[09:24] <svenl> both power3 and power4 are now called pseries.
[09:24] <svenl> so i would have pseries and iseries.
[09:25] <svenl> that is : powerpc/ppc, pseries/ppc64, iseries/ppc64
[09:25] <fabbione> ok from the actual mapping:
[09:25] <svenl> but it is also possible to build a power4 and beyond optimized pseries version, so i would add a : 
[09:25] <fabbione> powerpc{,-smp} -> ARCH=ppc, no name change
[09:25] <svenl> pseries-power4/ppc64.
[09:25] <svenl> fabbione: ok.
[09:26] <fabbione> how do i map power3 and power4?
[09:26] <svenl> fabbione: for power3/power4, just add new versions.
[09:26] <fabbione> so something like:
[09:26] <fabbione> ppc64-power3
[09:26] <fabbione> ppc64-power6
[09:26] <fabbione> meh
[09:26] <fabbione> ppc64-power4 <-
[09:26] <fabbione> and of course build them with ARCH=ppc64
[09:27] <svenl> one moment.
[09:27] <fabbione> sure
[09:27] <svenl> fabbione: forget the old mappings.
[09:31] <svenl> Ok, am back.
[09:31] <fabbione> no rush....
[09:32] <svenl> fabbione: i don't have it in my mind right now, but basically, for all ppc/ppc32, the configs should be almost similar.
[09:32] <svenl> with a little modifications.
[09:32] <fabbione> svenl: right now i need only the name schema
[09:32] <svenl> fabbione: ok.
[09:32] <fabbione> forget about the contents of the configs
[09:32] <svenl> so, i would do :
[09:32] <svenl> ARCH=ppc -> powerpc{-smp}
[09:32] <svenl> ARCH=ppc64 -> pseries{-smp}
[09:32] <svenl> ARCH=ppc64 -> pseries-power4{-smp}
[09:33] <svenl> ARCH=ppc64 -> iseries{-smp}
[09:33] <fabbione> where is power3 in this schema?
[09:33] <svenl> as for the actual difference between the 3, iseries is the iseries variant, and pseries is the pseries one.
[09:33] <svenl> and pseries-power4 is the power4 optimized version of pseries.
[09:34] <svenl> fabbione: pseries now support both power3 and power4.
[09:34] <svenl> fabbione: but you can enable power4 and beyond only optimization, which bring a performance gain, but drop support of the power3.
[09:34] <svenl> This is pseries-power4.
[09:35] <fabbione> so what is the iseries?
[09:36] <fabbione> i am sorry if these questions are lame
[09:36] <fabbione> but i am trying to understand the best i can
[09:36] <infinity> AS/400.  I didn't think they were shipping with different CPUs than the pseries, just different gear under the hood...
[09:40] <svenl> fabbione: iseries are IBM/power big iron, not previous supported by the ppc32 kernels.
[09:41] <fabbione> oh
[09:41] <fabbione> so that means generating heaps load of images
[09:41] <svenl> fabbione: not really.
[09:41] <fabbione> of the old power3/power4 images.. is there something we can actually drop safely?
[09:41] <infinity> For the installer, we should be able to cut back to two images.
[09:41] <infinity> A very generic ppc32 and a very generic ppc64.
[09:41] <svenl> it will only be 8 images compared to 6 previously.
[09:42] <svenl> fabbione: we can indeed only keep powerpc and pseries for the installer.
[09:42] <infinity> Unless the ppc64 generic images wont boot on AS/400 kit for some reason, and that would be silly.
[09:42] <svenl> or maybe powerpc and pseries-smp
[09:42] <fabbione> ok
[09:42] <svenl> fabbione: i would build iseries as netboot only.
[09:42] <fabbione> let me try to summarize
[09:42] <fabbione> svenl: netboot will still require an image
[09:42] <svenl> but this means enabling the mkvmlinuz build.
[09:43] <fabbione> powerpc stays as it is
[09:43] <svenl> fabbione: sure, but you don't need to put it on the CD.
[09:43] <fabbione> power4{,-smp} -> pseries-power4
[09:43] <fabbione> power3 -> vanish
[09:43] <svenl> mmm, come to think of it, mkvmlinuz needs fixing for ppc64.
[09:43] <svenl> fabbione: nope.
[09:43] <fabbione> we introduce iseries and pseries
[09:43] <svenl> power[34] {-smp} -> pseries{-smp}
[09:44] <fabbione> ok
[09:44] <fabbione> roger that
[09:44] <svenl> pseries-power4{-smp} is an optimized version of the pseries for power4 and beyond.
[09:44] <fabbione> how big is the performance gain?
[09:44] <svenl> like you have normal -386 and -k7 and such.
[09:44] <svenl> fabbione: not sure.
[09:44] <svenl> fabbione: 20-40 % maybe ? 
[09:44] <infinity> I'd question that 40.. :)
[09:45] <infinity> 20 would be generous.
[09:45] <svenl> need to ask the IBM guys.
[09:45] <svenl> infinity: i don't know.
[09:45] <fabbione> i think no more than 5%
[09:45] <svenl> but it is an important gain.
[09:45] <svenl> fabbione: how much would be the gain from -i386 to -k7 ? 
[09:45] <infinity> It's a measurable gain, but it's not massive.
[09:45] <svenl> anyway.
[09:45] <fabbione> svenl: minimal :)
[09:45] <infinity> Especially not from the point of view of userspace.
[09:46] <svenl> infinity: the ppc64 guys told me : please don't cripple the ppc64 kernels.
[09:46] <svenl> but well.
[09:46] <svenl> fabbione: if you want to gain space, you can drop the non-smp power3 variant.
[09:46] <infinity> Can't we pull tricks to optimise for power4, without using new ops?
[09:46] <fabbione> why that?
[09:46] <infinity> (This can be done in intel systems, slowing down older CPUs, but allowing them to still work)
[09:47] <infinity> Also, I question the value of any non-smp kernels, but that's something we still need to test more, I suppose.
[09:47] <svenl> power3 boxes are few indeed, and the majority of those are smp variants, and the smp kernel should work on up.
[09:47] <svenl> so i would do :
[09:47] <svenl> powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries
[09:47] <svenl> (i guess it makes no sense to have non-smp iseries :)
[09:48] <fabbione> so it would be:
[09:48] <svenl> which leaves us at exact the same amount of kernels as today.
[09:48] <fabbione> powerpc, powerpc-smp, pseries-smp, pseries-power4, pseries-power4-smp, iseries-smp
[09:48] <fabbione> just to keep the name schema coherent
[09:48] <svenl> fabbione: yep.
[09:48] <infinity> There are single CPU iseries machines, but the only people who use them are hackers writing software for the big iron, generally.
[09:49] <svenl> infinity: so they can live with the 5% or whatever performance drop, or use their own stuff.
[09:49] <fabbione> hackers don't use precompiled kernels
[09:50] <svenl> infinity: do you know what those iseries machine use for booting ? 
[09:50] <infinity> Not sure.  I've only seen one, and it was running AIX.
[09:50] <infinity> AndErm, OS/400.
[09:50] <infinity> Brain fart.
[09:51] <infinity> But, yeah.  I didn't ever hit the little white switch to reboot it.
[09:51] <infinity> It was happy on its own.
[09:51] <svenl> infinity: do you think yaboot will work on them ? 
[09:51] <infinity> It's possible.  I'd like to get my hands on one for testing.
[09:51] <svenl> And those are the ones which don't do funny partitioned computing stuff.
[09:52] <infinity> A single CPUU iSeries can still run VM, but I'm not sure why one would want to. :)
[09:52] <infinity> (It's a possible use case, though)
[09:52] <infinity> But unless we have some people at IBM who want to help out, this is all "I played with one a couple of years ago" experience.
[09:57] <svenl> i will investigate about this.
[10:01] <svenl> fabbione: will you build an 2.6.12-rc4 kernel packages ? Or still go with 2.6.11 ? 
[10:01] <svenl> 09:58 < mpee_> svenl, a non SMP kernel won't boot on iSeries so don't bother
[10:02] <infinity> Oh, they actually market single CPU iSeries stuff to end-users now.
[10:02] <infinity> And yes, they're running VM by default.
[10:02] <fabbione> svenl: 2.6.12rc4
[10:02] <svenl> so i guess that solves it. I would drop the -smp name of it though.
[10:02] <svenl> fabbione: cool.
[10:02] <fabbione> i am not spending time on .11
[10:02] <infinity> (Which allows them to ship them with Linux and OS/400 installed, in two seperate partitions)
[10:02] <svenl> do you have something i can try on my powerbook already ? benh said that 2.6.12-rc4 will solve all power management and sleep issues.
[10:02] <infinity> Which would also explain why the non-smp kernels won't work, cause I think all the VM magic is tied to SMP.
[10:02] <fabbione> svenl: not for ppc64
[10:03] <fabbione> svenl: the 32 bit images are in the archive already
[10:03] <fabbione> universe -> linux-source-2.6.12/
[10:03] <svenl> 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image
[10:04] <svenl> fabbione: no prebuilt kernel though.
[10:04] <svenl> fabbione: you think my powerbook G4 will like ppc64 kernels ? 
[10:04] <fabbione> yes.. they are in that dir
[10:04] <fabbione> svenl: no idea.. i am not a ppc guy :)
[10:04] <fabbione> that's why i keep asking ppc stuff around
[10:04] <svenl> fabbione: :)
[10:05] <fabbione> svenl: what does benh mean?
[10:05] <svenl> fabbione: the G4 is ppc32.
[10:05] <svenl> 10:01 < benh> svenl: drop UP kernels on ppc64
[10:05] <svenl> 10:01 < svenl> benh: :)
[10:05] <svenl> 10:01 < benh> svenl: I don't think they make any sense
[10:05] <svenl> 10:01 < benh> svenl: iseries ... oh well, yes, they still need a specific kernel
[10:05] <svenl> 10:01 < benh> svenl: pmac/pseries/everybody else can be a single image
[10:05] <svenl> 10:01 < benh> svenl: I'm not sure about the performance impact of doing the CONFIG_POWER4 option there
[10:05] <svenl> 10:01 < svenl> benh: even on pseries-power4 ? There are a bunch of single CPU G5 pmac about, don't they would lose in
[10:05] <svenl>                performance.
[10:05] <svenl> 10:02 < svenl> benh: do you know who might know ?
[10:05] <svenl> 10:02 < benh> svenl: maybe they would ...
[10:05] <svenl> 10:02 < benh> dunno
[10:05] <svenl> 10:03 < svenl> ok, so i guess we should keep them in the first run, and then drop them after a bit of experimentation.
[10:05] <svenl> fabbione: basically, he is advocating having only 2 ppc64 kernels, pseries and iseries, both of the smp variant.
[10:06] <fabbione> ok
[10:06] <fabbione> and one ppc32 kernel
[10:06] <svenl> but 1) no idea what the performance drop will be for single cpu powermac G5s.
[10:06] <svenl> and 2) no idea if the power4 optimization is worth it.
[10:06] <fabbione> ok we can start with the minimum
[10:06] <fabbione> and see if people will request other kernels
[10:06] <infinity> Shame about iseries needing its own kernel.
[10:07] <fabbione> so we will still have 6 kernels :(
[10:07] <svenl> fabbione: i would do :
[10:07] <fabbione> no.. actually less
[10:07] <infinity> 3?
[10:07] <svenl> 32bit : powerpc, powerpc-smp
[10:07] <fabbione> powepc{,-smp}
[10:07] <infinity> Oh.
[10:07] <fabbione> pseries-smp
[10:07] <svenl> 64bit : pseries, iseries
[10:07] <fabbione> iseries-smp
[10:08] <svenl> optional 64bit optimized kernels : 
[10:08] <svenl> pseries-power4
[10:08] <svenl> pseries-power4-up
[10:08] <infinity> I'd scrap those two, but whatever.
[10:08] <fabbione> me too
[10:08] <fabbione> we need to reduce the amount of images
[10:08] <svenl> so, we keep 4 and put them on CD, and build the two others, and keep them on the net.
[10:08] <svenl> fabbione: well.
[10:09] <svenl> fabbione: i would like them to be present in the first round, so we can do performance tests, and then decide.
[10:09] <svenl> fabbione: but as said, you don't need to put them on the CDs.
[10:09] <fabbione> svenl: i prefer the other way around :)
[10:09] <infinity> Has anyone done recent tests to see how much it hurts to run smp on up?
[10:09] <svenl> fabbione: not build them, and then make performance tests ? 
[10:09] <svenl> infinity: i think not.
[10:09] <svenl> fabbione: maybe we could inverse the situation : 
[10:09] <infinity> powerpc-smp should be the only powerpc kernel, if we can help it.
[10:10] <svenl> powerpc, powerpc-up, pseries, iseries.
[10:10] <infinity> (And I'm saying this as  aman who owns a ppc32 up machine)
[10:10] <svenl> We can then drop to 3 : powerpc, pseries, iseries.
[10:10] <fabbione> svenl: no that would be confusing to death
[10:10] <svenl> and then 3 set of optimized kernels : powerpc-up, pseries-power4 and pseries-power4-up.
[10:10] <svenl> fabbione: why ? 
[10:11] <fabbione> because the actual schema is -smp
[10:11] <fabbione> change it to -up and users will get confused
[10:12] <svenl> fabbione: so what ? 
[10:12] <svenl> fabbione: users should not know about this.
[10:12] <svenl> fabbione: have the powerpc/pseries/iseries provide the -smp version and everyone will be happy.
[10:12] <fabbione> svenl: they do and they ask questions about stuff like that
[10:13] <svenl> fabbione: so what ? That is what the long description is all about.
[10:13] <fabbione> + it breaks coherency with the other arches
[10:13] <svenl> fabbione: so what ? 
[10:13] <svenl> fabbione: if we are gonna default to smp versions, let's make it logical. The users will thank you in the long run.
[10:13] <fabbione> svenl: i want to be able to keep things coherent even across arches
[10:14] <svenl> infinity: BTW, how do you make up vs smp kernel performance tests ? I could do those on my powerbook.
[10:15] <infinity> svenl : <shrug>... Pick a benchmark you like, compile two kernels, identical except for CONFIG_SMP, see how it performs?
[10:15] <infinity> svenl : Benchmarking isn't an exact science, since everyone will want to test different things.  Just pick something that should give reasonably consistent numbers.
[10:16] <infinity> I should do this on my amd64 machine when I get it back up, too.
[10:16] <svenl> infinity: ok, my question would be of the kind : what kind of benchmark stress the kernel and not userland ? 
[10:17] <infinity> svenl : SOmething that shoves a lot of RAM around for no good reason?.. Filesystem tests... Make something up? :)
[10:17] <infinity> svenl : The real answer is "who cares?.. It's userland performance people see"
[10:17] <svenl> infinity: ok, i will look around.
[10:17] <svenl> infinity: :)
[10:17] <infinity> If a different kernel doesn't appear to affect userland by more than 5%, I say it's "good enough"
[10:17] <fabbione> svenl: can a pseriers kernel boot on g5?
[10:18] <infinity> Yes.
[10:18] <infinity> Same CPU.
[10:18] <fabbione> infinity: Xu said that the main issue with SMP on UP is the locking mechanism at net layer
[10:18] <infinity> Well, sort of.
[10:18] <fabbione> but that's due to:
[10:18] <svenl> fabbione: sure.
[10:18] <fabbione> a) crappy code
[10:18] <fabbione> b) very very high load on cpu and net (~1GB)
[10:18] <fabbione> so it is for sure NOT the common case
[10:18] <svenl> fabbione: notice that the power3 sym53c8xx driver did lock in up mode, and worked fine in smp mode on a dual power3 machine.
[10:19] <infinity> Which brings us to: Thee are shitty Mac-specific drivers for older macs (like my Beige G3) that may suck on SMP, because that hardware just doesn't get used with more than one CPU.
[10:20] <infinity> But it's not hard to put out a call for testers for that sort of thing.
[10:20] <infinity> Most of those driver bugs would surface immediately as oopses or panics, nothing subtle.
[10:21] <svenl> infinity: you default to smp early in the release cycle, and wait for bug reports :)
[10:22] <infinity> People doing constant updates of breezy don't think to upgrade kernels.
[10:22] <infinity> You call for testers, or risk the wrath of a broken installer at release time. :)
[10:24] <svenl> 10:21 < olaf> svenl: running 64bit smp vs. 32bit up on single cpu systems cost 2%
[10:27] <infinity> fabbione : Any objections to dropping the product names (powerpc, pseries) completely from the generic kernels, and just naming them like the hppa kernels?
[10:27] <svenl> 10:23 < olaf> I did not benchmark that. but noone cares. large enterprise thingies run with power4=n and they dont care
[10:27] <fabbione> nope
[10:27] <infinity> (2.6.12-32{,-smp}, 2.6.12-64{,-smp})
[10:27] <svenl> 10:24 < olaf> I did that 64bit smp vs 32bit up on a G5
[10:27] <infinity> Then for the iseries flavour, you'd have 2.6.12-64-iseries
[10:27] <infinity> Still pretty clear.
[10:27] <fabbione> it is just important for me to keep -smp in
[10:28] <fabbione> to be coherent with the other arches
[10:28] <infinity> Right.  Well, I always found the hppa kernels to be nice and intuitive.. And clean.
[10:28] <infinity> It was obvious what kernel I actually wanted. :)
[10:28] <fabbione> exactly
[10:28] <infinity> And Kamion's point about "who would install a kernel called 'pseries' ona G5 Mac?" is a good one.
[10:29] <fabbione> yup
[10:29] <fabbione> chmj, thom: you around?
[10:29] <infinity> Mac users aren't known for being able to extend their thought processes terribly far.
[10:29] <thom> yep
[10:29] <fabbione> chmj, thom: please start to get familiar with git/cogito
[10:29] <chmj> yep 
[10:29] <fabbione> there are deb packages around announced on debian-devel mailing list
[10:29] <fabbione> or install it from http://www.kernel.org/git/
[10:30] <fabbione> checkout the relevant trees
[10:30] <fabbione> linux/kernel/git/torvalds/linux-2.6.git linux/kernel/git/gregkh/stable-queue.git linux/kernel/git/gregkh/linux-2.6.11.y.git 
[10:30] <fabbione> we have some crack to deal with
[10:31] <fabbione> get used on how to grab a single patch out of the tree
[10:31] <fabbione> it's pretty simple
[10:31] <infinity> fabbione : Oh, BTW, I sign a lease tomorrow and move my amd64 somewhere where I can actually plug it in, so I will become more useful at that point.
[10:31] <fabbione> you use a combination of cg-log and cg-mkpatch
[10:31] <fabbione> infinity: rocking :)
[10:32] <svenl> fabbione: i disagree with the -smp part of it.
[10:33] <svenl> fabbione: you will only get questions from people asking where the -up version went.
[10:33] <svenl> fabbione: did you see the info from olaf ? 
[10:33] <svenl> fabbione: i would guess just keeping the smp version of powerpc, pseries, iseries would do it.
[10:33] <svenl> as -32, -64 and -64-iseries.
[10:34] <svenl> infinity: you could even do -32 -64 -iseries, as i guess anyone with an iserie machine will know he needs a 64 bit kernel.
[10:34] <fabbione> svenl: yes i saw the msgs from olaf
[10:36] <svenl> fabbione: so we are down to 3 (4 if we keep the up 32bit kernels) and add one full subarch.
[10:36] <svenl> infinity: the only problem with your naming scheme would be if you where to support stuff like apus or nubus, which are not yet integrated in the main kernel, as debian will do.
[10:37] <svenl> but then you could have -32, -64, -iseries, -nubus, -apus.
[10:37] <svenl> Would also work fine.
[10:48] <fabbione> the only thing i need basically is to be able to recognize a 64bit kernel from a 32bit one from the name, without hardencoding anything in debian/rules
[10:48] <fabbione> so something like -64- or ppc64 has to be there
[10:48] <fabbione> for the sake of simplicity
[10:48] <fabbione> so that given a regexp match i can set the proper arch
[10:49] <svenl> fabbione: just have a flavour file, which gives you the right arch for a given flavour, and parse it from debian/rules.
[10:49] <svenl> fabbione: see how i do it in the 2.4.27 debian powerpc package.
[10:52] <fabbione> there is no kernel-image-2.4.7-ppc
[10:52] <fabbione> 27 even
[10:52] <svenl> kernel-patch-powerpc-2.4.27
[10:53] <svenl> fabbione: well, it is overkill for your needs, but the basic format is : 
[10:53] <svenl> arch: <list of archs>
[10:53] <svenl> subarch <arch>: <list of subarches for that arch>
[10:54] <svenl> flavour <subarch>: <list of flavours for that subarch>
[10:54] <fabbione> yeah i see
[10:54] <svenl> so you could either have two subarches, ppc and ppc64, and a couple of flavours for each.
[10:54] <svenl> or have only subarch, and use a field to get it.
[10:55] <svenl> something like subarch-arch <subarch> : ppc64
[10:55] <svenl> i extract them by grep/sed, which may not be the more astute way of doing it.
[10:55] <svenl> but i believe it is better to have a explicit list, than to try to do some implicit detection like you plan to do.
[10:56] <svenl> and you could even have : 
[10:56] <svenl> arch : powerpc
[10:56] <svenl> subarch powerpc : apus nubus ppc32 ppc64
[10:56] <svenl> flavour ppc32 : 32 32-smp
[10:56] <svenl> flavour ppc64 : 64 iseries
[10:56] <svenl> or whatever.
[10:57] <fabbione> i don't need that kind of complexity
[10:57] <svenl> fabbione: bah.
[10:57] <fabbione> flavour[iseries] =ppc64
[10:57] <svenl> fabbione: remember, we spoke of unifying the kernel package with debian, and debian will most decidedly need it.
[10:57] <fabbione> that's all i need
[10:57] <svenl> for now.
[10:58] <fabbione> yes but i still don't need to make things more complex that they need to be
[10:58] <svenl> how do you think that debian will handle something like the subarch specific patches mips has ? 
[11:00] <fabbione> svenl: the same way as i do? checking for a per arch patchlist to apply?
[11:00] <fabbione> per arch and per flavour
[11:00] <fabbione> because that it is easy to implement
[11:00] <fabbione> what we need to address now is:
[11:00] <fabbione> given flavour foo, what arch is that?
[11:01] <fabbione> for our case:
[11:01] <fabbione> arch[iseries-smp]  = powerpc64
[11:01] <fabbione> source that array
[11:01] <fabbione> and you are done with an export
[11:01] <fabbione> clearly the array can be built in a clever way
[11:01] <fabbione> to handle more things
[11:02] <svenl> ok.
[11:02] <svenl> so you loose the subarch/flavour distinction, and have only two levels ?
[11:03] <svenl> you could build multiple flavours for a given subarch specific patch. And notice that i didn't mention a arch-specific patch, but an subarch specific one.
[11:04] <fabbione> svenl: i think we are using 2 different meanings for subarch/flavour
[11:04] <fabbione> because for me flavours are 386 686 k7
[11:04] <fabbione> or power3 power4 powerpc
[11:04] <fabbione> what are flavours for you?
[11:05] <fabbione> and what is subarch for you?
[11:05] <fabbione> (just that we can talk at the same level of terms)
[11:05] <infinity> Flavours are turning features on or off ina subarch.
[11:05] <infinity> Like, -xfs kernels in the good ol' days.
[11:06] <svenl> fabbione: i have a concept where there are three levels.
[11:06] <svenl> fabbione: there is the arch, and we all know what those are.
[11:06] <fabbione> yeah
[11:06] <svenl> fabbione: then there are the subarches, which i myself define as those who need incompatible patch sets.
[11:07] <svenl> fabbione: example of those on powerpc (2.4) are nubus, apus and main powerpc.
[11:07] <fabbione> make an example
[11:07] <fabbione> ok
[11:07] <svenl> fabbione: this is a prerequisite for misp i hear from ths.
[11:08] <svenl> fabbione: the subarches generate the main kernel-header package (may dissapear though in favour of a flavour one), and the subarch specific kernel-patch package.
[11:08] <svenl> fabbione: then flavours are individual config options inside an arch/subarch.
[11:08] <svenl> the subarch level could be dropped, as happens on x86.
[11:08] <svenl> altough you may consider that 64bit and 32bit are two subarches of the x86 arch.
[11:09] <fabbione> ok we are on the same level now...
[11:09] <fabbione> i think
[11:10] <fabbione> there are several things that need to be addressed
[11:10] <fabbione> clearly an array can do
[11:10] <svenl> yep.
[11:10] <fabbione> given that you build images from what you have in config/
[11:10] <fabbione> each of these config files have a unique name
[11:10] <svenl> you could simply have a subdir in config.
[11:11] <fabbione> and they can identify all the info you need
[11:11] <fabbione> there is no need
[11:11] <fabbione> that's what i mean
[11:11] <svenl> how is the ubuntu config layout ? 
[11:11] <svenl> a single level ? 
[11:11] <svenl> or a per arch sublevel ? 
[11:12] <fabbione> debian/config/$arch/$configfile
[11:12] <fabbione> per arch
[11:12] <fabbione> but config names are unique
[11:12] <fabbione> so there is no need for us to stick the $arch in the array
[11:12] <svenl> ok.
[11:12] <fabbione> and that somehow eliminates one level of complexity
[11:13] <svenl> how do you handle debian/config/powerpc/32 and debian/config/x86/32 or whatever ?
[11:13] <fabbione> now.. to apply my array to your view
[11:13] <fabbione> there is no name duplication
[11:13] <fabbione> you cannot find 32 in x86 AND ppc
[11:13] <fabbione> for your example
[11:13] <svenl> fabbione: this will break infinity's naming proposal.
[11:14] <fabbione> svenl: right.. but Kamion already killed it anyway :)
[11:14] <svenl> fabbione: huh, i did miss that.
[11:14] <fabbione> it was on u-d
[11:14] <fabbione> anyway
[11:14] <fabbione> the point is
[11:14] <fabbione> once you can get a unique name for each config file
[11:15] <svenl> ok.
[11:15] <fabbione> the array can carry all the info you need
[11:15] <fabbione> that can be ARCH=ppc64
[11:15] <fabbione> or patch list to apply
[11:15] <fabbione> or whatever
[11:15] <fabbione> it doesn't matter because the name is unique
[11:15] <fabbione> so arch[pseries-smp] =ppc64
[11:15] <fabbione> will tell me everything i need
[11:15] <fabbione> or
[11:16] <fabbione> patchlist[foo] =00list-1.2.21.foo.bar
[11:16] <fabbione> or whatever
[11:16] <fabbione> but you get the idea
[11:19] <svenl> indeed.
[11:19] <svenl> so we are back to powerpc, pseries, iseries ? 
[11:27] <fabbione> infinity: what did you agree with Kamion?
[11:32] <svenl> fabbione: but i would drop the -smp bit.
[11:34] <svenl> :)
[11:35] <JaneW> fabbione: no new kernels yet?
[11:35] <fabbione> JaneW: nope.. working on them
[11:36] <chmj> JaneW, I surppose you have a name already 
[11:36] <JaneW> fabbione: can I take the 'affects kernel' column out of the Breezy Goals wiki page, mdz feels it doe not have enough general interest or relevance...
[11:36] <JaneW> chmj: of course ;)
[11:36] <fabbione> JaneW: well the point is that a bunch of bofs ended with "we need this in the kernel"
[11:37] <fabbione> if the people that will implement stuff are going to tell me in a decent time, i am ok with removal
[11:37] <fabbione> otherwise i would rather have all of them to update that field
[11:41] <JaneW> fabbione: ok lets leave it for now, once the field is filled will you save to a speadsheet? Then we can remove, allowing us space for more info.
[11:41] <fabbione> works for me
[11:46] <thom> go cogito; it's your birthday
[11:46] <thom> aka, ftbfs on amd64
[11:50] <fabbione> fix it :)
[11:50] <fabbione> i think i had to build it with gcc-3.3
[11:50] <fabbione> i can't remember tbh
[11:50] <thom> ah, just scary signedness warnings; error was just masked a bit
[11:51] <thom> built ok with gcc 4.0 in the end
[11:51] <fabbione> eheh
[11:52] <thom> (and i just uploaded to breezy ;-) )
[11:52] <fabbione> nice
[12:00] <thom> oh. should i be merging skge onto kernel-debian--pre1,2--2.6.11.92 or kernel-debian--mainline-2,6,11,92-1,1--0 ?
[12:03] <fabbione> pre1,2
[12:03] <fabbione> mainline are basically tags
[12:04] <thom> okidoke
[12:17] <thom> fabbione: ok, committed
[12:17] <fabbione> cool
[12:22] <pitti> Hey
[12:23] <fabbione> i am here, but i am eating
[12:23] <fabbione> so slow answers
[12:24] <pitti> fabbione: enjoy your meal
[12:39] <thom> fabbione: hrm?
[12:41] <thom> oh, you want - add externel-driver-net-skge.dpatch ?
[12:42] <fabbione> thom: don't worry.. i am changing the bits to my standard
[12:43] <fabbione> so you can see them without getting crazy
[12:43] <fabbione> from where did you download the driver?
[12:44] <thom> http://developer.osdl.org/shemminger/skge/
[12:44] <fabbione> oh you didn't get the one from sysconnect?
[12:44] <fabbione> that's why it was so small
[12:44] <fabbione> and probably buggy
[12:45] <thom> eh?
[12:45] <thom> skge != sk98lin update
[12:45] <fabbione> yes
[12:45] <fabbione> but there is the driver done by sysconnect
[12:45] <fabbione> that is the one supposed to work :)
[12:45] <thom> yes, that's sk98lin
[12:45] <fabbione> oh ok
[12:45] <fabbione> i tought you wanted to update sk98lin
[12:45] <thom> it's big, bloaty and nasty
[12:47] <thom> if it's really broken we can back it out and run away later, but let's see :-)
[12:47] <thom> i think stephen runs ubuntu anyway :-)
[12:47] <fabbione> arch_commit: unable to acquire revision lock (internal error in archive-pfs.c(pfs_lock_revision))
[12:47] <fabbione> WTF IS WRONG NOW
[12:48] <pitti> mind the last words of the petunia bowl
[12:48] <fabbione> thom are you in the middle of a commit?
[12:49] <thom> nope
[12:49] <fabbione> hmm i think i know
[12:50] <fabbione> thom: what is your umask on roockery?
[12:50] <pitti> ah, that one :-/
[12:51] <thom> default, blah
[12:51] <thom> fixed
[12:51] <fabbione>    4 -r--r--r--    1 thom     warthogs      125 May 12 11:16 .listing
[12:51] <thom> (and i've fixed the rev lock, too)
[12:51] <thom> fixed that, too
[12:51] <fabbione> no it's will 444
[12:51] <fabbione> fabbione@rookery:/home/lamont/public_html/Archives/kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92/patch-9$ 
[12:51] <thom> -rw-rw-r--    1 thom     warthogs       89 May 12 11:16 .listing
[12:52] <fabbione> it still shows as 444 here!
[12:52] <thom> the .listing in the patch dir doesn't matter
[12:52] <thom> they're all 444
[12:52] <fabbione> oh right
[12:52] <thom> anyway, i've fixed the revlock, which is the pertinent point
[12:53] <thom> the directory .listing one i've fixed
[12:53] <fabbione> sftp status: Permission denied
[12:53] <fabbione> and now all the archive is fucked
[12:53] <fabbione> FUCK
[12:55] <thom> status on which dir?
[12:55] <thom> tree, rather?
[12:56] <fabbione> pre1,2 patch-9
[12:56] <fabbione> it started moving shit around during the commit
[12:57] <fabbione> than i got the sftp error
[12:57] <fabbione> BUM
[12:57] <fabbione> so now we have a patch-9 without revision lock
[12:58] <pitti> you can create one manually
[12:59] <pitti> baz lock-revision <lastrevision> doesn't work?
[12:59] <thom> baz lock-revision  kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92--patch-9
[12:59] <thom> lock-revision: error locking revision kernel-team@ubuntu.com--2005/kernel-team@ubuntu.com--2005/kernel-debian--pre1,2--2.6.11.92--patch-10 -- internal error in archive-pfs.c(pfs_lock_revision)
[01:00] <pitti> thom: is there a ++revision-lock-held-by-crack in the base directory (that with all the patch-* dirs)?
[01:00] <fabbione> hold on guys
[01:01] <fabbione> ok fixed
[01:02] <thom> what did you do?
[01:02] <fabbione> well i removed the bad lock
[01:02] <fabbione> and inside the patch dir
[01:02] <fabbione> mkdir -p ++revision-lock/+contents
[01:02] <fabbione> i missed +contents at the first attempt
[01:02] <thom> arh
[01:03] <fabbione> arch is insane
[01:03] <thom> yes
[01:03] <pitti> baz should just get "baz unfuck-archive"
[01:03] <thom> i've fixed my umask
[01:03] <Lathiat> heh
[01:03] <fabbione> baz commit -s'DIE YOU MOTHERFUCKER!'
[01:03] <fabbione> it did work...
[01:03] <fabbione> thom: you can merge from it now
[01:03] <fabbione> there are basically 3 changes
[01:03] <fabbione> a more detailes log
[01:04] <fabbione> an entry in debian/external-drivers to keep track of what we add from wheree
[01:04] <fabbione> and the patch naming is like:
.dpatch in your case
[01:04] <fabbione> horms:
.dpatch
[01:05] <fabbione> meh
[01:05] <fabbione> s/horms:/or
[01:05] <fabbione> ok now.. let's talk about more serious stuff
[01:06] <fabbione> pitti is here because we have a bunch of public security issues to deal with
[01:06] <fabbione> elmo is going tomorrow to the DC to play rebootorama
[01:06] <fabbione> so we should try to give him at least a set of patches
[01:07] <fabbione> and start working on both warty and hoary kernels
[01:07] <fabbione> chmj: what is your email?
[01:07] <chmj> charles@ubuntu.com 
[01:07] <chmj> @canonical.com 
[01:07] <chmj> @rootcore.co.za
[01:07] <fabbione> one is enough
[01:08] <chmj> preference order 
[01:08] <chmj> :-)
[01:09] <fabbione> you both got mail :)
[01:09] <fabbione> pitti: not you..
[01:09] <fabbione> i did forward your mail :)
[01:09] <mvirkkil> What kernel has the holliwood+/dxr3 module?
[01:10] <fabbione> mvirkkil: 2.6.12 version 2.6.11.92-1,1
[01:10] <mvirkkil> fabbione: thanks
[01:10] <fabbione> np
[01:11] <fabbione> so the first thing is to collect all the patches from the differnt trees
[01:11] <fabbione> chmj: did you install git?
[01:11] <fabbione> or cogito?
[01:12] <chmj> cogito 
[01:12] <fabbione> ok
[01:13] <fabbione> chmj: the few patches that are missing, are in the gregkh tree
[01:13] <fabbione> stable-queue.git
[01:13] <fabbione> please start collecting them
[01:14] <chmj> ok 
[01:14] <fabbione> thom: do you want to start looking at warty and i will start looking at hoary?
[01:14] <fabbione> with the patches that we already have
[01:14] <thom> ok
[01:14] <fabbione> pitti: mind to confirm with elmo what version of the kernel he needs?
[01:14] <pitti> sure
[01:14] <fabbione> if we can skip one distro for such a short time, it will be better
[01:15] <fabbione> thom: warty is not in baz..
[01:15] <fabbione> so it's freestyle :-)
[01:15] <thom> yeah, i guessed
[01:15] <fabbione> ehhe
[01:15] <thom> fun fun
[01:21] <pitti> fabbione: hoary kernel is priority for elmo, he does not have warty any mroe
[01:21] <pitti> more, even
[01:22] <fabbione> ok
[01:22] <fabbione> perfect
[01:23] <fabbione> baz is still munging on the tree....
[01:24] <fabbione> i have the feeling that the first vulnerability will change the ABI
[01:31] <zul> which group?
[01:31] <zul> hey btw
[01:31] <fabbione> metallica :)
[01:31] <zul> old or new...
[01:31] <fabbione> marylin manson is for the build orgy
[01:31] <fabbione> St. Anger
[01:31] <fabbione> new
[01:32] <fabbione> but old-style
[01:32] <zul> meh...i like old..
[01:32] <fabbione> i like old too
[01:35] <zul> ok you can merge from me if you want
[01:36] <fabbione> zul: later or tomorrow.. we need to do some security today :)
[01:36] <zul> cool...
[01:36] <fabbione> zul: did you already merge from me?=
[01:37] <zul> i just did
[01:37] <fabbione> ok
[01:37] <zul> now i have conflicts :(
[01:38] <fabbione> no! really?
[01:38] <fabbione> :)
[01:38] <zul> bitch
[01:40] <fabbione> pitti: do you confirm that i only have one missing CAN from hoary changelog?
[01:41] <pitti> CAN-2005-0977, yes
[01:41] <fabbione> ok
[01:42] <fabbione> added..
[01:48] <pitti> fabbione: btw, are the git patches web-published somewhere? so that one can refer to them with an URL?
[01:48] <fabbione> pitti: did you see the mail from XU?
[01:48] <fabbione> pitti: yes.. kernel.org/git/
[01:48] <pitti> cool
[01:48] <pitti> no, I didn't
[01:48] <fabbione> it just arrived here
[01:50] <pitti> fabbione: ah, I saw
[01:50] <pitti> well, do you want to do the warty kernels now?
[01:51] <fabbione> pitti: i am not sure what is the situation with Xu
[01:51] <fabbione> pitti: i had say to wait for mdz
[01:51] <pitti> fabbione: me neither, mdz couldn't speak to him, and me neither
[01:51] <fabbione> thom is already looking at it
[01:51] <fabbione> i did speak with Xu, for 40 minutes
[01:51] <fabbione> than he vanished in thin air
[01:52] <thom> so i should continue, or is xu doing it?
[01:52] <fabbione> thom: please keep doing it
[01:55] <thom> i take it there's no way to check abi for warty kernels?
[01:55] <fabbione> thom: not easily
[01:56] <fabbione> but since we are going to apply the same patchsets, i am confident that if it doesn't break for me, it won't for you
[01:56] <thom> ok
[01:56] <fabbione> otherwise see how it is done in hoary
[01:56] <thom> i'll just blame you for everything; it'll be great
[01:56] <fabbione> you will need to rebuild the warty kernel to get the current ABI file
[01:56] <fabbione> and build the new one to compare
[01:56] <thom> right
[02:04] <thom> building the abi stuff now
[02:05] <fabbione> tsk.. you have an amd64!
[02:05] <fabbione> chmj: how is it going to find the patches?
[02:06] <thom> fabbione: the kernel still takes ages :P
[02:06] <fabbione> thom: not on concordia dude...
[02:06] <thom> heh
[02:07] <thom> concordia is a slightly different beast to my poor amd64 3000+
[02:07] <Mithrandir> we're getting some 275s for hardware.no now.  That'll be nice.
[02:07] <fabbione> we will need to test build on ppc/i386
[02:07] <fabbione> oh poor..
[02:07] <Mithrandir> (dualcore 250s)
[02:07] <thom> fabbione: sure; but for the purposes of this i can test quite happily on just amd64
[02:07] <thom> Mithrandir: shurrup
[02:07] <Mithrandir> :)
[02:07] <fabbione> Mithrandir: send a few in this direction :)
[02:08] <thom> Mithrandir: seems they're not gonna be released to the public till Q4 :/
[02:08] <Mithrandir> fabbione: we're talking directly with AMD to get them, since they're totally unavailable still.
[02:08] <fabbione> thom: the reason for that might be related to the next undisclosed advisory :)
[02:08] <fabbione> that should actually happen in hmmm 1 hour and 52 minutes
[02:08] <thom> fabbione: doh
[02:09] <fabbione> pitti: do you still confirm?
[02:09] <thom> guess i'll get firefox 1.0.4 built while this rumbles on
[02:09] <pitti> fabbione: well, there is no patch whatsoever for the issue that is disclosed today
[02:10] <fabbione> pitti: ok..
[02:10] <fabbione> FUN
[02:10] <Mithrandir> is there any patch for the elf parser bug yet?
[02:10] <fabbione> Mithrandir: can?
[02:11] <fabbione> Paul Starzetz found an integer overflow in the ELF binary format
[02:11] <fabbione> this one?
[02:11] <Mithrandir> CAN-2005-1263
[02:11] <fabbione> yes
[02:11] <fabbione> dpatch-edit-patch: * Applying current stolen-from-head_CAN-2005-1263.dpatch for editing.
[02:11] <Mithrandir> nice
[02:29] <chmj> fabbione: I still have to learn git properlly, I'm currently doing some CXX transition stuff 
[02:30] <fabbione> exaclty
[02:30] <fabbione> ops
[02:30] <fabbione> chmj: we need the patch asap.. can you do it right away?
[02:31] <fabbione> otherwise i will
[02:32] <chmj> fabbione: I'm not properly clued up yet, I think you should for now 
[02:32] <chmj> provided you show me how 
[02:32] <fabbione> chmj: ok
[02:47] <fabbione> pitti: there is also a scsi tape security fix in 2.6.11.x
[02:47] <fabbione> do you know anything about it?
[02:47] <pitti> uh, no?
[02:48] <fabbione> i found the patch for the keyboard
[02:48] <fabbione> i am searching for the other one
[02:56] <fabbione> ah here it is
[02:58] <fabbione> thom: patches are on the way to you
[03:00] <thom> ta
[03:00] <fabbione> i need to teach this kernel fuckers on how to write a changelog and use a proper patch name
[03:02] <thom> fabbione: what naming scheme do you use for security patches?
[03:02] <fabbione> on warty i have none...
[03:02] <fabbione> for hoary/breezy is stolen-from-head_CAN-*
[03:03] <fabbione> or something sensible that matches the fix and the proper CAN entry in the changelog
[03:03] <thom> nod
[03:03] <fabbione> breezy actually is sth-*
[03:03] <fabbione> sfh-*
[03:03] <fabbione> well you got it
[03:03] <thom> ok, my disk io is totally rammed, i'm going for lunch
[03:03] <thom> heh, yup
[03:03] <fabbione> ahha
[03:03] <fabbione> buy more ram :)
[03:04] <thom> firefox and kernel building at once
[03:04] <fabbione> you crazy...
[03:04] <fabbione> or buy more amd64's
[03:04] <fabbione> distcc the kernel
[03:04] <thom> heh
[03:04] <fabbione> and firefox on local
[03:04] <thom> more ram is next on my list
[03:04] <Mithrandir> I'd go for the "buy more amd64s", just on general terms.
[03:04] <fabbione> Mithrandir: we are not all rich as you are :)
[03:05] <Mithrandir> fabbione: I just have my priorities right. :)
[03:05] <fabbione> you will understand after...
[03:05] <fabbione> ..after you will get married i mean
[03:06] <fabbione> X2 ?
[03:06] <Mithrandir> dualcore amd64
[03:06] <fabbione> ah ok
[03:12] <thom>  1  1   8124  84284   4284 227340    1    1   472   793  473   258 25 10 59  6
[03:12] <thom> definitely lunch time
[03:12] <thom> (that's vmstat)
[03:32] <svenl> Mithrandir: 2006 i guess.
[03:33] <Mithrandir> svenl: given that we had one for test last weekend, I doubt it.
[03:33] <Mithrandir> 2010 :P
[03:33] <svenl> Mithrandir: "at a non-cutthroat price:
[03:33] <fabbione> never...
[03:33] <Mithrandir> well, 750E is the current price they're talking about ATM.
[03:35] <svenl> Mithrandir: Mithrandir i read that massification will be during 2006, so i guess a year from now.
[03:35] <svenl> Mithrandir: but then intel's dual core is ways cheaper, so ...
[03:36] <svenl> Mithrandir: that said, dual core power4 and beyond are available since a couple years, so i think the dual core G5 will be available this year yet.
[03:37] <Mithrandir> svenl: well, Intel doesn't _have_ a dual core yet.  At least none I've seen.  And their 64 bit CPUs suck royally compared to AMD's.
[03:37] <thom> Mithrandir: the current top of line p4 EEs are dual core i thought
[03:37] <svenl> Mithrandir: but they start at 250$, or so the review says, while amd's base offering starts at 550$, but you are right.
[03:37] <Mithrandir> hm, they are?
[03:38] <thom> could well be wrong though
[03:38] <svenl> Mithrandir: i read a review about them yesterday somewhere, and i think so.
[03:38] <svenl> Mithrandir: they where saying that intel dual head didn't give such a speed advantage, because they already ate their smp bread with HT.
[03:38] <Mithrandir> hm, you're actually right
[03:40] <Mithrandir> apart from the fact that nobody is actually able to sell you one ATM.
[03:41] <Mithrandir> thom: yup, looks like it, but I'd rather have a opteron 265 than a P4 EE 840 :)
[03:41] <svenl> Mithrandir: is it true that the X2 will top out at >130W or something such ? 
[03:42] <Mithrandir> we had a full system with the top-of-the-line X2 and it drew 168W.
[03:42] <Mithrandir> (1G memory, Radeon 9800 pro/x700 single hard drive)
[03:42] <thom> Mithrandir: definitely
[03:43] <Mithrandir> thom: though, if I got a P4 EE I could probably get rid of my stove and just use the cooler for the CPU instead.
[03:43] <thom> heh
[04:06] <fabbione> thom: apparently there are no ABI changes
[04:06] <thom> score
[04:07] <fabbione> but the i386 chroot on concordia hates me
[04:08] <fabbione> there must be some x86_64 leaking somewhere
[04:08] <thom> you did "linux32 dchroot ...", right? :-)
[04:08] <fabbione> thom: i hate you
[04:09] <thom> you hate me because i'm right? :-)
[04:09] <fabbione> because i didn't know!
[04:09] <fabbione> amd64 is stupid
[04:09] <thom> heh
[04:10] <fabbione> that's because nobody have sent me one
[04:10] <fabbione> see..
[04:11] <zul> shesh you have more hardware than i do
[04:12] <fabbione> than you must suck even more than i do
[04:12] <zul> yes i think you  know that already
[04:13] <fabbione> eheh
[04:18] <chmj> heh
[04:19] <fabbione> thom: why did you upload cogito 0.8 ?????
[04:19] <fabbione> there 1.0 out
[04:20] <fabbione> or at least 0.9
[04:21] <thom> really? ber
[04:21] <thom> i'll update it soon then
[04:21] <fabbione> thom: www.kernel.org/git :)
[04:22] <zul> i just love the log for patch-10 ;)
[04:23] <fabbione> yeah
[04:24] <dilinger> speaking of cogito
[04:24] <dilinger> is there a way to diff changesets or files?
[04:24] <dilinger> or see your last few commits?
[04:25] <fabbione> diff changesets?
[04:25] <fabbione> you mean to get a patch from a changeset?
[04:28] <dilinger> right
[04:28] <dilinger> in baz speak, i want to baz diff base-0 patch-1
[04:29] <dilinger> or do the same but for a single file (which i'm not sure is possible in baz)
[04:29] <dilinger> or baz logs -s
[04:29] <dilinger> s/or/and/
[04:34] <dilinger> i was playing around w/ cogito yesterday, but didn't see any way to do those
[04:35] <dilinger> but i haven't looked at the newly announced packages, which apparently include documentation
[04:35] <thom> there is not a lot of docs in 0.10
[04:38] <fabbione> dilinger: i use cg-log to get the log history
[04:38] <fabbione> and cg-mkpatch -r $commit_num_from_cg-log 
[04:38] <fabbione> to get the patch
[04:40] <zul> im out of here for a bit...back later
[04:41] <dilinger> fabbione: neat, thanks
[04:41] <fabbione> dilinger: what is our use, we don't really need more than that :)
[04:42] <dilinger> fabbione: i want to update my bitkeeper helper scripts to use cogito (or git, if cogito doesn't provide the functionality)
[04:44] <fabbione> eheh
[05:03] <fabbione> lamont: you won't believe it.. i am still doing the checkout for linux-ipv6
[05:03] <fabbione> if i did travel to the server, pluged a disk, copy and fly back, i would have been faster
[05:04] <lamont> fabbione: wth??
[05:04] <fabbione> it's SLOOOOOW
[05:04] <lamont> I originally parsed that as itanglish for 'investigating' - was wondering what was so complicated...  this makes much more sense, given you, etc, etc...  but holy hell...
[05:48] <thom> right, so the abi check stuff seems to work correctly with the warty build system, so that's good
[05:48] <fabbione> did you port the abi checker to the warty kernel?
[05:49] <thom> i think so :-)
[05:49] <thom> i'll find out when i finish with dpatch and run it again
[05:49] <fabbione> ehehhee
[05:50] <fabbione> i am not 10000% sure mdz will like to see that in warty...
[05:50] <fabbione> but we all know that baz sometimes merges wrong bits and pieces...
[05:51] <fabbione> ok i am off
[05:51] <thom> well, it's only like 10 lines of shell; i'll try it on all arches and see
[05:51] <thom> ciao
[05:51] <fabbione> amd64/ppc/i386 hoary is build
[05:51] <fabbione> elmo is going to test it tomorrow at the DC
[05:51] <fabbione> and we are good to go
[05:51] <pitti> thom: would be cool, though :-) I mean, it doesn't actually change any source code, does it?
[05:52] <fabbione> cya either later or tomorrow
[05:52] <pitti> see you fabbione, thanks so far
[05:52] <fabbione> pitti: nope.. not a single line
[05:52] <fabbione> it's all in the build system
[05:52] <thom> no, it changes no source
[05:52] <pitti> yeah, it's more or less only an ultra-clever grep over the sources, isn't it?
[05:53] <thom> yep
[06:10] <zul> meh
[06:31] <dilinger> i just discovered we're using reiserfs on a few machines here
[06:31] <thom> ewww
[06:31] <thom> have the responsible parties been slapped
[06:31] <thom> ?
[06:33] <dilinger> i've only been here less than 2 weeks, i'm not allowed to slap people for at least another few weeks
[06:34] <lamont> dilinger: but btrees are _KEWL_ doncha know...
[06:34] <lamont> or are those production machines?
[06:37] <zul> dilinger: the probably didnt know better....
[06:46] <dilinger> lamont: they're production
[06:47] <zul> ok now you can shoot them
[07:45] <dilinger> aw
[07:46] <dilinger> no search love on kernel.org/git :/
[08:06] <zul> heh
[08:12] <thom> huh. This Morn' Omina is great hacking music
[08:40] <dilinger> thom: a watched kernel never compiles.  something i learned very early on :)
[08:40] <dilinger> i usually kick off a build before bed or something
[08:46] <thom> ber
[09:14] <zul> i have naps
[11:24] <thom> i watched blade trinity
[11:57] <zul> meh