| === medberry is now known as med_out | ||
| 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 | 04:52 |
|---|---|---|
| cjwatson | I've merged micahg's transition tracker branch above | 08:34 |
| Laney | i should merge ben from upstream at some point | 09:22 |
| Laney | think mehdi made some improvements | 09:22 |
| 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:32 |
| 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:33 |
| doko__ | jamespage, nice. and the -perl stuf will be gone next | 10:34 |
| 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:35 |
| doko__ | jamespage, sure, would be nice | 10:36 |
| jamespage | doko__, well I seem to be on a MIR run ATM so np | 10:36 |
| 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:39 |
| 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:40 |
| cjwatson | don't know, chase through germinate output? | 10:47 |
| cjwatson | perhaps something uninstallable on some architectures | 10:47 |
| 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:48 |
| cjwatson | doko__: better now? | 10:49 |
| doko__ | cjwatson, yes, thanks! | 10:52 |
| 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:25 |
| cjwatson | I hadn't fully got my head around that distinction when we last talked about this | 11:26 |
| doko__ | so we'll only catch errors catched by debian? | 11:28 |
| cjwatson | right | 11:29 |
| cjwatson | I don't know if it's the right thing to do, that's why I'm wondering :) | 11:29 |
| 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:30 |
| 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 | 11:31 |
| === doko__ is now known as doko | ||
| cjwatson | http://paste.ubuntu.com/713099/ - diff between exported flags | 11:34 |
| 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:35 |
| cjwatson | that would affect third-party packages too | 11:36 |
| doko | the only problematic one is -Werror=format-security. can we live with this one until we have the first test rebuild? | 11:38 |
| cjwatson | yep | 11:39 |
| 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:56 |
| cjwatson | ah, perl/amd64 built a bit quicker than perl/i386 | 11:57 |
| * cjwatson gives a load of stuff back then | 11:57 | |
| 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:25 |
| 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:26 |
| doko | jdstrand, this is no regression within ubuntu, just extra stuff from debian. | 12:28 |
| jdstrand | ah | 12:28 |
| 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:29 |
| cjwatson | jdstrand: "lose" - this has only been in Ubuntu for less than five days | 12:53 |
| 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) | 12:54 |
| 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 :) | 13:02 |
| jamespage | doko, I think we can probably drop jython from main | 15:49 |
| doko | jamespage, your call, I'm fine with it, if it's just optional features. | 15:51 |
| 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) | 15:52 |
| jamespage | doko: OK - going to go with dropping the last remaining optional use of jython | 16:04 |
| jamespage | can't find any reverse deps that use it and jython | 16:05 |
| 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:09 |
| jamespage | managed to remove one extra dependency that was not required | 16:10 |
| * micahg wonders why his wxwidgets tracker is failing... | 16:15 | |
| Laney | no semicolon after title? | 16:17 |
| Laney | we'll see, pushed | 16:19 |
| 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:22 |
| doko | jamespage, thanks, promoted | 16:37 |
| jamespage | doko: thanks | 16:37 |
| === med_out is now known as med | ||
| === med is now known as medberry | ||
| 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:44 |
| 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 | 18:45 |
| scott-work | infinity, awesome! thank you :) | 19:04 |
| 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:13 |
| scott-work | should i follow the 'per package' route for permission or the 'delegated team' route? | 20:14 |
| 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:32 |
| 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:38 |
| 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... | 20:40 |
| scott-work | sorry, infinity and micahg, i was in a meeting at work | 21:13 |
| 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:14 |
| 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:15 |
| Laney | yeah, there already is one | 21:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!