=== medberry is now known as med_out
micahgcould 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.604:52
cjwatsonI've merged micahg's transition tracker branch above08:34
Laneyi should merge ben from upstream at some point09:22
Laneythink mehdi made some improvements09:22
jamespagedoko__, skaet, component mismatches now looking much better10:32
jamespagedoko__, 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 87641310:32
ubot4Launchpad bug 876413 in xmlunit (Ubuntu) (and 15 other projects) "[MIR] xmlunit (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/87641310:32
jamespagesorry - bug 87714610:33
ubot4Launchpad bug 877146 in testng (Ubuntu) (and 3 other projects) "[MIR] junit4 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/87714610:33
doko__jamespage, nice. and the -perl stuf will be gone next10:34
jamespagedoko__, want me to look at the jython deps?10:35
jamespageI need to look at the new ones for mysql-connector as well10:35
doko__jamespage, sure, would be nice10:36
jamespagedoko__, well I seem to be on a MIR run ATM so np10:36
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:39
doko__o libextutils-cbuilder-perl: libextutils-cbuilder-perl10:40
doko__   [Reverse-Depends: libmodule-build-perl]10:40
doko__ o libextutils-parsexs-perl: libextutils-parsexs-perl10: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:40
cjwatsondon't know, chase through germinate output?10:47
cjwatsonperhaps something uninstallable on some architectures10:47
cjwatsonah, it's just armhf10:48
cjwatsonlet me take that out of c-m for now if it's being confusing10:48
cjwatsondoko__: better now?10:49
doko__cjwatson, yes, thanks!10:52
cjwatsondoko__: 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 default11:25
cjwatsonI hadn't fully got my head around that distinction when we last talked about this11:26
doko__so we'll only catch errors catched by debian?11:28
cjwatsonI don't know if it's the right thing to do, that's why I'm wondering :)11:29
cjwatsonour intention in continuing to export dpkg-buildflags output by default was to generally keep things at at least the state they were in in oneiric11:30
cjwatsonthere is an argument that in order to fulfil that we could export only those flags that were exported in oneiric11: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 main11:31
doko__but not that many11:31
=== doko__ is now known as doko
cjwatsonhttp://paste.ubuntu.com/713099/ - diff between exported flags11:34
cjwatsonI appreciate that the security team would love it to have all the hardening flags enabled by default11:35
cjwatsonbut we'll see whether exporting them from dpkg-buildpackage is a bit much11:35
cjwatsonthat would affect third-party packages too11:36
dokothe only problematic one is -Werror=format-security. can we live with this one until we have the first test rebuild?11:38
cjwatsonhttps://launchpadlibrarian.net/83181749/buildlog_ubuntu-precise-amd64.ziproxy_3.1.3-1build1_FAILEDTOBUILD.txt.gz I don't like the look of this11:56
cjwatsonah, perl/amd64 built a bit quicker than perl/i38611:57
* cjwatson gives a load of stuff back then11:57
jdstrandcjwatson, 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 options12:25
jdstrandcjwatson, 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 kees12:26
dokojdstrand, this is no regression within ubuntu, just extra stuff from debian.12:28
jdstrandwell, 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
jdstrandand I'm sure you know *way* more about it than I :)12:29
cjwatsonjdstrand: "lose" - this has only been in Ubuntu for less than five days12:53
cjwatsonin the particular form we're talking about12:54
jdstrandack-- I just saw that and got panicky for a moment. I apologize (hardening options are understandably a big deal for our team)12:54
cjwatsonunderstood, I certainly don't mean to regress from what's in oneiric13:02
cjwatsonthat would be (a) bad and (b) unnecessary :)13:02
jamespagedoko, I think we can probably drop jython from main15:49
dokojamespage, your call, I'm fine with it, if it's just optional features.15:51
jamespagedoko: well its used by two packages optionally - one of which already has it disabled because its broken15:52
jamespage(but its still kept the dep)15:52
jamespagedoko: OK - going to go with dropping the last remaining optional use of jython16:04
jamespagecan't find any reverse deps that use it and jython16:05
jamespagedoko: MIR bug 878186 is ready for review if you have time16:09
ubot4Launchpad bug 878186 in libslf4j-java (Ubuntu) (and 1 other project) "[MIR] libslf4j-java (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/87818616:09
jamespagemanaged to remove one extra dependency that was not required16:10
* micahg wonders why his wxwidgets tracker is failing...16:15
Laneyno semicolon after title?16:17
Laneywe'll see, pushed16:19
micahgLaney: ah, probably it, thanks :)16:22
micahgLaney: is there a notes field?  I added the Debian wiki link in the title since I wasn't sure16:22
Laneynot that i know of16:22
Laneywe should get some kind of index16:22
dokojamespage, thanks, promoted16:37
jamespagedoko: thanks16:37
=== med_out is now known as med
=== med is now known as medberry
scott-workcjwatson: 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:44
infinityscott-work: We have no formal team contact, but you know most of us.18:45
infinityscott-work: https://launchpad.net/~ubuntu-cdimage/+members18:45
scott-workinfinity, awesome!  thank you :)19:04
scott-worki'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-workas ubuntu studio project lead i want to get permission to push studio packages to the repositories20:13
scott-workshould i follow the 'per package' route for permission or the 'delegated team' route?20:14
infinityIf 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:32
micahgscott-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 approve20:38
micahgscott-work: #ubuntu-devel is fine for membership questions20:40
micahgthe DMB doesn't have its own channel, although, maybe that's not a bad idea...20:40
scott-worksorry, infinity and micahg, i was in a meeting at work21:13
scott-workinfinity and micahg, i do not expect many people to have permissions to push studio packages to the repos, possibly only two for redundancy21:14
micahgscott-work: yeah, you just need upload rights for the ubuntustudio packageset then21:15
micahgscott-work: let's continue in #ubuntustudio-devel21:15
Laneyyeah, there already is one21:16

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!