[07:17] <fabbione> morning
[07:52] <lamont> elmo: yellow has been behaving, yes
[10:18] <elmo> doko_: ?
[10:19] <fabbione> hey elmo
[10:19] <doko_> morning
[10:19] <doko_> elmo: hi
[10:20] <elmo> doko: dude, why are we still blacklisting apps?
[10:20] <doko> because I didn't do my homework yet to reduce the cxxapps list
[10:20] <elmo> no, I mean, in general
[10:21] <doko> not all libs in universe are already converted
[10:21] <elmo> right, but the same question I asked the other day, applys - couldn't we not blacklist stuff and once we've done the transition determine what we need to recompile?
[10:22] <elmo> AFAICS, the only thing we'll miss is stuff linking statically with C++, and I'm not sure missing that is worth the pain of managing the c++ apps list on the buildds
[10:24] <doko> hmm, let me reduce the list today for one time, please. for another reason it's a bad time to push all the packages to the buildd's now: uninstallability of xbase-clients will break all kde builds
[10:25] <elmo> the blacklist is a BIG BLOODY HAMMER, we shouldn't be using it to avoid random breakage
[10:26] <doko> yes, and a clean reduction seems to be doable and easy
[10:26] <elmo> I'm talking in general, I don't think the app blacklist is the right way to handle this
[10:27] <elmo> I think we can assume that someone is uploading an app, it's their responsiblity to ensure that everything it's built against is transitioned
[10:27] <elmo> I don't mind the sync blacklist, but the buildd blacklist is just PAIN
[10:27] <elmo> and this concept is entirely not going to work for Debian, I can tell you that right now
[10:28] <doko> I know, the right way are modified build deps, but we didn't want this at the start. I know that it doesn't work for Debian, but we didn't want to modify the 800 blocked packages. that was the price
[10:40] <elmo> lamont: dude, why on earth didn't we use NFU?
[10:40] <doko> NFU?
[10:41] <elmo> not-for-us
[10:41] <elmo> the wanna-build state
[10:41] <elmo> rather than altering 18 config files on buildds
[10:58] <doko> jbailey: have a 32bit libgcj working, but 21 test suite failures, 1 is a bug in the testcase, the others all signal related :(
[12:47] <jbailey> doko: This is amd64?
[02:33] <lamont> elmo: IIRC, NFU still gets a should-I-build message, which we told buildd to just answer 'ok'.
[02:33] <lamont> OTOH, I could have dep-waited them on 'cxxlibs' or something
[02:42] <lamont> and it's only 15 config files (across 6 architectures)
[02:43] <lamont> and sed -i does a reasonable job.  At the same time, I was given to expect that we'd be adding/removing the list as a unit (haven't decided if I should reasonably have expected that or not...)
[02:45] <lamont> having looked, NFU doesn't seem to get a should-build msg, but I seem to remember something annoying with email related to that state, etc.
[02:45] <elmo> that's fails
[02:45] <elmo> nfu is fairly permanent
[02:46] <elmo> dep-wait would have worked too
[03:02] <lamont> elmo: I'll burn some time today and switch the blacklist into a breezy NFU state
[03:02] <lamont> or maybe a dep-wait on something bogus
[03:02] <lamont> or better yet, if doko does his homework and tells me which version of which package each thing is actually blocked by, then I can use a real depwait....
[03:03] <lamont> but right now, I need to get ready and go to work.
[03:26] <infinity> NFU would have worked fantastically for this purpose.
[04:01] <lamont> gcc-3.3 ICE in debian.  sigh.
[04:31] <infinity> GCC never ICEs, you must be imagining things.
[04:54] <doko> jbailey: yes, amd64
[04:55] <jbailey> doko: 'kay.  So I need to get on with getting Tollef's multiarch stuff in and happy, I guess.
[04:56] <jbailey> doko: He mentioned a baz patchset that he thinks needs to be applied.  I haven't looked at it yet.
[04:56] <lamont__> doko: so are you going to work through the list of what each cxxapp should d-w on?
[05:08] <infinity> lamont__ : If he does, I can implement it.
[05:37] <doko> lamont__, yes, working on it now ...
[06:12] <lamont__> infinity: it's just a slew of wanna-build --dep-wait commands, followed by dropping the massive sledge hammer that is @no_auto_build

