=== doko_ [~doko___@dsl-082-082-199-023.arcor-ip.net] has joined #ubuntu-toolchain [07:17] morning [07:52] elmo: yellow has been behaving, yes === \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain [10:18] doko_: ? [10:19] hey elmo [10:19] morning [10:19] elmo: hi [10:20] doko: dude, why are we still blacklisting apps? [10:20] because I didn't do my homework yet to reduce the cxxapps list [10:20] no, I mean, in general [10:21] not all libs in universe are already converted [10:21] 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] 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 === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [10:24] 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] the blacklist is a BIG BLOODY HAMMER, we shouldn't be using it to avoid random breakage [10:26] yes, and a clean reduction seems to be doable and easy [10:26] I'm talking in general, I don't think the app blacklist is the right way to handle this [10:27] 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] I don't mind the sync blacklist, but the buildd blacklist is just PAIN [10:27] and this concept is entirely not going to work for Debian, I can tell you that right now [10:28] 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] lamont: dude, why on earth didn't we use NFU? [10:40] NFU? [10:41] not-for-us [10:41] the wanna-build state [10:41] rather than altering 18 config files on buildds [10:58] 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] doko: This is amd64? [02:33] elmo: IIRC, NFU still gets a should-I-build message, which we told buildd to just answer 'ok'. [02:33] OTOH, I could have dep-waited them on 'cxxlibs' or something [02:42] and it's only 15 config files (across 6 architectures) [02:43] 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] 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] that's fails [02:45] nfu is fairly permanent [02:46] dep-wait would have worked too [03:02] elmo: I'll burn some time today and switch the blacklist into a breezy NFU state [03:02] or maybe a dep-wait on something bogus [03:02] 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] but right now, I need to get ready and go to work. [03:26] NFU would have worked fantastically for this purpose. [04:01] gcc-3.3 ICE in debian. sigh. [04:31] GCC never ICEs, you must be imagining things. === lamont__ [~lamont@15.238.6.24] has joined #ubuntu-toolchain [04:54] jbailey: yes, amd64 [04:55] doko: 'kay. So I need to get on with getting Tollef's multiarch stuff in and happy, I guess. [04:56] doko: He mentioned a baz patchset that he thinks needs to be applied. I haven't looked at it yet. [04:56] doko: so are you going to work through the list of what each cxxapp should d-w on? [05:08] lamont__ : If he does, I can implement it. === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain [05:37] lamont__, yes, working on it now ... [06:12] 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] [06:13] S'what I assumed. [06:14] And I'm pretty darned fast at doing mass dep-waits. :) [06:14] Someone used to send me complete lists of build-order for gnome uploads on m68k. [06:14] especially when they can be scripted... :-) [06:14] Which was pretty handy. I wish more maintainers were that nice. [06:15] infinity: of course, if the packages just had correctly versioned build-deps, then it doesn't really matter, modulo download speed === lamont__ discovers that he needs to reconfigure the serial port on his laptop, so that the 3rd ide controller is usable [06:15] Yeah, the gnome team moved from hand-massaging to tighter build-deps. [06:16] Though the hand-massaging actually worked better anyway. [06:16] (Well, if there was communication, obviously.. Otherwise, it all blew up horribly) [06:16] feh [06:17] 3rd IDE controller on your laptop?... Dude, where would you even plug in a third IDE drive? [06:17] docking station [06:17] That seems excessive to me. [06:17] ide1 at 0x170-0x177,0x376 on irq 15 [06:17] ide2: I/O resource 0x3EE-0x3EE not free. [06:17] ide2: ports already in use, skipping probe [06:17] Ahh. Right. I forgot people still had those. [06:18] That's a werid place to put a serial port. [06:18] the current solution for a desktop for me is a laptop+docking station [06:18] weird, too. [06:18] serial is 3f8-3fe, 3e8-3ee [06:19] hrm... maybe that's just the kernel being excessive... [06:19] COM1/COm2 is 2f8-2fe/3f8-3fe, aren't they? [06:19] lspci only shows one IDE interface [06:19] (Or reversed from that) === lamont__ ponders the meaning of /proc/ide/ide0/mate [06:20] Still, 3ee is very not normal to be used by... Anything. [06:20] 0170-0177 : ide1 [06:20] 01f0-01f7 : ide0 [06:20] 0376-0376 : ide1 [06:20] 03e8-03ef : serial [06:20] 03f6-03f6 : ide0 [06:20] 03f8-03ff : serial [06:20] but yeah. [06:20] and OT anyway [06:21] Sure, it is. :) [06:21] (If that's two ports, reconfigure the first one in the BIOS to 2f8-2fe where it belongs) [06:21] 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] \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] \sh: when it kills the laptop, I'll make 'em get me a new one.... === lamont__ is using the multi-bay replicator [06:40] 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] 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] lamont__: did you already do the de-wait magic? [06:43] fabbione : For the CXX stuff? [06:43] yeah [06:43] Nope. [06:44] doko's supposed to be making a list. :) [06:46] infinity: shhtt ... [06:47] doko : You're missing an "i" in there somewhere. [06:48] nfnty: which one? ;-) [06:48] Between the hh and tt, I'd say. :) [06:48] (or, perhaps in place of one of each...) [06:48] infinity: if you want to handle the DC buildd's that'd be cool. hppa/sparc still need me/fabbione though... [06:50] lamont__ : Yup. I can do the DCs and provide a script for the others, if you guys feel lazy. [06:52] infinity, lamont__: are you allowed to build a package without one build dependency? [06:52] infinity: yes :) [06:52] i am lazy to death [06:53] doko : Define "allowed". I could build it for bootstrap purposes, but not upload it. It'd have to be rebuilt for uploading. [07:10] infinity: trying to find a way to build zlib without updating ia32-libs two times. [07:11] doko : Just waste the CPU and bandwidth and do it twice? [07:13] infinity: laziness is next to godliness [07:13] doko: dpkg-buildpackage fails if debian/control lists a build-dep that isn't resolved. [07:14] hmm, ok [07:14] why would building zlib requre building ia32-libs twice? [07:15] you currently cannot build it, because of a broken dependency (missing lib32z1), but you need it for the 32bit libc [07:18] 1) upload old ia32-libs, 2) build zlib, 3) redo the ia32-libs change [07:19] So just do it?... It would have been done in the time you spent talking about it. [07:21] ahh, yes, that's not m68k speed [07:22] doko : Also, I give up on your java stuff. :) [07:22] doko : E: Package libant1.6-java has no installation candidate [07:22] (From ecj-bootstrap) [07:22] ? [07:23] Oh, feh. ecj-bootstrap went to main. Was it supposed to be in universe? [07:23] (I assume that libant is in universe) [07:24] it is in universe ... [07:25] ecj-bootstrap appears to be in main. Did someone re-seed it? [07:25] we should really have the java stuff still in main ... that's development work. [07:25] At any rate, until ecj-bootstrap gets seeded back to universe, or libant moves to main, this build will go nowhere. [07:25] So, I suggest you get that fixed. :) [07:25] java-gcj-compat was in main, AFAIK, because OOo2 needed it === Mithrandir [~tfheen@vawad.err.no] has joined #ubuntu-toolchain === infinity decides to go back to bed in an effort to get back on his own timezone. [07:32] 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] doko : If you don't get around to it, I'll just bug you about it again tomorrow. :) [07:34] infinity: let's see ;-) [08:53] lamont__, infinity: are the buildd's running? zlib, ia32-libs === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain [10:44] lamont__: you around? [10:44] jbailey; ? [10:45] fabbione: yeah [10:46] lamont__: how are you hadling xbse-client fuckups on the buildd?= [10:46] clarify [10:46] i get some FTBFS because xbase-clientes 6.8.2-21 is not installable [10:46] or better [10:47] it fails to install [10:47] 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] but in the ideal world, one would determine why it wasn't installable, and then dep-wait on the right thing [10:48] ok about dep-wait.. [10:48] i do the same too [10:48] but right now kde* can't build because xbase-client doesn't install [10:48] and it's not due to dependencies [10:49] but because it fails to unpack or something [10:49] gack [10:49] fabbione: Hey! [10:49] fabbione: Oh, you replyied to my ping earlier too, hmm. Lemme dig that up. [10:49] jbailey: i saw you did ping me before... [10:49] yeah i have only a few minutes... [10:49] and i need to go away [10:49] i just passed to give a huge kickback on sparc [10:50] lustre patches... [10:50] Apparently their goal is to get everything in kernel. [10:50] So the person I was talking with thinks that they might be willing to provide recent versions / security fixes and such. [10:51] 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] 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] ehhehe ok :) [10:51] g'n =) [10:52] for me tuesday/thursday are userland days :) [10:52] wed is a mis ;) [10:52] monday/friday kernel [10:52] Yup, Monday is my mix day. [10:52] Catch up from the weekend and such. [10:52] ehhe [10:52] i am off than [10:52] Thu/Fri hacking days. [10:52] See you! [10:52] good night folks [10:53] cya in few hours [10:59] lamont, lamont__, infinity: new frozen app list (2nd column): chinstrap:~doko/frozenapps.txt