/srv/irclogs.ubuntu.com/2014/09/22/#ubuntu-release.txt

bluesabreRelease team, please let us know if there is any objection to https://launchpad.net/bugs/1372085 - we have ack from docs and translation teams00:07
ubot2Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]00:07
ubot93Launchpad bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New]00:07
ScottKbluesabre: Did you send the mail to the translators ML?01:10
bluesabreScottK, wasn't sure whether the mail should be sent before or after upload01:11
bluesabreI can send it now01:11
ScottKBefore the approval.01:11
bluesabreok01:11
ScottKWrite in the bug when it's been sent.01:12
bluesabreScottK, done.01:23
knomeScottK, most affected should know this already :)01:31
ScottKknome: Still the mail should be sent.01:48
ScottKbluesabre: Approved.01:49
bluesabrethanks ScottK01:51
knomeScottK, sure, agreed. :)02:02
jack_hi, release team, would you please review the FFe request at bug #1371165?07:08
ubot2bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/137116507:08
ubot93bug 1371165 in Ubuntu Kylin "[FFe] Upload ubuntu-kylin-sso-client to Archive for UKSC" [High,New] https://launchpad.net/bugs/137116507:08
jack_Laney, hi, are you around?07:10
Laneyhi JackYu (assume that was you), will look at the queue of ffe requests soon08:28
bluesabreRelease team, please review https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/1372391 and let us know if you approve.10:51
ubot2Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]10:51
ubot93Launchpad bug 1372391 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update Xubuntu slideshow artwork" [Undecided,New]10:51
knomei've also pinged Riddell on sponsoring it since he did another upload of it earlier today, but others are free to take it :)10:52
Riddellyou have?10:57
Riddellknome: any screenshots in docs or anywhere that need updated?10:59
knomenope, slideshow is the only place we have screenshots in10:59
knomewell in addition to the website, but those are not used for documentation :)10:59
Riddellknome: groovy, uploading11:00
knomecheers!11:00
=== 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
mlankhorstinfinity: 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
ubot2Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]13:45
ubot93Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]13:45
=== ricmm_ is now known as ricmm
Riddellmlankhorst: ooh new mesa? should I test it out?14:44
mlankhorstfeel free, it's in ppa:canonical-x/x-staging14:44
Riddellgotcha14:45
=== Guest26752 is now known as jpds
Riddellmlankhorst: when you say you tested KDE what do you test?15:04
mlankhorstthat compositing works without crashes15:05
Riddellmlankhorst: so you play around with kwin?15:06
mlankhorstRiddell: yeah just the basic things though..15:09
mlankhorstenabling/disabling compositing, creating/closing window15:09
Riddellmlankhorst: 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 mesas15:12
TrevinhoLaney: hey, could you put some love on https://bugs.launchpad.net/compiz/+bug/1356981 ? :)15:44
ubot2Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]15:44
ubot93Launchpad bug 1356981 in Compiz "[FFe] Regression: wrong window decorator applied" [High,In progress]15:44
LaneyTrevinho: I just loaded it up15:44
Laneybefore your ping15:44
TrevinhoLaney: ah, cool... :)15:44
rbasakCould somebody review bcache-tools from Utopic NEW, please? It's a pretty straightforward package.15:58
rbasak(and small)15:58
infinitymlankhorst: Commented.16:27
ScottKinfinity: 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
ScottKGiven the complete lack of kwin expertise in the Kubuntu team, I'm officially concerned.16:32
ScottKRiddell: ^^^16:32
didrocksJackYu: FYI ^16:34
Riddellyeah I'm also against it I'm afraid, we can't adequately test it in the time16:34
=== maclin_ is now known as maclin
JackYudidrocks, great^16:36
infinityScottK / 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
infinityTHough, yes, the timing is bad, and if we can't test in time, that's a valid reason to NACK.16:42
ScottKinfinity: I'd be less unhappy if I had some idea who "ourselves" might be.16:42
ScottK(re fixing)16:43
infinityScottK: 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. :P16:44
infinityAnyhow, I'd love to just see enough testing that people were confident enough.16:44
infinityIf that can't be done, you guys can NACK, it's well past FF.16:44
ScottKHow about out of experience that every time we do this, it goes badly.16:44
ScottKThat's not paranoia, that's history.16:45
infinityWasn't the breakage in the past API/ABI breaks?16:45
infinityThis one's ABI compatible, I thought.16:45
ScottKMy recollection is that they weren't all advertised as incompatible.16:46
RiddellI don't think it's paranoia to not want risky FFe updates, that's kindae the point of FFe16:47
ScottKinfinity: Also see Riddell's latest in the bug.  Testing didn't go well for him.16:47
RiddellI guess I'd like to see testing reports on intel, amd and nvidia using kwin 4 and 516:50
infinityYeahp, fair enough.16:50
infinitymlankhorst: So, that's no longer a +1. :P16:51
Riddellfrom kwin dev mgraesslin: "As with each mesa version it could mean that the16:51
Riddellworld explodes (recently we learned that we are no longer allowed to use lose16:51
Riddellbinding on Intel drivers)."16:52
=== maxb_ is now known as maxb
barrysru 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: #129084719:01
ubot2Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/129084719:01
ubot93Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released] https://launchpad.net/bugs/129084719:01
ScottKbarry: Doesn't that also imply a stack of changes in other packages to give them wheels?19:11
ScottKAlso, it probably matters if it has to be in main who would have to say it's OK.19:11
barryScottK: it does19:22
barryScottK: maybe i should just make the error message say "install python-virtualenv and use -p python3"19:23
barryand leave it at that19:23
barryit's *a lot* of effort to backport a proper fix19:23
barrysadly19:23
infinitybarry: If a less intrusive fix is possible, that's preferrable.19:35
infinitybarry: 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
barryinfinity: i think the less intrusive fix is print("go use virtualenv")19:35
barryinfinity: which i'm actually fine with19:36
barryinfinity: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847/comments/4819:36
ubot2Launchpad bug 1290847 in python3.4 (Ubuntu) "pyvenv fails due to mising ensurepip module" [Undecided,Fix released]19:36
infinitybarry: 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:37
infinitybarry: 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
barryinfinity: there really is no functional difference imho.  it's just that the functionality of virtualenv comes built-in with py3.4 now19:38
infinitybarry: Kay, but the external virtualenv continues to work as well is the implication?19:39
barryyep19:39
infinitybarry: 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
infinitys/to that/so that/19:39
infinitybarry: 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
barryinfinity: 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 them19:41
infinitybarry: 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:41
barryinfinity: would you like to add a comment to that bug with your official sru hat on?19:42
infinitybarry: Feel free to copy and paste. :P19:42
barry;)19:42
infinitybarry: 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
barryinfinity: good point19:43

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