[11:12] <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:13] <didrocks> tjaalton: btw, as core-dev you can change the seed yourself :)
[11:19] <tjaalton> oh?
[11:20] <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:22] <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:23] <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:24] <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:25] <didrocks> tjaalton: I guess needs doko to revisit it
[11:26] <tjaalton> could be
[12:08] <infinity> tjaalton: Which bindings are you refering to in the bug?
[12:10] <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:11] <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:12] <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:13] <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:14] <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 :)
[13:15] <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:38] <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:39] <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:40] <cjwatson> ogra_: All it takes is some reverse-dependency that touches both stacks
[13:41] <cjwatson> I don't know which one and don't much care
[13:41] <tjaalton> cjwatson: ok, thanks
[14:27] <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:28] <cjwatson> Actually
[14:28] <cjwatson> WTF happened to trusty
[14:28] <cjwatson> https://launchpad.net/ubuntu/+source/man-db -> no trusty
[14:43] <apw> cjwatson, seems to be gone
[14:43] <cjwatson> Yes, I'm firefighting on #launchpad-ops
[14:44] <cjwatson> Somebody marked it experimental, presumably by accident, but I can find no audit trail right now ...
[14:45] <rsalveti> infinity: thanks for fixing the android package btw
[14:47] <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:52] <marrusl> Is there a specific release date for 14.04.1 yet?  or is it "about 3.5 months after 14.04"?
[14:53] <cjwatson> not as yet, we'd need to extrapolate that from the 12.04 schedule I guess
[14:55] <marrusl> cjwatson, It seems like  it's usually about 3.5 months.  that will do for an answer now.  thanks.
[14:57] <slangasek> I don't think there've been enough LTSes to say when it's "usually" been
[14:58] <slangasek> IIRC, the interval between 10.04 and 10.04.1 was much shorter
[15:04] <cjwatson> OK, /ubuntu/trusty recovered, it was a misfire for /charms/trusty
[15:38] <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:39] <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:40] <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:41] <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 ;-)
[17:21] <xnox> can gcc-4.6-armhf-cross 1.68 source and binaries be simply copied back into trusty? (undelete) they existed in raring.
[17:22] <xnox> ?
[19:42] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <slangasek> rsalveti: yeah, we were deliberately excluding them before :)
[19:49] <rsalveti> slangasek: yup, let me fix that
[19:50] <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:51] <rsalveti> yup
[19:51] <didrocks> slangasek: right
[19:51]  * slangasek nods
[19:52] <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:53] <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:54] <didrocks> precise -> anything would be broken
[19:54] <infinity> I have some other hackish ideas.
[19:54] <didrocks> hey infinity ;)
[19:58] <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:59] <infinity> I *think* I can sort out a hackish way to avoid the bug, sort of, but it won't be pretty.
[20:04] <rsalveti> slangasek: will push a new android package removing the 64 binaries in there
[20:15] <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:16] <rsalveti> infinity: yeah, I'm not removing your seds
[20:39] <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)
[21:01] <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:02] <rsalveti> currently it tries to build for both i386 and amd64 even if you don't have the dependencies around
[22:45] <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:47] <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:49] <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
[23:12] <tjaalton> soqt failed to build on armhf, which then blocks visp from building, which is aiui the only missing bit for libav transition?
[23:14] <tjaalton> hmm, could be fixed with the new mesa
[23:26] <tjaalton> nope
[23:30] <infinity> tjaalton: It's always failed on armhf..
[23:31] <infinity> tjaalton: And so has visp.
[23:31] <infinity> tjaalton: You may need to improve your britney debugging skills. ;)