[00:32] <skaet> ScottL,  after reading the backscroll, others have pointed out the issues re: bitrot, etc..  :)   From a logistics point of view, it should be straight forward enough though.
[00:34]  * ScottK wonders if the queuebot fell asleep.
[01:19] <slangasek> ScottK: iterating gnuradio is proving wonderfully tedious :P
[01:20] <ScottK> Glad you're enjoying it ...
[01:20] <ScottK> ;-)
[01:24] <slangasek> I blame C++ for much of this
[01:25] <slangasek> I think the headers are leaking constructor details, leading to library linkages that the consumer test cases really don't care about
[01:42] <ScottK> Was trying to look at nlkt for qwt6 transition and typed nltk by mistake.  Turns out that needs pysupport -> dh_python2.
[03:17] <ScottL> skaet, infinity, cjwatson ScottK : re: ubuntu studio one-year release cycle, we still have to get through 11.10 and 12.04 before we would be ready for such a thing but we now know that it is a possibility, thank you for you input
[03:20] <ScottK> ScottL: You might first consider trying to lightly QA alternate releases and support direct upgrades and see how it goes.  You could even try supporting 11.04 to 12.04 as an experiment.
[04:13] <ScottL> ScottK, thank you for that excellent suggestion :)
[05:56] <slangasek> ScottK: so after all the makefile patching, gnuradio FTBFS because swig generates C++ code without the required includes for ptrdiff_t
[06:07] <slangasek> ah, but swig2.0 does the job
[12:35] <Daviey> Might be of use: http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html
[13:04] <doko_> Daviey, the general suggestion is not quiet correct, a lot of component mismatches are handled by fixing some package to stay in universe
[15:37] <ScottK> Daviey: As an example of doko_'s point, the solution to the kdesvn one is to fix the kdesdk FTBFS on powerpc.
[16:42] <ScottK> cjwatson: Debian has introduced a qwt5 package: http://packages.qa.debian.org/q/qwt5.html instead of all the qwt6 related removals (and there will be more) we could just sync that instead.
[17:30] <slangasek> ScottK: well, gnuradio isn't source-compatible with qwt6 either FWIW :)
[17:30] <slangasek> finally got through the linker / swig errors, now it fails because QwtDoublePoint no longer exists
[17:31] <ScottK> slangasek: So approve the qwt5 FFe and sync it.
[17:31] <ScottK> Then it's all full of win.
[17:31] <slangasek> ok, will look at that shortly
[17:31] <ScottK> Bug 835553
[17:31] <ubot4> Launchpad bug 835553 in ubuntu "FFe: Sync qwt5 5.2.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/835553
[17:32] <ScottK> So far ~3/4 of the packages I've looked at needed porting and most of those were non-trivial.
[17:54] <charlie-tca> Why don't todays images have the latest changes/
[17:54] <ScottK> What changes?
[17:54] <charlie-tca> Ubiquity 2.7.17 is still on Xubuntu Desktop for today, and it needs to be 2.7.18 to allow installing 3rd party software duing the installs
[17:55] <charlie-tca> Trying to resolve bug 653571, which shows fixed-released
[17:55] <ubot4> Launchpad bug 653571 in ubiquity (Ubuntu Oneiric) (and 1 other project) "ubiquity crashed with DBusException in call_blocking() when the option "Install 3rd party software" is checked. (affects: 113) (dups: 60) (heat: 550)" [High,Fix released] https://launchpad.net/bugs/653571
[17:55] <ScottK> charlie-tca: https://launchpad.net/ubuntu/+source/ubiquity/2.7.18 - failed to build.
[17:56] <charlie-tca> Thanks
[18:36] <Daviey> doko_: Yeah, i get that.. i mainly did that page for my needs, and thought it was useful to share.  I was careful to put "consider" raising a MIR.
[18:37] <Daviey> but hey, if it's not useful for you aswell.. then don't use it :)
[18:41] <Daviey> string updated to make it clearer. :/
[18:42] <slangasek> interesting, Oracle reportedly isn't going to be distributing sun-java6 under the DLJ anymore; I wonder if we'll still have it in partner
[18:42] <slangasek> that would make a eucalyptus dependency on sun-java6 even more problematic, if the packages no longer exist at all...
[18:43] <ScottK> Nice.
[18:43] <Daviey> slangasek: The fact that euca currently only seems to work with sun-java6 is a bug.  Debian will care about this aswell.
[18:43] <ScottK> Daviey: I do think it's a good accompaniment to the c-m page.  Perhaps the MIR linking bits could be added to c-m.
[18:44] <slangasek> Daviey: certainly
[18:44] <slangasek> but "care about" != "get a fix for in a timely manner" :)
[18:44] <Daviey> ScottK: That was my hope, but i wasn't able to get the c-m.txt generation source when I needed it.  So decided to JFDI.  Tracking the MIR's i need to chase has been a apin.
[18:44] <Daviey> pain*
[18:45] <slangasek> oh cute, something has caused gnuradio to install everything to /usr/lib64 instead of /usr/lib
[18:45] <slangasek> I swear, this software
[18:45] <Daviey> slangasek: I'm not that hopeful that euca will be resolved in time for Oneiric.  I have been in contact with upstream, and they are /starting/ to get more involved.  However, i'm not expecting it to be stable at release time.
[18:45] <Daviey> I suspect it's going to be a release note issue.
[18:46]  * slangasek nods
[18:47] <Daviey> slangasek: Regarding multiverse depending on partner.. Would that require a manual build, injecting partner into the buildd?
[18:47] <slangasek> Daviey: oh, it requires it at *build*-time?  Yeah, that's a non-starter
[18:48] <slangasek> if it were just a runtime dep, we could (*could*) turn a blind eye
[18:48] <Daviey> Well, i would think jdk would be required for a java build.
[18:48] <slangasek> yes, but it might be able to build with openjdk and only fail at runtime without sun-java
[18:48] <Daviey> Lack of clear policy on this kinda blows my mind TBH. :)
[18:49] <Daviey> slangasek: ack, not tried that TBH.
[18:49] <slangasek> the questions rarely come up... I think the original AA team all had a shared consensus in their heads that hasn't really been propagated anywhere on paper :)  (Or it's on paper, but only on some web page on www.ubuntu.com whose URL I can never remember, not in any AA/developer documentation)
[18:50] <slangasek> cjwatson probably knows the page I'm thinking of, as he's the one who's pointed me to it in the past
[18:53] <Daviey> On a related note, someone was asking about me about ABI stability throughout the supported cycle.  The best response i could give is that ABI compatability is not promised and it's "best judgement of do least harm" by the SRU and security team.
[18:58] <ScottK> Daviey: post-release we (mostly) promise regression free.  So I think an ABI break would be "bad".
[19:00] <Daviey> ScottK: I didn't think we ever promised ABI stability, let alone do significant checks for it? I thought the kernel was the only thing checked, and that was not necessarily a blocker (hence our love for DKMS).
[19:01] <ScottK> Kernel ABI breaks are part of the (mostly).
[19:01] <ScottK> They are pretty unavoidable.
[19:02] <ScottK> I think we do promise no hidden ABI breaks (which is why the package name changes).
[19:04] <slangasek> yes, the SRU team would certainly raise a flag for an ABI-changing update
[19:05] <slangasek> I think we've had to do an ABI-changing openssl security update *once*, and it was a rather large affair
[19:05] <Daviey> slangasek: raise a flag is not quite rejecting based on it, is it?
[19:05] <Daviey> As in, my theory of "best judgement of do least harm" still stands?
[19:05] <slangasek> Daviey: there has to be a darn good reason why we should let something in that breaks the ABI
[19:06] <slangasek> such as needing a fundamental ABI change to fix a security vulnerability
[19:06] <slangasek> anything short of that would almost certainly be rejected
[19:07] <slangasek> and if we do change an ABI for a security vuln, that carries with it a committment to update all the packages to use the new ABI - so library name change, plus rebuilds of all affected packages
[19:07] <Daviey> slangasek: so, the famous - bug 559822 was only a year ago.. Was it ever documented /how/ that slipped through?
[19:07] <ubot4> Launchpad bug 559822 in wxwidgets2.8 (Ubuntu Lucid) (and 3 other projects) "editra is provided by both the editra package and python-wxtools and conflicts (affects: 17) (dups: 2) (heat: 31)" [Undecided,Fix released] https://launchpad.net/bugs/559822
[19:07] <slangasek> hmm, wasn't famous to me
[19:11] <slangasek> oh, haha, gnuradio's lib64 detection regressed because we made /lib64 a real dir
[19:12] <slangasek> Daviey: what is it in bug #559822 that slipped through?  Is it the pgadmin3 breakage ttx mentioned?
[19:12] <ubot4> Launchpad bug 559822 in wxwidgets2.8 (Ubuntu Lucid) (and 3 other projects) "editra is provided by both the editra package and python-wxtools and conflicts (affects: 17) (dups: 2) (heat: 31)" [Undecided,Fix released] https://launchpad.net/bugs/559822
[19:12] <Daviey> slangasek: Yes, believe so.
[19:13] <Daviey> slangasek: according to the SRU wiki page caused, bug 610975
[19:13] <ubot4> Launchpad bug 610975 in pgadmin3 (Debian) (and 24 other projects) "relocation error with latest wxwidgets2.8 (affects: 100) (dups: 17) (heat: 334)" [Unknown,Fix released] https://launchpad.net/bugs/610975
[19:15] <slangasek> what SRU wiki page?
[19:15] <Daviey> https://wiki.ubuntu.com/StableReleaseUpdates#Why .. last example
[19:15] <slangasek> ah
[19:17] <slangasek> I suspect what happened there is that one SRU member was aware that it caused regressions, but this information was buried in the bug log and we have no process for flagging it to the attention of other SRU team members that an SRU has other dependencies that need taking care of before publishing
[19:17] <ScottK> IIRC that's about right.
[19:17] <slangasek> in this case it was apparently impossible to rebuild wxwidgets2.8 without an ABI change due to toolchain updates
[19:18] <slangasek> I don't really see any analysis in the bugs to explain what changed that caused disappearance of a symbol other packages were using, though - that's rather unusual
[19:18] <Daviey> The 'wave a flag' idea kinda falls flat if there is no channel. :)
[19:19] <ScottK> Daviey: There is a channel.  #ubuntu-devel.
[19:19] <slangasek> ah, Debian bug 540060
[19:19] <ubot4> Debian bug 540060 in libwxgtk2.8-0 "error in pgadmin3" [Serious,Open] http://bugs.debian.org/540060
[19:19] <Daviey> slangasek: The reason this became an issue, is that people are spending time/resouces validating / gainign certification for parts of our stack that needs to be re-acheieved on ABI changes.
[19:19] <ScottK> slangasek: Are you going to deal with New for qwt5 too?
[19:20] <Daviey> It was my belief that we could not give promise or warning of ABI changes.
[19:20] <ScottK> That's accurate.
[19:20] <Daviey> wow, my spelling is bad.
[19:20] <ScottK> What we can do is attempt to maintain ABI and fix it when we mess up.
[19:20] <slangasek> well honestly, d.filoni should have blocked the SRU until the regression was fully understood once he became aware of it
[19:20] <slangasek> I don't know if that was discussed in post mortem though
[19:21] <slangasek> ScottK: yessir
[19:21] <ScottK> Thanks.
[19:22] <ScottK> The good news is all the Main qwt stuff is on qwt6, so qwt5 can be in Universe with no problem.
[19:22] <slangasek> Daviey: what parts of the stack are you worried about ABI changes to?
[19:23] <slangasek> ScottK: right, I see the old binaries are already in universe, so all good
[19:24] <slangasek> Daviey: we have a *responsibility* to guard against undeclared ABI changes, and to minimize the ABI changes that happen in -updates/-security; in some cases we'll fall short (as we did in the wxwidgets case), but that's a bug, not an acceptable casualty
[19:25] <slangasek> bah, and the bug came down to a change in binutils' parsing of linker scripts
[19:25] <slangasek> that should have been fixed in wxwidgets2.8 by fixing the linker script :P
[19:25] <Daviey> slangasek: This specific issue that was raised to me was related to virtio drivers, and Windows validation.
[19:26] <slangasek> instead of forcing rebuilds of everything else :/
[19:26] <Daviey> They need to be blessed by Microsoft.
[19:26] <slangasek> Daviey: virtio drivers being kernel drivers, or?
[19:26] <Daviey> slangasek: No, the part provided to the guest.
[19:27] <slangasek> oh. why would any ABIs change there?
[19:28] <slangasek> oop, car done getting serviced, afk :)
[19:28] <Daviey> slangasek: I agree Ubuntu does have a responsibility, but i know I am guilty of not properly checking for ABI changes when i propose SRU updated.  I don't know that the SRU team check deeper, other than visual inspection.
[19:29] <Daviey> slangasek: In the case of a qemu SRU / security update?
[19:29] <Daviey> Anyway!  I hear the pub calling, ta-ta.
[19:30] <ScottK> Sigh.
[19:30] <Daviey> (The reason i raised that it was related, is more down to documented policy not really being avaliable)
[19:30] <slangasek> right, the SRU team doesn't scale to reviewing the changes in that kind of detail - to some degree we have to rely on due diligence from the uploaders and that our SRU verification process works as intended
[19:31] <slangasek> personally, I would be in favor of a rule that no library can be SRUed unless it uses dpkg-gensymbols and bails at build time on a symbol mismatch
[19:31] <Daviey> ScottK: Sigh?
[19:32] <ScottK> I think I accepted kde-l10n-ug into Universe when it needed to go in Main.
[19:32] <Daviey> slangasek: That sir, is something that would probably make people happy.
[19:32] <ScottK> It can get sorted later.
[19:32] <cjwatson> slangasek: is http://www.ubuntu.com/project/about-ubuntu/licensing what you mean?  I'm not sure ...  At some point I borged what I thought were the salient points of that into ubuntu-policy
[19:33] <Daviey> cjwatson: Oo, that is a good page.
[19:33] <ScottK> cjwatson: Did you see we sorted qwt NBS without having to do mass removals or tons of qwt6 ports?
[19:33] <cjwatson> ScottK: I saw, yeah, thanks
[19:34] <ScottK> I'm glad the story has a happy ending.
[19:34] <Daviey> cjwatson: BTW, did bug 817264 come by you at some point?
[19:34] <ubot4> Launchpad bug 817264 in ubuntu-policy (Ubuntu) "Policy should be reviewed and/or merged with latest debian-policy (affects: 1) (heat: 4)" [Undecided,New] https://launchpad.net/bugs/817264
[19:35] <cjwatson> Daviey: no, but it's been on my guilt-list for a while anyway
[19:35] <cjwatson> I'll assign it to myself, and in my CFT ...
[19:35] <ScottK> Oh, but with a new -doc package so we get to deal with binary New again anyway ...
[19:35] <Daviey> cjwatson: Sorry. :(
[19:36] <cjwatson> I'm not worried about the maintainer address thing given common practices in Ubuntu; I think we can add an exception there
[19:36] <ScottK> cjwatson: Actually, since qwt5 hit binary New on i386 only (due to the -doc package), could you review it for binary New so the archive isn't out of sync?
[19:38] <Daviey> cjwatson: I think most developers reference debian-policy rather than ubuntu-policy anyway. :/
[19:39] <cjwatson> ScottK: ok, just a sec
[19:39] <ScottK> cjwatson: Thanks.
[19:39] <cjwatson> Daviey: yeah :-/  although I do see the odd IRC highlight for ubuntu-policy, given that it still has my username in the URL ...
[19:49] <cjwatson> ScottK: accepted
[20:01] <ScottK> cjwatson: Great. Thanks.
[20:14] <slangasek> Daviey: it's something that would make people happy in the long run... in the short term, too few libraries are actually set up that way today
[20:15] <slangasek> cjwatson: yeah, that might be the page... and I see it gives no guidance on multiverse except in the negative :)
[22:16] <doko_> please could somebody accept java-common?
[22:18] <ScottK> doko_: Done.
[22:18] <doko_> thanks!
[22:55] <slangasek> doko_: what changes does java-access-bridge need in order to drop the build-dependency on at-spi (bug #790240)?  Or is java-access-bridge not ported to at-spi2, in which case I think we should drop it out of main?
[22:55] <ubot4> Launchpad bug 790240 in libgail-gnome (Ubuntu Oneiric) (and 9 other projects) "at-spi needs demotion for oneiric (at-spi2-core in main) (affects: 7) (heat: 32)" [Medium,Fix released] https://launchpad.net/bugs/790240
[22:56] <doko_> slangasek, TheMuso did want to address this
[22:56] <slangasek> as in, he wants to port it to at-spi2?
[22:56] <doko_> yes
[22:56] <slangasek> ok
[22:58]  * slangasek documents this in the bug
[23:00] <slangasek> oh how I despise cdbs-simplepatchsys
[23:28] <ScottK> Ohhh.  There it is.