=== bjf is now known as bjf-afk === lbt_ is now known as lbt [10:35] lool, how good are you with d-shlibs ? [10:36] i'd like to add "s/ld-linux3-dev//" to the overrides to fix the graphviz and libshout FTBFS but i'm not sure its the right approach [10:42] I didn't touch that until now but can have a look [10:42] /build/buildd/graphviz-2.20.2/debian/tmp/usr/lib/*.so [10:42] devlibs error: There is no package matching [ld-linux3-dev] and noone provides it, please report bug to d-shlibs maintainer [10:43] thats the error (same in libshout and i bet if i dig i find more that try to use the nonexisting ld-linux3-dev [10:43] ) [10:43] so imho just wiping it from the shlibs should be ok, there is nothing like ld-linux3-dev or similar [10:43] Oh my this package is horid [10:44] grapviz ? [10:44] *graph [10:44] d-shlibs [10:44] oh, heh [10:44] well, its small at least ... only two binaries [10:44] overrides are set in d-devlibdeps [10:46] ah ubiquity uploaded [10:53] ogra: So I'm not sure we really want to hide the problem by changing d-shlibs; it might very well be the thing to do but I'd like to check why we end up wit a NEEDED entry on ld-linux [10:53] ogra: Could you do a manual build of either package and see whether all binaries have it and perhaps check why? [10:53] Could be new toolchain [10:54] ogra: At least in the current graphiv the *.so dont have it [10:54] its a pretty old thing [10:54] i just dug up the same on http://mojo.handhelds.org/frisky-devel [10:54] Sorry I mean in the jaunty graphviz; not sure whether we have a new one in karmic [10:54] Our glibc ends up having /lib/ld-linux3.so found by d-devlibdeps and then it can't figure out how to do the depedencies. The quick fix is to add ld-linux3-dev to the overridelibs and replace it with nothing (i.e., s/ld-linux3-dev//). This problem first showed in in package libgd2 [10:55] thats the changelog entry mojo made back in feisty [10:55] so i doubt its a new toolchain realted thing [10:55] ogra: Well that's exactly the same change as the one you want to do but it doesn't explain why we end up with a NEEDED on ld-linux [10:56] bcause /lib/ld-linux3.so exists and d-devlibdeps adds it [10:56] which is wrong in itself [10:56] ogra: Run objdump -p on random binaries or libs on an installed armel system [10:57] ogra: Under jaunty, I cant find any [10:57] with ld-linux as NEEDED [10:57] If I look at recent karmic rebuilds they have it [10:57] yeah [10:58] i see it on plenty files in /usr/lib [10:58] The question is whether this is a bug or not [10:58] I can tell for instance on libperl.so.5.10 it was added between jaunty and karmic [10:59] so we should consult doko i guess [10:59] Yup that's what I'd d [10:59] do [10:59] will do after my packagekit build is done and uploaded === dyfet` is now known as dyfet === bjf-afk is now known as bjf [15:47] NCommander: There's still a jaunty task on https://bugs.launchpad.net/ubuntu/karmic/+source/lightning-sunbird/+bug/385325 [15:47] Launchpad bug 385325 in thunderbird "[armel] thunderbird-bin crashed with SIGSEGVI" [Medium,Confirmed] [15:48] NCommander: Please push a fixed TB to $ppa, either with backported fix or a new upstream [15:50] lool, sure, but its very low on my priorities list ATM, I likely won't get to it until next week [15:52] NCommander: I'm a bit worried that so many things are just falling off the radar instead of being fixed on the spot [15:52] It's not like it would be a very long job to prepare a backport would it? [15:54] lool, I was shot down on doing a backprot [15:54] lool, asac insisted that it would be fixed via a new upstream release via security [15:54] * NCommander had a backport prepared [15:56] Hmm [15:56] I'll check with asac === easy4_ is now known as easy4 === bjf is now known as bjf-afk === easy4_ is now known as easy4 === cbrake is now known as cbrake_away