| didrocks | tjaalton: but seeding sssd to supported is trying to pull samba4 in main | 11:12 |
|---|---|---|
| didrocks | tjaalton: so, build-dep needs to be investigated :) | 11:12 |
| didrocks | tjaalton: btw, as core-dev you can change the seed yourself :) | 11:13 |
| tjaalton | oh? | 11:19 |
| tjaalton | maybe it wants the new samba in main first | 11:20 |
| tjaalton | if you could promote all of ldb there that should be fulfilled | 11:20 |
| tjaalton | didrocks: ^ | 11:22 |
| didrocks | tjaalton: I doubt that it tries to pull "samba4" (see what I pasted in the comment) because samba itself is not in main | 11:22 |
| didrocks | tjaalton: the -dev samba dep is in proposed or release pocket? | 11:22 |
| tjaalton | proposed | 11:23 |
| didrocks | tjaalton: ah, maybe that's why, probably, the seed is only computing the mismatch in the release pocket | 11:23 |
| tjaalton | yeah, would make sense | 11:23 |
| didrocks | tjaalton: I think just gives a heads'up once it's in the release pocket and seed it | 11:23 |
| didrocks | then, the quickest will promote those :) | 11:24 |
| tjaalton | fixing bug 1250463 should be the key then | 11:24 |
| ubot2 | Launchpad bug 1250463 in ldb (Ubuntu) "[MIR] ldb" [Undecided,Triaged] https://launchpad.net/bugs/1250463 | 11:24 |
| tjaalton | other rdeps were promoted already | 11:24 |
| tjaalton | of samba | 11:24 |
| didrocks | tjaalton: I guess needs doko to revisit it | 11:25 |
| tjaalton | could be | 11:26 |
| infinity | tjaalton: Which bindings are you refering to in the bug? | 12:08 |
| tjaalton | infinity: python-ldb | 12:10 |
| infinity | tjaalton: It's in main. | 12:10 |
| tjaalton | huh | 12:10 |
| tjaalton | ok | 12:10 |
| infinity | So, what are we actually trying to solve here? :P | 12:10 |
| tjaalton | so what's blocking the new samba then? | 12:10 |
| tjaalton | getting samba out of proposed | 12:10 |
| tjaalton | unless it's artificially held there due to known bugs? | 12:11 |
| infinity | component mismatches don't block promotions anyway, britney doesn't know about components (sadly). | 12:11 |
| infinity | tjaalton: update_output.txt shows it breaking a... Lot of stuff. | 12:12 |
| infinity | tjaalton: A few of those can go away if I remove samba4 from the archive, but not most of them. | 12:12 |
| infinity | tjaalton: And it might be tied up in the libav transition too. | 12:13 |
| infinity | tjaalton: Yeah, it is. | 12:13 |
| tjaalton | okay | 12:13 |
| tjaalton | i don't mind if sssd is stuck in proposed until those are all solved | 12:14 |
| infinity | Good, cause you minding wouldn't have changed anything. :) | 12:14 |
| infinity | (Except perhaps motivate you to help with the libav transition) | 12:14 |
| tjaalton | sure :) | 12:14 |
| === chuck__ is now known as zul | ||
| tjaalton | infinity: so what line should I be looking if sorting the libav rdep rebuilds? | 13:15 |
| tjaalton | i have update_output.txt open | 13:15 |
| cjwatson | tjaalton: The block that starts "Trying easy from autohinter: samba/2:4.0.10+dfsg-4ubuntu1" | 13:38 |
| cjwatson | Some of those will be samba, some libav, since they're now intertangled thanks to the server team's enthusiasm :-P | 13:38 |
| cjwatson | There's also the block starting "Trying easy from autohinter: libav/6:9.10-1ubuntu1" but I suspect that's misleading ... | 13:39 |
| ogra_ | why is that ? does libav do video streaming via CIFS now ? | 13:39 |
| cjwatson | ogra_: All it takes is some reverse-dependency that touches both stacks | 13:40 |
| cjwatson | I don't know which one and don't much care | 13:41 |
| === exekias_ is now known as exekias | ||
| tjaalton | cjwatson: ok, thanks | 13:41 |
| cjwatson | grr, proposed-migration crashing | 14:27 |
| cjwatson | will look as soon as I have spare brain cycles | 14:27 |
| cjwatson | copyPackage libelf/0.8.13-4: libelf is not published in Primary Archive for Ubuntu. | 14:27 |
| cjwatson | Actually | 14:28 |
| cjwatson | WTF happened to trusty | 14:28 |
| cjwatson | https://launchpad.net/ubuntu/+source/man-db -> no trusty | 14:28 |
| apw | cjwatson, seems to be gone | 14:43 |
| cjwatson | Yes, I'm firefighting on #launchpad-ops | 14:43 |
| cjwatson | Somebody marked it experimental, presumably by accident, but I can find no audit trail right now ... | 14:44 |
| rsalveti | infinity: thanks for fixing the android package btw | 14:45 |
| tjaalton | visp seems to have been built against libavcodec53 from the old libav, but libavutil52 from the new.. | 14:47 |
| tjaalton | there might be others like that | 14:47 |
| marrusl | Is there a specific release date for 14.04.1 yet? or is it "about 3.5 months after 14.04"? | 14:52 |
| cjwatson | not as yet, we'd need to extrapolate that from the 12.04 schedule I guess | 14:53 |
| marrusl | cjwatson, It seems like it's usually about 3.5 months. that will do for an answer now. thanks. | 14:55 |
| slangasek | I don't think there've been enough LTSes to say when it's "usually" been | 14:57 |
| slangasek | IIRC, the interval between 10.04 and 10.04.1 was much shorter | 14:58 |
| === alex-abreu|afk is now known as alex-abreu | ||
| cjwatson | OK, /ubuntu/trusty recovered, it was a misfire for /charms/trusty | 15:04 |
| rsalveti | seems the android-emulator package is gone from the archive/mirror | 15:38 |
| rsalveti | wonder if that is a side effect of the proposed migration crash | 15:38 |
| ogra_ | cjwatson, there seems to be a mirroring issue additionally | 15:39 |
| seb128 | rsalveti, right, as I commented on your g+ it got deleted by infinity | 15:39 |
| ogra_ | oh ! | 15:39 |
| ogra_ | rsalveti, read more G+ !!! | 15:39 |
| seb128 | rsalveti, to avoid more users bricking their system by installing libc6-amd64 | 15:39 |
| ogra_ | its the new bug report channel ! | 15:39 |
| ogra_ | :P | 15:39 |
| rsalveti | oh, got it | 15:39 |
| rsalveti | lol | 15:39 |
| rsalveti | yeah, I have libc6-amd64 here lol | 15:40 |
| cjwatson | ogra_: I'm supervising android, don't worry about it | 15:40 |
| seb128 | rsalveti, that's fine, just never remove it :p | 15:40 |
| rsalveti | seb128: haha, but autoremove still wants to remove it :-) | 15:41 |
| ogra_ | cjwatson, yeah, we were rather looking for the already published binary | 15:41 |
| cjwatson | just fish it out of the librarian | 15:41 |
| ogra_ | right | 15:41 |
| ogra_ | telling mfrey | 15:41 |
| cjwatson | https://launchpad.net/ubuntu/+source/android/20131120-0225-0ubuntu1/+build/5247268/+files/android-emulator_20131120-0225-0ubuntu1_i386.deb | 15:41 |
| seb128 | rsalveti, yeah, that's what led didrocks to brick his system earlier ;-) | 15:41 |
| xnox | can gcc-4.6-armhf-cross 1.68 source and binaries be simply copied back into trusty? (undelete) they existed in raring. | 17:21 |
| xnox | ? | 17:22 |
| slangasek | didrocks, seb128, infinity, xnox, rsalveti: ok, someone please explain to me how the android package wound up with this dep on libc6-amd64 in the first place? The last version I had here did not have any such dependency | 19:42 |
| seb128 | slangasek, what version was that? | 19:44 |
| slangasek | the one I had here was 20131108-0510-0ubuntu3 | 19:44 |
| slangasek | and had no 64-bit stuff in it | 19:44 |
| seb128 | https://launchpad.net/ubuntu/+source/android/20131120-0225-0ubuntu1 had it | 19:44 |
| slangasek | why do we now have 64-bit stuff in the i386 package? | 19:44 |
| slangasek | I don't think hackish swapping of multilib deps for multiarch ones is the right answer; we shouldn't be winding up with an i386 package with amd64 deps at all | 19:45 |
| seb128 | yeah, I'm not sure about that, you want rsalveti there | 19:45 |
| xnox | slangasek: after infinitys patch or even before infinities patch? i have been cleaning out 64-bit stuff out of the package, but if any 64-bit crept back in, the wrong deps are generated. | 19:45 |
| slangasek | xnox: I'm talking about before infinity's patch... infinity was patching *because* the dep on libc6-amd64 was breaking things horribly | 19:46 |
| xnox | slangasek: should i do a more generic: find . / test with `file` and rm any 64-bit binaries? | 19:46 |
| slangasek | which means the dep on libc6-amd64 already existed | 19:46 |
| xnox | right. | 19:46 |
| slangasek | xnox: well, I guess that would work :) | 19:46 |
| cjwatson | /usr/share/android/emulator/out/host/linux-x86/bin/emulator64-* | 19:47 |
| cjwatson | So we could just not ship those files ... | 19:47 |
| xnox | argh, i was removing those from the build. | 19:47 |
| * slangasek nods | 19:47 | |
| slangasek | I think we should not ship them, until such time as we can sanely build it on amd64 | 19:47 |
| cjwatson | (dpkg -L android-emulator | xargs file | grep 'ELF 64') | 19:47 |
| slangasek | but currently the android build system assumes you have 32bittage available in your build env :P | 19:48 |
| rsalveti | slangasek: yeah, we can remove them | 19:48 |
| rsalveti | I added because I wanted all the published binaries to be available in there | 19:48 |
| rsalveti | but then decided to just focus on the x86 one | 19:48 |
| rsalveti | i386 :-) | 19:48 |
| slangasek | rsalveti: yeah, we were deliberately excluding them before :) | 19:49 |
| rsalveti | slangasek: yup, let me fix that | 19:49 |
| didrocks | slangasek: thanks for excluding them, I learnt why in some way :) | 19:50 |
| slangasek | didrocks: heh, yeah - what actually caused the problem for you, removing libc6-amd64 after installation? | 19:50 |
| rsalveti | yup | 19:51 |
| didrocks | slangasek: right | 19:51 |
| * slangasek nods | 19:51 | |
| didrocks | just the libc6 symlink is pointing to nothing in /lib64 | 19:52 |
| didrocks | I can let you imagine what happens ;) | 19:52 |
| slangasek | yeah, I know exactly what happens, I did that to myself during the sprint ;) | 19:52 |
| slangasek | (unrelated to the emulator) | 19:52 |
| didrocks | heh ;) | 19:52 |
| didrocks | it's funny, chromium is doing something weird | 19:52 |
| slangasek | I never did look to see what had pulled libc6-amd64 in | 19:52 |
| didrocks | one tab after another died | 19:52 |
| didrocks | not sure what they reload | 19:52 |
| rsalveti | slangasek: how can we fix that? | 19:52 |
| slangasek | rsalveti: breakage on libc6-amd64 removal? | 19:53 |
| slangasek | not sure | 19:53 |
| rsalveti | slangasek: yeah | 19:53 |
| slangasek | something for infinity and I to sort out in eglibc, I guess | 19:53 |
| didrocks | infinity told that he has some ideas, but because of dpkg-divert had a bug, he doesn't know how to do that pre-LTS | 19:53 |
| didrocks | (from what I heard) | 19:53 |
| didrocks | precise -> anything would be broken | 19:54 |
| infinity | I have some other hackish ideas. | 19:54 |
| didrocks | hey infinity ;) | 19:54 |
| infinity | So, yeah, this isn't a new bug (and, in fact, this bug is what led to the dpkg-divert bug getting filed and fixed, because we'd hoped to use it to fix the bug, but then we didn't get the fix into precise-release...) | 19:58 |
| infinity | It's unfortunate that we've accidentally inflicted the bug on more people via this dep, though. :/ | 19:58 |
| infinity | I *think* I can sort out a hackish way to avoid the bug, sort of, but it won't be pretty. | 19:59 |
| rsalveti | slangasek: will push a new android package removing the 64 binaries in there | 20:04 |
| === Ursinha is now known as Ursinha-afk | ||
| infinity | rsalveti: Might want something in debian/rules that detects 64-bit binaries and forcefully removes them, in case a new one slips by. | 20:15 |
| rsalveti | infinity: yeah, I'm not removing your seds | 20:16 |
| === Ursinha-afk is now known as Ursinha | ||
| xnox | rsalveti: better to include something that cjwatson posted. find debian/android-emulator | xargs file | grep 'ELF 64' and rm them. | 20:39 |
| xnox | (pseudo code) | 20:39 |
| rsalveti | xnox: yeah, it's just the emulator actually, as we already disabled the opengl libraries | 21:01 |
| rsalveti | xnox: we need to also have a package for amd64 in there, but we first need to fix the android build system to only build it for one arch | 21:01 |
| rsalveti | currently it tries to build for both i386 and amd64 even if you don't have the dependencies around | 21:02 |
| bdmurray | RAOF: are you using sru-review to release uploads? I noticed the package version number wasn't in one of your "Please test proposed package" comments | 22:45 |
| RAOF | bdmurray: I am indeed using sru-review. | 22:45 |
| bdmurray | RAOF: hunh I was looking at this comment - https://bugs.launchpad.net/glipper/+bug/1203888/comments/33 | 22:47 |
| ubot2 | Launchpad bug 1203888 in libdbusmenu (Ubuntu) "appindicator ignores menu entries after having sent the menu to the indicator" [High,Fix committed] | 22:47 |
| RAOF | bdmurray: Oh! *That* one was not done via sru-review, because sru-review can't review syncs from crazy Ayatana PPAs. | 22:49 |
| bdmurray | RAOF: oh, right PPAs makes sense | 22:49 |
| tjaalton | soqt failed to build on armhf, which then blocks visp from building, which is aiui the only missing bit for libav transition? | 23:12 |
| tjaalton | hmm, could be fixed with the new mesa | 23:14 |
| tjaalton | nope | 23:26 |
| infinity | tjaalton: It's always failed on armhf.. | 23:30 |
| infinity | tjaalton: And so has visp. | 23:31 |
| infinity | tjaalton: You may need to improve your britney debugging skills. ;) | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!