[00:08] <cjwatson> ah.  damn it.  mplayer doesn't work if the header files in the source tree are from a different libav* ABI than the system libraries you're compiling against - it ends up with mismatched structure sizes and everything goes to pot
[00:08] <cjwatson> that is very nasty
[00:48] <cjwatson> siretart: so, the result of all that - never mind.  FFe sent requesting permission to sync from experimental.
[07:00] <siretart> cjwatson: yes, the only other option would have been to link against the internal copy of libav*, but the package from experimental is IMO clearly the better option for oneiric
[07:56] <cjwatson> siretart: yeah, I don't feel good about introducing more duplication
[08:14] <dupondje> https://launchpad.net/ubuntu/+source/libdispatch/0~svn197-3
[08:14] <dupondje> could somebody retry the build ?
[08:14] <dupondje> should be fixed now (just tested in pbuilder)
[08:25] <debfx> dupondje: done
[08:25] <dupondje> thx
[08:28] <dupondje> and it build :D
[08:33] <dupondje> wtf, the armel build queue is 2 weeks ? :p
[08:33] <ogra_> archive rebuild in progress
[08:34] <dupondje> oh ok :)
[08:36] <infinity> cjwatson: Acked your FFe, BTW.  As did ScottK.  You should be good to go to sync, unless you want another AA to do it.
[08:39] <cjwatson> thanks.  that's OK, I'll take care of it
[09:40] <sgnb> infinity: http://glondu.net/tmp/ocaml-arm-recompilation.txt
[09:40] <infinity> sgnb: My hero.  I'll slam group 3 at the archive tomorrow, after I get some sleep. :)
[09:42] <cjwatson> https://launchpad.net/ubuntu/+source/openscenegraph/3.0.0-2ubuntu1/+build/2636062 ugh, that kind of build result makes me sad
[09:42]  * cjwatson is rather tempted to remove all the libav reverse-deps on armel that have GL porting problems
[09:43] <cjwatson> on the basis that seriously who's using them anyway
[09:44] <tumbleweed> there's a whole slew of science packages with that problem too
[09:45] <ogra_> cjwatson, thhey would most likely need proting to GLES for hw accel, but there is meas for GL
[09:45] <ogra_> *mesa
[09:46] <cjwatson> yeah, but is anyone going to do it?
[09:46] <cjwatson> or is there a porting guide?
[09:46] <cjwatson> also if somebody really masochistic wants to fix salome (or declare that it should be removed), that'd be great
[09:46] <cjwatson> have a look at its Debian bug page for great justice
[09:46] <ogra_> well, thats linaro realm mostly, their multimedia teams work with upstreams to fix it usually
[09:47] <cjwatson> ogra_: yeah, 16-hour builds that are going to involve serious effort and guesswork aren't high on my list to sort out
[09:47] <cjwatson> but cleaning up NBS is
[09:47] <bdrung> cjwatson: i found two bugs of the new syncpackage way. where should i report it?
[09:47] <cjwatson> bdrung: are they bugs in the client or the server?
[09:47] <ogra_> well, drop the dep and lest see about the fallout
[09:47] <ogra_> its not like release is tomorrow ...
[09:48] <bdrung> cjwatson: probably server. 1. wrong uploader: https://launchpad.net/ubuntu/+source/mozilla-devscripts/0.28 2. lp bug not closed: bug #829493
[09:48] <cjwatson> I'd rather just remove the unbuildable binaries and have them continue to show up as build failures.  There is precedent for doing that around beta time
[09:48] <ogra_> if people scream about something missing we can still fix
[09:48] <bdrung> cjwatson: 3. newlines seems to be wrong in changelog on https://launchpad.net/ubuntu/+source/mozilla-devscripts/0.28
[09:49] <infinity> cjwatson: I'm happy with the old binary cruft being tossed.  If and when we get various ducks in a row about GL/GLES on ARM, people can fix it all.  If it doesn't happen before release, at least there's no cruft.
[09:49] <cjwatson> bdrung: I think 1 may be deliberate to some extent, as it's copying the Debian publication record, although it'd be nice if the syncer were shown somewhere too.  It might be tied into bug 827608 and/or bug 827555
[09:50] <cjwatson> bdrung: 2 is a client bug, syncpackage needs to close it; bug on ubuntu-dev-tools and assign to me, please?
[09:50] <cjwatson> bdrung: 3 is bug 827528
[09:50] <cjwatson> bdrung: all the server-side bugs live at https://bugs.launchpad.net/launchpad/+bugs?field.tag=derivation
[09:51] <tumbleweed> cjwatson: if syncpackage needs to close the bugs, that's another potential problem with people using +localepackagediffs
[09:51] <cjwatson> bdrung: 2> (for now, just close it manually)
[09:51] <cjwatson> tumbleweed: people need to not use +localpackagediffs for Ubuntu
[09:51] <tumbleweed> indeed
[09:51] <bdrung> cjwatson: couldn't be 2 done by LP?
[09:51] <cjwatson> I'm simply not interested in making that work
[09:51] <tumbleweed> let me write that bug I was going to, complaining about it
[09:52] <Laney> syncpackage has -b xxxx that you could pass manually for now?
[09:52] <cjwatson> bdrung: I don't think it would fit well into the API.  the API already has a way to close bugs, it doesn't make sense to bolt another one onto the side of the copy for the sake of Ubuntu process
[09:52] <cjwatson> Laney: it doesn't honour that for the API copy case yet.  that's the bug
[09:52] <infinity> cjwatson: To be fair, newlines are incorrect for non-sync uploads too, they're just differently incorrect. :P
[09:53] <cjwatson> infinity: yeah, but they're wrong in the gina import in this case
[09:53] <Laney> yeah, just saying that there's a non-completely-manual way to do it (and that this code could be wired together with the native sync stuff)
[09:53] <cjwatson> you can see the same wrongness at https://launchpad.net/debian/+source/mozilla-devscripts/0.28
[09:53] <cjwatson> Laney: you'll have to provide -b anyway - it probably can't magically figure out the right bug
[09:53] <cjwatson> but yeah, need to fix that
[09:54] <infinity> cjwatson: Yeah, I saw the extra newline there.  And yet, that still looks nicer than the missing newline on https://launchpad.net/ubuntu/+source/telepathy-glib/0.15.5-1ubuntu1 ;)
[09:54] <tumbleweed> to close the bugs, we have to pull all the intermediate dscs (or a full source package to read debian/changelog) :/
[09:54] <cjwatson> well, that's true
[09:54] <cjwatson> hmm
[09:54] <Laney> can you ask LP for the changes that were in the Debian changesfiles?
[09:54] <cjwatson> I suppose that does kind of argue for an extra parameter to the API, although it won't help much until bug 827576 is fixed
[09:55] <cjwatson> I don't think it has changesfiles for Debian imports
[09:55]  * cjwatson goes out
[09:58] <tumbleweed> I suppose we could pull a changelog from PTS / changelogs.debian.net, but that's ugly (and potentially out of date)
[09:59] <infinity> And not canonical, by any stretch.
[09:59] <tumbleweed> or secure
[09:59] <infinity> Though it does irk me that https://launchpad.net/ubuntu/+source/telepathy-glib/+changelog isn't actually a full changelog.
[09:59] <Laney> yes, I said that on ^ bug
[09:59] <tumbleweed> yeah it's a pain
[09:59] <infinity> But rather a log of uploads that were published in soyuz.
[10:00] <Laney> don't knwo if it will get completely fixed, the best you'll get is a concatenation of the changesfiles changes that went into debian I reckon
[10:00] <Laney> which may still miss some
[10:01] <tumbleweed> Laney: does launchpda get those changes files? I assumed it just looked for new versions when it mirrored
[10:02] <Laney> maybe it does. I thought it got that data from the changesfiles, but perhaps not :-)
[10:03] <Laney> anyway, it's not like people are as universally conscientious with using -v as they could be when they upload to ubuntu
[10:04] <tumbleweed> sure, but tools should get it right
[10:04] <infinity> Or make a valiant effot, anyway.
[10:04] <infinity> Some of this stuff can never be right, just "slightly less wrong".
[10:04] <Laney> indeed
[10:05] <Laney> hence the bug, of course
[10:05] <tumbleweed> yay, +localpackagediffs generated a diff for me and it only took half an hour to do so :/
[10:05]  * infinity notices that it's 4am, and decides to sleep.
[10:30] <htorque> maybe someone here can help me: i found a process that consumes more and more memory over time, how would i use valgrind to add something useful to a bug report? just call it once then close it or let it run for a while?
[12:19] <kennydude> Hi, what do I do once a branch has been marked as "Needs Fixing"?
[12:30] <tkamppeter> OdyX, ping
[15:14] <ScottK> siretart: Do you have any time to help out with libav porting issues?  kd3b needs help (neither upstream, nor Debian have done the port).  If you add libqtwebkit-dev to build-depends and then try to build the current package you'll see the issues.
[15:14] <ScottK> kd3b/k3b
[16:02] <hyperair> can a core-dev please look into sponsoring bug #823937 please?
[16:04] <shadeslayer> slangasek: multiarch ping
[17:20] <slangasek> shadeslayer: pong
[17:21] <shadeslayer> slangasek: hi!
[17:21] <shadeslayer> one sec
[17:22] <shadeslayer> slangasek: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2697477/+files/buildlog_ubuntu-oneiric-i386.kalzium_4%3A4.7.0-0ubuntu2_FAILEDTOBUILD.txt.gz >> t
[17:23] <shadeslayer> we have : make[4]: *** No rule to make target `/usr/lib/libQtOpenGL.so', needed by `lib/libcompoundviewer.so.4.7.0'.  Stop.
[17:23] <slangasek> right
[17:23] <shadeslayer> because that file is now installed to /usr/lib/arch/
[17:23] <shadeslayer> could you guide me as to how to fix this issue?
[17:24] <slangasek> so the question is, what has hard-coded the path to /usr/lib/libQtOpenGL.so?  Looking at the build-deps, it might be kde-sc-dev-latest or kdelibs5-dev; or it could be in the kalzium source itself
[17:24] <slangasek> I'm not an expert at cmake-based builds, so the most guidance I can offer is "use grep -r a lot"
[17:26] <shadeslayer> its avogadro :)
[17:26] <shadeslayer> more specifically /usr/lib/avogadro/1_0/AvogadroLibraryDeps.cmake
[17:26] <slangasek> ok
[17:27] <slangasek> try a no-change rebuild of avogadro, maybe that's enough to fix it?
[17:28] <shadeslayer> alright, will try
[17:29] <debfx> slangasek: that might be enough to fix it, but I'd rather not have to rebuild cmake-using libraries whenever some other library is converted for multiarch
[17:29] <debfx> any idea how to properly fix this in cmake?
[17:30] <slangasek> debfx: sure - then those cmake-violating libraries need to stop hard-coding paths in the first place, since this has never been guaranteed by the system.  If this is a general cmake feature, can cmake be changed to spit out -L$path -lQtOpenGL instead?
[17:31] <slangasek> actually, in the shared library case it would be better if it would just not spit anything out at all
[17:31] <slangasek> since with glibc, all it does is make the system more brittle
[18:04] <debfx> slangasek: so it's "just" a question of how to implement that :)
[19:05] <ScottK> doko: Are you going to sync trousers or should I edit the FTBFS bug to be a sync request?
[22:31] <lamont> SpamapS: apport in postfix is annoyig
[22:31] <lamont> SpamapS: since it forks the package (debian has no such beast)
[22:32] <lamont> SpamapS: I would  welcome a solution to that situation