[06:13] <infinity> S'what I assumed.
[06:14] <infinity> And I'm pretty darned fast at doing mass dep-waits. :)
[06:14] <infinity> Someone used to send me complete lists of build-order for gnome uploads on m68k.
[06:14] <lamont__> especially when they can be scripted... :-)
[06:14] <infinity> Which was pretty handy.  I wish more maintainers were that nice.
[06:15] <lamont__> infinity: of course, if the packages just had correctly versioned build-deps, then it doesn't really matter, modulo download speed
[06:15] <infinity> Yeah, the gnome team moved from hand-massaging to tighter build-deps.
[06:16] <infinity> Though the hand-massaging actually worked better anyway.
[06:16] <infinity> (Well, if there was communication, obviously.. Otherwise, it all blew up horribly)
[06:16] <lamont__> feh
[06:17] <infinity> 3rd IDE controller on your laptop?... Dude, where would you even plug in a third IDE drive?
[06:17] <lamont__> docking station
[06:17] <infinity> That seems excessive to me.
[06:17] <lamont__> ide1 at 0x170-0x177,0x376 on irq 15
[06:17] <lamont__> ide2: I/O resource 0x3EE-0x3EE not free.
[06:17] <lamont__> ide2: ports already in use, skipping probe
[06:17] <infinity> Ahh.  Right.  I forgot people still had those.
[06:18] <infinity> That's a werid place to put a serial port.
[06:18] <lamont__> the current solution for a desktop for me is a laptop+docking station
[06:18] <infinity> weird, too.
[06:18] <lamont__> serial is 3f8-3fe, 3e8-3ee
[06:19] <lamont__> hrm... maybe that's just the kernel being excessive...
[06:19] <infinity> COM1/COm2 is 2f8-2fe/3f8-3fe, aren't they?
[06:19] <lamont__> lspci only shows one IDE interface
[06:19] <infinity> (Or reversed from that)
[06:20] <infinity> Still, 3ee is very not normal to be used by... Anything.
[06:20] <lamont__> 0170-0177 : ide1
[06:20] <lamont__> 01f0-01f7 : ide0
[06:20] <lamont__> 0376-0376 : ide1
[06:20] <lamont__> 03e8-03ef : serial
[06:20] <lamont__> 03f6-03f6 : ide0
[06:20] <lamont__> 03f8-03ff : serial
[06:20] <lamont__> but yeah.
[06:20] <lamont__> and OT anyway
[06:21] <infinity> Sure, it is. :)
[06:21] <infinity> (If that's two ports, reconfigure the first one in the BIOS to 2f8-2fe where it belongs)
[06:21] <infinity> And now I stop being OT.
[06:29] <\sh> lamont__: u have the nc6000? it's not the serial, it's the irda port u should fix
[06:30] <\sh> 3ee comes from this nasty irda chip..the chipset is in the kernel, but on the wrong sir/fir addr..i tried to patch it to work..but no success
[06:33] <lamont__> \sh: ah, cool.
[06:34] <\sh> lamont__: hp bugged
[06:37] <\sh> lamont__: another thing, u mentioned the portreplicator...
[06:38] <\sh> lamont__: don't use it, it will kill your laptop at some time...in our company we're using now those nc6000 with portreps...and 3 of them died using it...if it's not connected properly :(
[06:39] <lamont__> \sh: when it kills the laptop, I'll make 'em get me a new one....
[06:40] <lamont__> is pretty common in the lab here - doesn't seem to be a big issue for folks
[06:41] <\sh> lamont__: yeah...this one i have, too..it killed my mainboard and cpu and ram at the same time...for the other 2 it was only the mainboard and cpu
[06:42] <fabbione> re
[06:42] <\sh> lamont__: sometimes the connectors are not fitting correctly and as we found out, it's a common failure of this hw
[06:42] <fabbione> lamont__: did you already do the de-wait magic?
[06:43] <infinity> fabbione : For the CXX stuff?
[06:43] <fabbione> yeah
[06:43] <infinity> Nope.
[06:44] <infinity> doko's supposed to be making a list. :)
[06:46] <doko> infinity: shhtt ...
[06:47] <infinity> doko : You're missing an "i" in there somewhere.
[06:48] <doko> nfnty: which one? ;-)
[06:48] <infinity> Between the hh and tt, I'd say. :)
[06:48] <infinity> (or, perhaps in place of one of each...)
[06:48] <lamont__> infinity: if you want to handle the DC buildd's that'd be cool.  hppa/sparc still need me/fabbione though...
[06:50] <infinity> lamont__ : Yup.  I can do the DCs and provide a script for the others, if you guys feel lazy.
[06:52] <doko> infinity, lamont__: are you allowed to build a package without one build dependency?
[06:52] <fabbione> infinity: yes :)
[06:52] <fabbione> i am lazy to death
[06:53] <infinity> doko : Define "allowed".  I could build it for bootstrap purposes, but not upload it.  It'd have to be rebuilt for uploading.
[07:10] <doko> infinity: trying to find a way to build zlib without updating ia32-libs two times.
[07:11] <infinity> doko : Just waste the CPU and bandwidth and do it twice?
[07:13] <lamont__> infinity: laziness is next to godliness
[07:13] <lamont__> doko: dpkg-buildpackage fails if debian/control lists a build-dep that isn't resolved.
[07:14] <doko> hmm, ok
[07:14] <lamont__> why would building zlib requre building ia32-libs twice?
[07:15] <doko> you currently cannot build it, because of a broken dependency (missing lib32z1), but you need it for the 32bit libc
[07:18] <doko> 1) upload old ia32-libs, 2) build zlib, 3) redo the ia32-libs change
[07:19] <infinity> So just do it?... It would have been done in the time you spent talking about it.
[07:21] <doko> ahh, yes, that's not m68k speed
[07:22] <infinity> doko : Also, I give up on your java stuff. :)
[07:22] <infinity> doko : E: Package libant1.6-java has no installation candidate
[07:22] <infinity> (From ecj-bootstrap)
[07:22] <doko> ?
[07:23] <infinity> Oh, feh.  ecj-bootstrap went to main.  Was it supposed to be in universe?
[07:23] <infinity> (I assume that libant is in universe)
[07:24] <doko> it is in universe ...
[07:25] <infinity> ecj-bootstrap appears to be in main.  Did someone re-seed it?
[07:25] <doko> we should really have the java stuff still in main ... that's development work.
[07:25] <infinity> At any rate, until ecj-bootstrap gets seeded back to universe, or libant moves to main, this build will go nowhere.
[07:25] <infinity> So, I suggest you get that fixed. :)
[07:25] <doko> java-gcj-compat was in main, AFAIK, because OOo2 needed it
[07:32] <infinity> doko : If you work out the CXX transition build-dep/dep-wait tree, can you mail it to me, and I'll do the DC buildds when I wake up (in 5 or 6 hours) and forward the script off to lamont and fabbione for the private buildds.
[07:32] <infinity> doko : If you don't get around to it, I'll just bug you about it again tomorrow. :)
[07:34] <doko> infinity: let's see ;-)
[08:53] <doko> lamont__, infinity: are the buildd's running? zlib, ia32-libs
[10:44] <fabbione> lamont__: you around?
[10:44] <fabbione> jbailey; ?
[10:45] <lamont__> fabbione: yeah
[10:46] <fabbione> lamont__: how are you hadling xbse-client fuckups on the buildd?=
[10:46] <lamont__> clarify
[10:46] <fabbione> i get some FTBFS because xbase-clientes 6.8.2-21 is not installable
[10:46] <fabbione> or better
[10:47] <fabbione> it fails to install
[10:47] <lamont__> ah...  generally speaking, I've just been giving back everything that didn't build due to build-deps a couple times, then bitching about it..... (truth be told)
[10:47] <lamont__> but in the ideal world, one would determine why it wasn't installable, and then dep-wait on the right thing
[10:48] <fabbione> ok about dep-wait..
[10:48] <fabbione> i do the same too
[10:48] <fabbione> but right now kde* can't build because xbase-client doesn't install
[10:48] <fabbione> and it's not due to dependencies
[10:49] <fabbione> but because it fails to unpack or something
[10:49] <lamont__> gack
[10:49] <jbailey> fabbione: Hey!
[10:49] <jbailey> fabbione: Oh, you replyied to my ping earlier too, hmm.  Lemme dig that up.
[10:49] <fabbione> jbailey: i saw you did ping me before...
[10:49] <fabbione> yeah i have only a few minutes...
[10:49] <fabbione> and i need to go away
[10:49] <fabbione> i just passed to give a huge kickback on sparc
[10:50] <jbailey> lustre patches...
[10:50] <jbailey> Apparently their goal is to get everything in kernel.
[10:50] <jbailey> So the person I was talking with thinks that they might be willing to provide recent versions / security fixes and such.
[10:51] <fabbione> jbailey: ok.. we need to go in details for that.. can we do it when i wake up in few hours or tomorrow that my wife is away?
[10:51] <jbailey> Yup.  Tuesdays and Thursdays are support days for me, anyway.  I've been making about avoiding hacking on them and am trying to be better about it. =)
[10:51] <fabbione> ehhehe ok :)
[10:51] <jbailey> g'n =)
[10:52] <fabbione> for me tuesday/thursday are userland days :)
[10:52] <fabbione> wed is a mis ;)
[10:52] <fabbione> monday/friday kernel
[10:52] <jbailey> Yup, Monday is my mix day.
[10:52] <jbailey> Catch up from the weekend and such.
[10:52] <fabbione> ehhe
[10:52] <fabbione> i am off than
[10:52] <jbailey> Thu/Fri hacking days.
[10:52] <jbailey> See you!
[10:52] <fabbione> good night folks
[10:53] <fabbione> cya in few hours
[10:59] <doko> lamont, lamont__, infinity: new frozen app list (2nd column): chinstrap:~doko/frozenapps.txt