=== doko_ [~doko___@dsl-082-082-199-023.arcor-ip.net] has joined #ubuntu-toolchain | ||
fabbione | morning | 07:17 |
---|---|---|
lamont | elmo: yellow has been behaving, yes | 07:52 |
=== \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain | ||
elmo | doko_: ? | 10:18 |
fabbione | hey elmo | 10:19 |
doko_ | morning | 10:19 |
doko_ | elmo: hi | 10:19 |
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:20 |
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:21 |
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:22 |
=== chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain | ||
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:24 |
elmo | the blacklist is a BIG BLOODY HAMMER, we shouldn't be using it to avoid random breakage | 10:25 |
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:26 |
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:27 |
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:28 |
elmo | lamont: dude, why on earth didn't we use NFU? | 10:40 |
doko | NFU? | 10:40 |
elmo | not-for-us | 10:41 |
elmo | the wanna-build state | 10:41 |
elmo | rather than altering 18 config files on buildds | 10:41 |
doko | jbailey: have a 32bit libgcj working, but 21 test suite failures, 1 is a bug in the testcase, the others all signal related :( | 10:58 |
jbailey | doko: This is amd64? | 12:47 |
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:33 |
lamont | and it's only 15 config files (across 6 architectures) | 02:42 |
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:43 |
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:45 |
elmo | dep-wait would have worked too | 02:46 |
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:02 |
lamont | but right now, I need to get ready and go to work. | 03:03 |
infinity | NFU would have worked fantastically for this purpose. | 03:26 |
lamont | gcc-3.3 ICE in debian. sigh. | 04:01 |
infinity | GCC never ICEs, you must be imagining things. | 04:31 |
=== lamont__ [~lamont@15.238.6.24] has joined #ubuntu-toolchain | ||
doko | jbailey: yes, amd64 | 04:54 |
jbailey | doko: 'kay. So I need to get on with getting Tollef's multiarch stuff in and happy, I guess. | 04:55 |
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? | 04:56 |
infinity | lamont__ : If he does, I can implement it. | 05:08 |
=== Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
doko | lamont__, yes, working on it now ... | 05:37 |
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:12 |
infinity | <nod> | 06:13 |
infinity | S'what I assumed. | 06:13 |
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:14 |
lamont__ | infinity: of course, if the packages just had correctly versioned build-deps, then it doesn't really matter, modulo download speed | 06:15 |
=== lamont__ discovers that he needs to reconfigure the serial port on his laptop, so that the 3rd ide controller is usable | ||
infinity | Yeah, the gnome team moved from hand-massaging to tighter build-deps. | 06:15 |
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:16 |
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:17 |
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:18 |
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:19 |
=== lamont__ ponders the meaning of /proc/ide/ide0/mate | ||
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:20 |
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:21 |
\sh | lamont__: u have the nc6000? it's not the serial, it's the irda port u should fix | 06:29 |
\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:30 |
lamont__ | \sh: ah, cool. | 06:33 |
\sh | lamont__: hp bugged | 06:34 |
\sh | lamont__: another thing, u mentioned the portreplicator... | 06:37 |
\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:38 |
lamont__ | \sh: when it kills the laptop, I'll make 'em get me a new one.... | 06:39 |
=== lamont__ is using the multi-bay replicator | ||
lamont__ | is pretty common in the lab here - doesn't seem to be a big issue for folks | 06:40 |
\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:41 |
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:42 |
infinity | fabbione : For the CXX stuff? | 06:43 |
fabbione | yeah | 06:43 |
infinity | Nope. | 06:43 |
infinity | doko's supposed to be making a list. :) | 06:44 |
doko | infinity: shhtt ... | 06:46 |
infinity | doko : You're missing an "i" in there somewhere. | 06:47 |
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:48 |
infinity | lamont__ : Yup. I can do the DCs and provide a script for the others, if you guys feel lazy. | 06:50 |
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:52 |
infinity | doko : Define "allowed". I could build it for bootstrap purposes, but not upload it. It'd have to be rebuilt for uploading. | 06:53 |
doko | infinity: trying to find a way to build zlib without updating ia32-libs two times. | 07:10 |
infinity | doko : Just waste the CPU and bandwidth and do it twice? | 07:11 |
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:13 |
doko | hmm, ok | 07:14 |
lamont__ | why would building zlib requre building ia32-libs twice? | 07:14 |
doko | you currently cannot build it, because of a broken dependency (missing lib32z1), but you need it for the 32bit libc | 07:15 |
doko | 1) upload old ia32-libs, 2) build zlib, 3) redo the ia32-libs change | 07:18 |
infinity | So just do it?... It would have been done in the time you spent talking about it. | 07:19 |
doko | ahh, yes, that's not m68k speed | 07:21 |
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:22 |
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:23 |
doko | it is in universe ... | 07:24 |
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:25 |
=== 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. | ||
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:32 |
doko | infinity: let's see ;-) | 07:34 |
doko | lamont__, infinity: are the buildd's running? zlib, ia32-libs | 08:53 |
=== rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain | ||
fabbione | lamont__: you around? | 10:44 |
fabbione | jbailey; ? | 10:44 |
lamont__ | fabbione: yeah | 10:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
fabbione | cya in few hours | 10:53 |
doko | lamont, lamont__, infinity: new frozen app list (2nd column): chinstrap:~doko/frozenapps.txt | 10:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!