[00:00] <slangasek> oh wow, libedit is using dh_movefiles still
[00:00] <slangasek> so fixing the build failure without multiarching it is seriously non-trivial
[00:00] <slangasek> anyone object to me biting the bullet and just switching it over, knowing that there'll be ftbfs revdeps (php5 again, maybe others)?
[02:37] <ScottK> slangasek: 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.
[03:52] <slangasek> fair enough
[03:55] <slangasek> currently 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 :P
[06:11] <slangasek> huh.  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)
=== seb128_ is now known as seb128
[13:34]  * 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 times
[13:35] <ogra_> i wonder if anyone has an idea to work around it, i dont want my installer to scan all tarballs on a device
[13:35] <ogra_> s/installed/installer/
[13:36] <ogra_> cjwatson, is there some way to guess the final tarball name in advance ?
[13:37] <cjwatson> sorry, I don't really know what tarball you mean
[13:37] <cjwatson> not familiar with the arm initramfs stuff
[13:37] <ogra_> the rootfs ... in trhe ac100 case i create a tarball
[13:37] <cjwatson> I'd have to trace through the code just like you
[13:38] <ogra_> the installer is an initrd script unpacking it to the target
[13:38] <ogra_> hmm, k
[17:02] <cjwatson> Could somebody process python-ecore through binary NEW, please?  FFe bug 828004
[17:02] <ubot4> Launchpad 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/828004
[17:20] <slangasek> jjohansen: done
[17:20] <slangasek> eh
[17:20] <slangasek> cjwatson: done
[17:21] <cjwatson> great, thanks
[17:21] <cjwatson> now I just need to fix the python-elementary build failure and that NBS stack is GONE
[17:21] <slangasek> woot
[17:41] <Laney> is anyone looking at the libav nbs?
[17:42] <micahg> Laney: fabrice_sp was working on it, but that seems to have stalled
[17:43]  * Laney pings siretart
[18:57] <micahg> slangasek: would a transition tracker instance for ia32-libs help so we know what we're up against?
[19:39] <slangasek> micahg: 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 uses
[19:41] <micahg> slangasek: ah, only ~45 binaries and ~20 sources
[19:41] <slangasek> hmm?
[19:41] <slangasek> that shouldn't be the count of packages depending on ia32-libs
[19:41] <micahg> slangasek: http://paste.ubuntu.com/668542/
[19:42] <slangasek> oh, lib32gcc1 is a false positive
[19:42] <slangasek> ia32-libs only owns that binary package on ia64
[19:42] <slangasek> ...which we no longer build for
[19:42] <micahg> ah, ok
[19:43] <slangasek> also, this list is somewhat incomplete because it doesn't encompass partner :)
[19:44]  * micahg should fix that later...
[19:48] <slangasek> micahg: 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:49] <slangasek> this should cause apt to install nspluginwrapper from the "preferred" arch (amd64), plus the i386 nspluginviewer and flashplugin
[19:49] <micahg> slangasek: ok, do we gain anything over the current implementation though?  also, i386 doesn't need it, so we're forcing an unneeded dependency
[19:50] <slangasek> it ensures we actually get nspluginwrapper installed where we *do* need it, since currently nothing else ensures that on amd64
[19:50] <slangasek> (pitti already ran into this problem yesterday when testing)
[19:50] <micahg> slangasek: flashplugin-installer:amd64 should :)
[19:51] <slangasek> I thought you wanted to get rid of that package?
[19:51] <slangasek> also, 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:52] <micahg> slangasek: the only reason to get rid of it is if we can get rid of the installer entirely
[19:52] <micahg> which we can't do at present
[19:53] <slangasek> if we moved the nspluginwrapper dep to the adobe-flashplugin package in partner, couldn't we then?
[19:53] <micahg> but I like the i386 in a container argument :)
[19:53] <micahg> slangasek: yes, but we can't do that :)
[19:53] <slangasek> hmm, can't we?
[19:53] <slangasek> not us directly, but
[19:54] <slangasek> so an amd64 flashplugin-installer package would have to have some other i386-only package to attach the library dependencies to
[19:55] <slangasek> could be done, but just using nspluginwrapper everywhere might be simpler