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