slangasekoh wow, libedit is using dh_movefiles still00:00
slangasekso fixing the build failure without multiarching it is seriously non-trivial00:00
slangasekanyone object to me biting the bullet and just switching it over, knowing that there'll be ftbfs revdeps (php5 again, maybe others)?00:00
ScottKslangasek: I don't object to you doing it, but I think you ought to make a tracking bug for all the affected packages so the work status is documented.02:37
slangasekfair enough03:52
slangasekcurrently holding off on syncing libedit from Debian until I can at least understand why the updated libedit causes php5 build to fail while trying to detect libpcre :P03:55
slangasekhuh.  so improbably, php actually detects libedit just fine w/o modification (once I account for $DEB_HOST_MULTIARCH not having been in my environment, sigh)06:11
=== seb128_ is now known as seb128
* ogra_ looks for some livecd-rootfs help ... infinity convinced me to roll my boot-img file from live-build instead of doing it in antimony, my installed needs the md5 of the rootfs tarball in the initrd, that results in this code snippet: http://paste.ubuntu.com/668211/13:34
ogra_now my installer uses the filename too from the md5sum file ... and indeed during the build process the tarball gets renamed several times13:34
ogra_i wonder if anyone has an idea to work around it, i dont want my installer to scan all tarballs on a device13:35
ogra_cjwatson, is there some way to guess the final tarball name in advance ?13:36
cjwatsonsorry, I don't really know what tarball you mean13:37
cjwatsonnot familiar with the arm initramfs stuff13:37
ogra_the rootfs ... in trhe ac100 case i create a tarball13:37
cjwatsonI'd have to trace through the code just like you13:37
ogra_the installer is an initrd script unpacking it to the target13:38
ogra_hmm, k13:38
cjwatsonCould somebody process python-ecore through binary NEW, please?  FFe bug 82800417:02
ubot4Launchpad bug 828004 in python-evas (Ubuntu) (and 4 other projects) "FFe: Upgrade Python EFL bindings to 0.7.3 (affects: 1) (heat: 8)" [Wishlist,Fix released] https://launchpad.net/bugs/82800417:02
slangasekjjohansen: done17:20
slangasekcjwatson: done17:20
cjwatsongreat, thanks17:21
cjwatsonnow I just need to fix the python-elementary build failure and that NBS stack is GONE17:21
Laneyis anyone looking at the libav nbs?17:41
micahgLaney: fabrice_sp was working on it, but that seems to have stalled17:42
* Laney pings siretart17:43
micahgslangasek: would a transition tracker instance for ia32-libs help so we know what we're up against?18:57
slangasekmicahg: I'm doubtful that it would... there are really only a handful of packages left in the ubuntu + partner archives that depend on it, and each has to be inspected to figure out what libraries it uses19:39
micahgslangasek: ah, only ~45 binaries and ~20 sources19:41
slangasekthat shouldn't be the count of packages depending on ia32-libs19:41
micahgslangasek: http://paste.ubuntu.com/668542/19:41
slangasekoh, lib32gcc1 is a false positive19:42
slangasekia32-libs only owns that binary package on ia6419:42
slangasek...which we no longer build for19:42
micahgah, ok19:42
slangasekalso, this list is somewhat incomplete because it doesn't encompass partner :)19:43
* micahg should fix that later...19:44
slangasekmicahg: so to ensure flashplugin pulls in nspluginwrapper, I think the right solution is to make nspluginwrapper M-A: foreign and make flashplugin-installer depend on it unconditionally (i.e., on i386)19:48
slangasekthis should cause apt to install nspluginwrapper from the "preferred" arch (amd64), plus the i386 nspluginviewer and flashplugin19:49
micahgslangasek: ok, do we gain anything over the current implementation though?  also, i386 doesn't need it, so we're forcing an unneeded dependency19:49
slangasekit ensures we actually get nspluginwrapper installed where we *do* need it, since currently nothing else ensures that on amd6419:50
slangasek(pitti already ran into this problem yesterday when testing)19:50
micahgslangasek: flashplugin-installer:amd64 should :)19:50
slangasekI thought you wanted to get rid of that package?19:51
slangasekalso, even on i386 it's useful to have flashplugin in a container process... which firefox handles for us, but I think other browsers don't?19:51
micahgslangasek: the only reason to get rid of it is if we can get rid of the installer entirely19:52
micahgwhich we can't do at present19:52
slangasekif we moved the nspluginwrapper dep to the adobe-flashplugin package in partner, couldn't we then?19:53
micahgbut I like the i386 in a container argument :)19:53
micahgslangasek: yes, but we can't do that :)19:53
slangasekhmm, can't we?19:53
slangaseknot us directly, but19:53
slangasekso an amd64 flashplugin-installer package would have to have some other i386-only package to attach the library dependencies to19:54
slangasekcould be done, but just using nspluginwrapper everywhere might be simpler19:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!