=== medberry is now known as med_out
[04:52] <micahg> could I please get someone to merge https://code.launchpad.net/~micahg/+junk/transition-tracker into the transition tracker?  It adds a tracker to get rid of wxwidgets2.6
[08:34] <cjwatson> I've merged micahg's transition tracker branch above
[09:22] <Laney> i should merge ben from upstream at some point
[09:22] <Laney> think mehdi made some improvements
[10:32] <jamespage> doko__, skaet, component mismatches now looking much better
[10:32] <jamespage> doko__, I've raised and documented MIR requirements for junit4 + qdox and deps (for fop 1.0 once I land it) in bug 876413 and bug 876413
[10:32] <ubot4> Launchpad bug 876413 in xmlunit (Ubuntu) (and 15 other projects) "[MIR] xmlunit (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/876413
[10:33] <jamespage> sorry - bug 877146
[10:33] <ubot4> Launchpad bug 877146 in testng (Ubuntu) (and 3 other projects) "[MIR] junit4 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/877146
[10:34] <doko__> jamespage, nice. and the -perl stuf will be gone next
[10:35] <jamespage> doko__, want me to look at the jython deps?
[10:35] <jamespage> I need to look at the new ones for mysql-connector as well
[10:36] <doko__> jamespage, sure, would be nice
[10:36] <jamespage> doko__, well I seem to be on a MIR run ATM so np
[10:39] <doko__> libmodule-build-perl
[10:39] <doko__> Depends: perl, libcpan-meta-perl (>= 2.110420), libextutils-cbuilder-perl (>= 0.2700) | perl (>= 5.11.2), libextutils-parsexs-perl (>= 2.210000) | perl (>= 5.11.2),
[10:40] <doko__> o libextutils-cbuilder-perl: libextutils-cbuilder-perl
[10:40] <doko__>    [Reverse-Depends: libmodule-build-perl]
[10:40] <doko__>  o libextutils-parsexs-perl: libextutils-parsexs-perl
[10:40] <doko__>    [Reverse-Depends: libmodule-build-perl]
[10:40] <doko__> cjwatson, ^^^ why do these show up now, the package didn't change from oneiric?
[10:47] <cjwatson> don't know, chase through germinate output?
[10:47] <cjwatson> perhaps something uninstallable on some architectures
[10:48] <cjwatson> ah, it's just armhf
[10:48] <cjwatson> let me take that out of c-m for now if it's being confusing
[10:49] <cjwatson> doko__: better now?
[10:52] <doko__> cjwatson, yes, thanks!
[11:25] <cjwatson> doko__: re -Werror=format-security, I wonder if we should continue to put it in the output of dpkg-buildflags but just not export it into the dpkg-buildpackage environment by default
[11:26] <cjwatson> I hadn't fully got my head around that distinction when we last talked about this
[11:28] <doko__> so we'll only catch errors catched by debian?
[11:29] <cjwatson> right
[11:29] <cjwatson> I don't know if it's the right thing to do, that's why I'm wondering :)
[11:30] <cjwatson> our intention in continuing to export dpkg-buildflags output by default was to generally keep things at at least the state they were in in oneiric
[11:31] <cjwatson> there is an argument that in order to fulfil that we could export only those flags that were exported in oneiric
[11:31] <doko__> it sounds a bit ugly, I would like to keep it the same for dpkg-buildflags and the environment. maybe we can revisit this when we know how much fails?
[11:31] <doko__> I see see some new ftbfs in main
[11:31] <doko__> but not that many
=== doko__ is now known as doko
[11:34] <cjwatson> http://paste.ubuntu.com/713099/ - diff between exported flags
[11:35] <cjwatson> I appreciate that the security team would love it to have all the hardening flags enabled by default
[11:35] <cjwatson> but we'll see whether exporting them from dpkg-buildpackage is a bit much
[11:36] <cjwatson> that would affect third-party packages too
[11:38] <doko> the only problematic one is -Werror=format-security. can we live with this one until we have the first test rebuild?
[11:39] <cjwatson> yep
[11:56] <cjwatson> https://launchpadlibrarian.net/83181749/buildlog_ubuntu-precise-amd64.ziproxy_3.1.3-1build1_FAILEDTOBUILD.txt.gz I don't like the look of this
[11:57] <cjwatson> ah, perl/amd64 built a bit quicker than perl/i386
[11:57]  * cjwatson gives a load of stuff back then
[12:25] <jdstrand> cjwatson, doko: so, I'm not the one to talk to about this (please talk to sbeattie), but a security feature we have over other distribtuions (that is in marketing materials iirc correctly) is that our default compiler will build 3rd party apps with hardening options
[12:26] <jdstrand> cjwatson, doko: that is not something we would want to lose I don't think. That said, I am not the one to discuss this with-- sbeattie has taken over this work from kees
[12:28] <doko> jdstrand, this is no regression within ubuntu, just extra stuff from debian.
[12:28] <jdstrand> ah
[12:29] <jdstrand> well, I know that Debian is starting to take up kees' work, but in a different manner. I'd rather not comment further because I would be approaching speculation :)
[12:29] <jdstrand> and I'm sure you know *way* more about it than I :)
[12:53] <cjwatson> jdstrand: "lose" - this has only been in Ubuntu for less than five days
[12:54] <cjwatson> in the particular form we're talking about
[12:54] <jdstrand> ack-- I just saw that and got panicky for a moment. I apologize (hardening options are understandably a big deal for our team)
[13:02] <cjwatson> understood, I certainly don't mean to regress from what's in oneiric
[13:02] <cjwatson> that would be (a) bad and (b) unnecessary :)
[15:49] <jamespage> doko, I think we can probably drop jython from main
[15:51] <doko> jamespage, your call, I'm fine with it, if it's just optional features.
[15:52] <jamespage> doko: well its used by two packages optionally - one of which already has it disabled because its broken
[15:52] <jamespage> (but its still kept the dep)
[16:04] <jamespage> doko: OK - going to go with dropping the last remaining optional use of jython
[16:05] <jamespage> can't find any reverse deps that use it and jython
[16:09] <jamespage> doko: MIR bug 878186 is ready for review if you have time
[16:09] <ubot4> Launchpad bug 878186 in libslf4j-java (Ubuntu) (and 1 other project) "[MIR] libslf4j-java (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/878186
[16:10] <jamespage> managed to remove one extra dependency that was not required
[16:15]  * micahg wonders why his wxwidgets tracker is failing...
[16:17] <Laney> no semicolon after title?
[16:19] <Laney> we'll see, pushed
[16:22] <micahg> Laney: ah, probably it, thanks :)
[16:22] <micahg> Laney: is there a notes field?  I added the Debian wiki link in the title since I wasn't sure
[16:22] <Laney> not that i know of
[16:22] <Laney> we should get some kind of index
[16:37] <doko> jamespage, thanks, promoted
[16:37] <jamespage> doko: thanks
=== med_out is now known as med
=== med is now known as medberry
[18:44] <scott-work> cjwatson: we discuss with infinity about moving ubuntu studio to a live dvd weeks ago and you suggested talking to the "cd image team", is there a preferred way to contact them?
[18:45] <infinity> scott-work: We have no formal team contact, but you know most of us.
[18:45] <infinity> scott-work: https://launchpad.net/~ubuntu-cdimage/+members
[19:04] <scott-work> infinity, awesome!  thank you :)
[20:13] <scott-work> i'm not sure this is the proper forum for this question, but please point me in the right direction and i'll ask it there:
[20:13] <scott-work> as ubuntu studio project lead i want to get permission to push studio packages to the repositories
[20:13] <scott-work> https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Developers_.28from_delegated_teams.29
[20:14] <scott-work> should i follow the 'per package' route for permission or the 'delegated team' route?
[20:32] <infinity> If you're going to end up with a large package set and a team managing it, you'll probably want to go the team route.
[20:38] <micahg> scott-work: you probably want a package set as opposed to a delegated team unless you plan on a lot of applicants for Ubuntu Studio packages that you would like to be able to approve
[20:40] <micahg> scott-work: #ubuntu-devel is fine for membership questions
[20:40] <micahg> the DMB doesn't have its own channel, although, maybe that's not a bad idea...
[21:13] <scott-work> sorry, infinity and micahg, i was in a meeting at work
[21:14] <scott-work> infinity and micahg, i do not expect many people to have permissions to push studio packages to the repos, possibly only two for redundancy
[21:15] <micahg> scott-work: yeah, you just need upload rights for the ubuntustudio packageset then
[21:15] <micahg> scott-work: let's continue in #ubuntustudio-devel
[21:16] <Laney> yeah, there already is one