/srv/irclogs.ubuntu.com/2013/11/20/#ubuntu-release.txt

didrockstjaalton: but seeding sssd to supported is trying to pull samba4 in main11:12
didrockstjaalton: so, build-dep needs to be investigated :)11:12
didrockstjaalton: btw, as core-dev you can change the seed yourself :)11:13
tjaaltonoh?11:19
tjaaltonmaybe it wants the new samba in main first11:20
tjaaltonif you could promote all of ldb there that should be fulfilled11:20
tjaaltondidrocks: ^11:22
didrockstjaalton: I doubt that it tries to pull "samba4" (see what I pasted in the comment) because samba itself is not in main11:22
didrockstjaalton: the -dev samba dep is in proposed or release pocket?11:22
tjaaltonproposed11:23
didrockstjaalton: ah, maybe that's why, probably, the seed is only computing the mismatch in the release pocket11:23
tjaaltonyeah, would make sense11:23
didrockstjaalton: I think just gives a heads'up once it's in the release pocket and seed it11:23
didrocksthen, the quickest will promote those :)11:24
tjaaltonfixing bug 1250463 should be the key then11:24
ubot2Launchpad bug 1250463 in ldb (Ubuntu) "[MIR] ldb" [Undecided,Triaged] https://launchpad.net/bugs/125046311:24
tjaaltonother rdeps were promoted already11:24
tjaaltonof samba11:24
didrockstjaalton: I guess needs doko to revisit it11:25
tjaaltoncould be11:26
infinitytjaalton: Which bindings are you refering to in the bug?12:08
tjaaltoninfinity: python-ldb12:10
infinitytjaalton: It's in main.12:10
tjaaltonhuh12:10
tjaaltonok12:10
infinitySo, what are we actually trying to solve here? :P12:10
tjaaltonso what's blocking the new samba then?12:10
tjaaltongetting samba out of proposed12:10
tjaaltonunless it's artificially held there due to known bugs?12:11
infinitycomponent mismatches don't block promotions anyway, britney doesn't know about components (sadly).12:11
infinitytjaalton: update_output.txt shows it breaking a... Lot of stuff.12:12
infinitytjaalton: A few of those can go away if I remove samba4 from the archive, but not most of them.12:12
infinitytjaalton: And it might be tied up in the libav transition too.12:13
infinitytjaalton: Yeah, it is.12:13
tjaaltonokay12:13
tjaaltoni don't mind if sssd is stuck in proposed until those are all solved12:14
infinityGood, cause you minding wouldn't have changed anything. :)12:14
infinity(Except perhaps motivate you to help with the libav transition)12:14
tjaaltonsure :)12:14
=== chuck__ is now known as zul
tjaaltoninfinity: so what line should I be looking if sorting the libav rdep rebuilds?13:15
tjaaltoni have update_output.txt open13:15
cjwatsontjaalton: The block that starts "Trying easy from autohinter: samba/2:4.0.10+dfsg-4ubuntu1"13:38
cjwatsonSome of those will be samba, some libav, since they're now intertangled thanks to the server team's enthusiasm :-P13:38
cjwatsonThere'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
cjwatsonogra_: All it takes is some reverse-dependency that touches both stacks13:40
cjwatsonI don't know which one and don't much care13:41
=== exekias_ is now known as exekias
tjaaltoncjwatson: ok, thanks13:41
cjwatsongrr, proposed-migration crashing14:27
cjwatsonwill look as soon as I have spare brain cycles14:27
cjwatsoncopyPackage libelf/0.8.13-4: libelf is not published in Primary Archive for Ubuntu.14:27
cjwatsonActually14:28
cjwatsonWTF happened to trusty14:28
cjwatsonhttps://launchpad.net/ubuntu/+source/man-db -> no trusty14:28
apwcjwatson, seems to be gone14:43
cjwatsonYes, I'm firefighting on #launchpad-ops14:43
cjwatsonSomebody marked it experimental, presumably by accident, but I can find no audit trail right now ...14:44
rsalvetiinfinity: thanks for fixing the android package btw14:45
tjaaltonvisp seems to have been built against libavcodec53 from the old libav, but libavutil52 from the new..14:47
tjaaltonthere might be others like that14:47
marruslIs there a specific release date for 14.04.1 yet?  or is it "about 3.5 months after 14.04"?14:52
cjwatsonnot as yet, we'd need to extrapolate that from the 12.04 schedule I guess14:53
marruslcjwatson, It seems like  it's usually about 3.5 months.  that will do for an answer now.  thanks.14:55
slangasekI don't think there've been enough LTSes to say when it's "usually" been14:57
slangasekIIRC, the interval between 10.04 and 10.04.1 was much shorter14:58
=== alex-abreu|afk is now known as alex-abreu
cjwatsonOK, /ubuntu/trusty recovered, it was a misfire for /charms/trusty15:04
rsalvetiseems the android-emulator package is gone from the archive/mirror15:38
rsalvetiwonder if that is a side effect of the proposed migration crash15:38
ogra_cjwatson, there seems to be a mirroring issue additionally15:39
seb128rsalveti, right, as I commented on your g+ it got deleted by infinity15:39
ogra_oh !15:39
ogra_rsalveti, read more G+ !!!15:39
seb128rsalveti, to avoid more users bricking their system by installing libc6-amd6415:39
ogra_its the new bug report channel !15:39
ogra_:P15:39
rsalvetioh, got it15:39
rsalvetilol15:39
rsalvetiyeah, I have libc6-amd64 here lol15:40
cjwatsonogra_: I'm supervising android, don't worry about it15:40
seb128rsalveti, that's fine, just never remove it :p15:40
rsalvetiseb128: haha, but autoremove still wants to remove it :-)15:41
ogra_cjwatson, yeah, we were rather looking for the already published binary15:41
cjwatsonjust fish it out of the librarian15:41
ogra_right15:41
ogra_telling mfrey15:41
cjwatsonhttps://launchpad.net/ubuntu/+source/android/20131120-0225-0ubuntu1/+build/5247268/+files/android-emulator_20131120-0225-0ubuntu1_i386.deb15:41
seb128rsalveti, yeah, that's what led didrocks to brick his system earlier ;-)15:41
xnoxcan 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
slangasekdidrocks, 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 dependency19:42
seb128slangasek, what version was that?19:44
slangasekthe one I had here was 20131108-0510-0ubuntu319:44
slangasekand had no 64-bit stuff in it19:44
seb128https://launchpad.net/ubuntu/+source/android/20131120-0225-0ubuntu1 had it19:44
slangasekwhy do we now have 64-bit stuff in the i386 package?19:44
slangasekI 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 all19:45
seb128yeah, I'm not sure about that, you want rsalveti there19:45
xnoxslangasek: 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
slangasekxnox: I'm talking about before infinity's patch... infinity was patching *because* the dep on libc6-amd64 was breaking things horribly19:46
xnoxslangasek: should i do a more generic: find . / test with `file` and rm any 64-bit binaries?19:46
slangasekwhich means the dep on libc6-amd64 already existed19:46
xnoxright.19:46
slangasekxnox: well, I guess that would work :)19:46
cjwatson/usr/share/android/emulator/out/host/linux-x86/bin/emulator64-*19:47
cjwatsonSo we could just not ship those files ...19:47
xnoxargh, i was removing those from the build.19:47
* slangasek nods19:47
slangasekI think we should not ship them, until such time as we can sanely build it on amd6419:47
cjwatson(dpkg -L android-emulator | xargs file | grep 'ELF 64')19:47
slangasekbut currently the android build system assumes you have 32bittage available in your build env :P19:48
rsalvetislangasek: yeah, we can remove them19:48
rsalvetiI added because I wanted all the published binaries to be available in there19:48
rsalvetibut then decided to just focus on the x86 one19:48
rsalvetii386 :-)19:48
slangasekrsalveti: yeah, we were deliberately excluding them before :)19:49
rsalvetislangasek: yup, let me fix that19:49
didrocksslangasek: thanks for excluding them, I learnt why in some way :)19:50
slangasekdidrocks: heh, yeah - what actually caused the problem for you, removing libc6-amd64 after installation?19:50
rsalvetiyup19:51
didrocksslangasek: right19:51
* slangasek nods19:51
didrocksjust the libc6 symlink is pointing to nothing in /lib6419:52
didrocksI can let you imagine what happens ;)19:52
slangasekyeah, I know exactly what happens, I did that to myself during the sprint ;)19:52
slangasek(unrelated to the emulator)19:52
didrocksheh ;)19:52
didrocksit's funny, chromium is doing something weird19:52
slangasekI never did look to see what had pulled libc6-amd64 in19:52
didrocksone tab after another died19:52
didrocksnot sure what they reload19:52
rsalvetislangasek: how can we fix that?19:52
slangasekrsalveti: breakage on libc6-amd64 removal?19:53
slangaseknot sure19:53
rsalvetislangasek: yeah19:53
slangaseksomething for infinity and I to sort out in eglibc, I guess19:53
didrocksinfinity told that he has some ideas, but because of dpkg-divert had a bug, he doesn't know how to do that pre-LTS19:53
didrocks(from what I heard)19:53
didrocksprecise -> anything would be broken19:54
infinityI have some other hackish ideas.19:54
didrockshey infinity ;)19:54
infinitySo, 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
infinityIt's unfortunate that we've accidentally inflicted the bug on more people via this dep, though. :/19:58
infinityI *think* I can sort out a hackish way to avoid the bug, sort of, but it won't be pretty.19:59
rsalvetislangasek: will push a new android package removing the 64 binaries in there20:04
=== Ursinha is now known as Ursinha-afk
infinityrsalveti: Might want something in debian/rules that detects 64-bit binaries and forcefully removes them, in case a new one slips by.20:15
rsalvetiinfinity: yeah, I'm not removing your seds20:16
=== Ursinha-afk is now known as Ursinha
xnoxrsalveti: 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
rsalvetixnox: yeah, it's just the emulator actually, as we already disabled the opengl libraries21:01
rsalvetixnox: 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 arch21:01
rsalveticurrently it tries to build for both i386 and amd64 even if you don't have the dependencies around21:02
bdmurrayRAOF: are you using sru-review to release uploads?  I noticed the package version number wasn't in one of your "Please test proposed package" comments22:45
RAOFbdmurray: I am indeed using sru-review.22:45
bdmurrayRAOF: hunh I was looking at this comment - https://bugs.launchpad.net/glipper/+bug/1203888/comments/3322:47
ubot2Launchpad bug 1203888 in libdbusmenu (Ubuntu) "appindicator ignores menu entries after having sent the menu to the indicator" [High,Fix committed]22:47
RAOFbdmurray: Oh! *That* one was not done via sru-review, because sru-review can't review syncs from crazy Ayatana PPAs.22:49
bdmurrayRAOF: oh, right PPAs makes sense22:49
tjaaltonsoqt failed to build on armhf, which then blocks visp from building, which is aiui the only missing bit for libav transition?23:12
tjaaltonhmm, could be fixed with the new mesa23:14
tjaaltonnope23:26
infinitytjaalton: It's always failed on armhf..23:30
infinitytjaalton: And so has visp.23:31
infinitytjaalton: 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!