| 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)? | 00:00 |
| 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. | 02:37 |
| slangasek | fair enough | 03:52 |
| 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 | 03:55 |
| 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) | 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 times | 13:34 |
| 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:35 |
| ogra_ | cjwatson, is there some way to guess the final tarball name in advance ? | 13:36 |
| 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:37 |
| ogra_ | the installer is an initrd script unpacking it to the target | 13:38 |
| ogra_ | hmm, k | 13:38 |
| 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:02 |
| slangasek | jjohansen: done | 17:20 |
| slangasek | eh | 17:20 |
| slangasek | cjwatson: done | 17:20 |
| 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:21 |
| Laney | is anyone looking at the libav nbs? | 17:41 |
| micahg | Laney: fabrice_sp was working on it, but that seems to have stalled | 17:42 |
| * Laney pings siretart | 17:43 | |
| micahg | slangasek: would a transition tracker instance for ia32-libs help so we know what we're up against? | 18:57 |
| 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:39 |
| 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:41 |
| 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:42 |
| slangasek | also, this list is somewhat incomplete because it doesn't encompass partner :) | 19:43 |
| * micahg should fix that later... | 19:44 | |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| slangasek | so an amd64 flashplugin-installer package would have to have some other i386-only package to attach the library dependencies to | 19:54 |
| slangasek | could be done, but just using nspluginwrapper everywhere might be simpler | 19:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!