[00:07] <bluesabre> Release team, please let us know if there is any objection to https://launchpad.net/bugs/1372085 - we have ack from docs and translation teams
[00:07] <ubot2> Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]
[00:07] <ubot93> Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]
[01:10] <ScottK> bluesabre: Did you send the mail to the translators ML?
[01:11] <bluesabre> ScottK, wasn't sure whether the mail should be sent before or after upload
[01:11] <bluesabre> I can send it now
[01:11] <ScottK> Before the approval.
[01:11] <bluesabre> ok
[01:12] <ScottK> Write in the bug when it's been sent.
[01:23] <bluesabre> ScottK, done.
[01:31] <knome> ScottK, most affected should know this already :)
[01:48] <ScottK> knome: Still the mail should be sent.
[01:49] <ScottK> bluesabre: Approved.
[01:51] <bluesabre> thanks ScottK
[02:02] <knome> ScottK, sure, agreed. :)
[07:08] <jack_> hi, release team, would you please review the FFe request at bug #1371165?
[07:08] <ubot2> bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/1371165
[07:08] <ubot93> bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/1371165
[07:10] <jack_> Laney, hi, are you around?
[08:28] <Laney> hi JackYu (assume that was you), will look at the queue of ffe requests soon
[10:51] <bluesabre> Release team, please review https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1372391 and let us know if you approve.
[10:51] <ubot2> Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]
[10:51] <ubot93> Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]
[10:52] <knome> i've also pinged Riddell on sponsoring it since he did another upload of it earlier today, but others are free to take it :)
[10:57] <Riddell> you have?
[10:59] <Riddell> knome: any screenshots in docs or anywhere that need updated?
[10:59] <knome> nope, slideshow is the only place we have screenshots in
[10:59] <knome> well in addition to the website, but those are not used for documentation :)
[11:00] <Riddell> knome: groovy, uploading
[11:00] <knome> cheers!
=== mapreri_ is now known as mapreri
=== barry` is now known as barry_
=== barry_ is now known as barry
=== bdrung_work_ is now known as bdrung_work
[13:45] <mlankhorst> infinity: I've tested basic KDE and lightdm, made sure that some of the tests that hung earlier on llvm-3.5 didn't regress, and I'll commit to doing .1 before final release, can you give your ok in https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1364003 so I can upload mesa 10.3.0?
[13:45] <ubot2> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]
[13:45] <ubot93> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]
=== ricmm_ is now known as ricmm
[14:44] <Riddell> mlankhorst: ooh new mesa? should I test it out?
[14:44] <mlankhorst> feel free, it's in ppa:canonical-x/x-staging
[14:45] <Riddell> gotcha
=== Guest26752 is now known as jpds
[15:04] <Riddell> mlankhorst: when you say you tested KDE what do you test?
[15:05] <mlankhorst> that compositing works without crashes
[15:06] <Riddell> mlankhorst: so you play around with kwin?
[15:09] <mlankhorst> Riddell: yeah just the basic things though..
[15:09] <mlankhorst> enabling/disabling compositing, creating/closing window
[15:12] <Riddell> mlankhorst: and do you test on all the major video card types? cos in the past we've had problems that occur only on 1 type in one of these FFe mesas
[15:44] <Trevinho> Laney: hey, could you put some love on https://bugs.launchpad.net/compiz/+bug/1356981 ? :)
[15:44] <ubot2> Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]
[15:44] <ubot93> Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]
[15:44] <Laney> Trevinho: I just loaded it up
[15:44] <Laney> before your ping
[15:44] <Trevinho> Laney: ah, cool... :)
[15:58] <rbasak> Could somebody review bcache-tools from Utopic NEW, please? It's a pretty straightforward package.
[15:58] <rbasak> (and small)
[16:27] <infinity> mlankhorst: Commented.
[16:32] <ScottK> infinity: FYI, kwin upstream say's he's not tested this version of mesa at all and if stuff breaks, we're on our own (he's focused on the Qt5 port we'll use in the next cycle).
[16:32] <ScottK> Given the complete lack of kwin expertise in the Kubuntu team, I'm officially concerned.
[16:32] <ScottK> Riddell: ^^^
[16:34] <didrocks> JackYu: FYI ^
[16:34] <Riddell> yeah I'm also against it I'm afraid, we can't adequately test it in the time
=== maclin_ is now known as maclin
[16:36] <JackYu> didrocks, great^
[16:42] <infinity> ScottK / Riddell: What level of testing would we need to be happy enough?  We can't stop updating mesa because an upstream hasn't tested, this is part of being a larger distro, we sometimes have to take the hit and do the testing (and even fixing) ourselves.
[16:42] <infinity> THough, yes, the timing is bad, and if we can't test in time, that's a valid reason to NACK.
[16:42] <ScottK> infinity: I'd be less unhappy if I had some idea who "ourselves" might be.
[16:43] <ScottK> (re fixing)
[16:44] <infinity> ScottK: Well, in a Debian context, that would be the maintainers of the packages affected.  In Ubuntu, I'm not sure who should own such a breakage.  If it was "Ubuntu breaking a flavour with our own weird stuff", I'd say Canonical UE owns the problem, but when it's "a flavour needs to keep older versions out of paranoia", that's a bit harder to lay blame. :P
[16:44] <infinity> Anyhow, I'd love to just see enough testing that people were confident enough.
[16:44] <infinity> If that can't be done, you guys can NACK, it's well past FF.
[16:44] <ScottK> How about out of experience that every time we do this, it goes badly.
[16:45] <ScottK> That's not paranoia, that's history.
[16:45] <infinity> Wasn't the breakage in the past API/ABI breaks?
[16:45] <infinity> This one's ABI compatible, I thought.
[16:46] <ScottK> My recollection is that they weren't all advertised as incompatible.
[16:47] <Riddell> I don't think it's paranoia to not want risky FFe updates, that's kindae the point of FFe
[16:47] <ScottK> infinity: Also see Riddell's latest in the bug.  Testing didn't go well for him.
[16:50] <Riddell> I guess I'd like to see testing reports on intel, amd and nvidia using kwin 4 and 5
[16:50] <infinity> Yeahp, fair enough.
[16:51] <infinity> mlankhorst: So, that's no longer a +1. :P
[16:51] <Riddell> from kwin dev mgraesslin: "As with each mesa version it could mean that the
[16:51] <Riddell> world explodes (recently we learned that we are no longer allowed to use lose
[16:52] <Riddell> binding on Intel drivers)."
=== maxb_ is now known as maxb
[19:01] <barry> sru team: i have a package that must be backported to trusty (it's currently only available in utopic) in order to fix a potentially sru'able bug in another package.  is it allowed for the first package to go into -updates instead of -backports?  ftr: we would need 'wheel' to be available to sru a fix for LP: #1290847
[19:01] <ubot2> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
[19:01] <ubot93> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/1290847
[19:11] <ScottK> barry: Doesn't that also imply a stack of changes in other packages to give them wheels?
[19:11] <ScottK> Also, it probably matters if it has to be in main who would have to say it's OK.
[19:22] <barry> ScottK: it does
[19:23] <barry> ScottK: maybe i should just make the error message say "install python-virtualenv and use -p python3"
[19:23] <barry> and leave it at that
[19:23] <barry> it's *a lot* of effort to backport a proper fix
[19:23] <barry> sadly
[19:35] <infinity> barry: If a less intrusive fix is possible, that's preferrable.
[19:35] <infinity> barry: We *can* backport new sources to -updates as SRUs, and occasionally do, but I'd prefer it's a last resort, not a go-to.
[19:35] <barry> infinity: i think the less intrusive fix is print("go use virtualenv")
[19:36] <barry> infinity: which i'm actually fine with
[19:36] <barry> infinity: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847/comments/48
[19:36] <ubot2> Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released]
[19:37] <infinity> barry: Functionally, what ends up being the difference between A and B?  Does either (or both) escape using packaged binaries, is there a security impact to recommending one over the other, blah blah?
[19:38] <infinity> barry: If printing explicit instructions on how to use virtualenv solves the issue with no real negative side-effects, I think that's fine.
[19:38] <barry> infinity: there really is no functional difference imho.  it's just that the functionality of virtualenv comes built-in with py3.4 now
[19:39] <infinity> barry: Kay, but the external virtualenv continues to work as well is the implication?
[19:39] <barry> yep
[19:39] <infinity> barry: Could this be hacked to that trying to use the built-in triggers using the external (and print a helpful message instead of a messy backtrace if it's not installed?)
[19:39] <infinity> s/to that/so that/
[19:41] <infinity> barry: ie, could "python3 -m venv" transparently check for virtualenv, error if not install, else fork "virtualenv -p python3", and people could then start using the new interface, even if it's using the old method?
[19:41] <barry> infinity: i'm not sure i like that.  e.g. i'm not positive that the cli switches are totally aligned.  i think i'd rather tell people what to do than do it for them
[19:41] <infinity> barry: Kay, if they wouldn't be 100% compatible, I agree it's a bad idea, so just printing the "yo, this is broken, try the other thing" would be fine, IMO.
[19:42] <barry> infinity: would you like to add a comment to that bug with your official sru hat on?
[19:42] <infinity> barry: Feel free to copy and paste. :P
[19:42] <barry> ;)
[19:43] <infinity> barry: Just make sure the printed message attempts to not be too negative/scary, while also being informative enough that people aren't left with more questions than answers.
[19:43] <barry> infinity: good point