[08:17] <xnox>  -queuebot:#ubuntu-release- New source: boost-mpi-source1.49 (quantal-release/primary) [1.49.0-3ubuntu1]
[08:17] <xnox> Can somebody accept ^^^^, this is the 'universe' edition of the boost1.49 package to build mpi dependant debs.
[08:18] <xnox> I prepared the package, ScottK reviewed & sponsored it.
[08:18] <xnox> It will fix a few ftbfs & will help with boost1.49 transition, which I was hoping to finish before Alpha 1.
[08:20] <infinity> xnox: I'll look at it.
[08:21] <xnox> infinity: thank you.
[08:21] <infinity> xnox: I assume it's pretty much just a version bump of boost-mpi-source1.46?
[08:21] <xnox> infinity: yes.
[08:22] <xnox> build from the matching complete version of boost1.49
[08:24] <xnox> (hence the errors from lintain about using matching source-version number, when the other debs are, in fact, in the main/boost1.49)
[08:27] <infinity> xnox: Accepted, BTW.  queuebot was away and didn't tell you. :P
[08:27] <xnox> infinity: thanks =)
[08:27] <xnox> queuebot: wakey wakey =)
[08:29] <xnox> infinity: I've marked bug #1005179 as fix released
[08:29] <ubot2> Launchpad bug 1005179 in boost-mpi-source1.46 "Please upload boost-mpi-source1.49" [Wishlist,Fix released] https://launchpad.net/bugs/1005179
[11:06] <ogra_> infinity, any progress wrt arm livefs-builder chroots ?
=== Guest55695 is now known as Pici
[13:11] <seb128> could software-center from precise-proposed be moved to updates earlier than the week period? it fixes a regression from the previous SRU (which moved to updates) which is the most reported bug on errors.ubuntu.com
[13:11] <seb128> SpamapS, RAOF, slangasek, other SRU members: ^
[13:22] <seb128> SpamapS, RAOF, slangasek, other SRU members: ^
[13:39] <infinity> seb128: See the bug, it seems to still be lacking verification.
[13:40] <ogra_> infinity, !
[13:40] <ogra_> infinity, did you see my ping above ?
[13:40] <seb128> infinity, it's ridiculous to let a regression which reached -updates and is our most reported bug non solved this way...
[13:40] <infinity> ogra_: I did, yeah.  Remind me when it's not 10pm? ;)
[13:40] <ogra_> since you are at connect, can you tell me who to work with to get these chroots fixed ?
[13:41] <ogra_> and we need to talk about the flash-kernel sync/merge/move ... i would like to do it before A1
[13:41] <infinity> seb128: Uhm, I'm happy to move it early, but the bug doesn't show that anyone's tested that the upload actually fixed the bug.
[13:41] <infinity> seb128: Hint, you could do that. :P
[13:41] <seb128> infinity, well, it comes down on "do you prefer to keep a regression in updates that trust mvo's fix and try if that fixes it"?
[13:42] <infinity> seb128: In the time you're spending arguing about it, you could have installed the update and reproduced the bug (or not) surely?
[13:42] <seb128> infinity, yeah, I could, I'm a bit annoyed that mvo asked here on friday (or thurday) that we fix up the screwage and that we let the regression sit in for 5 days
[13:43] <seb128> infinity, right, that would not solve the issue that people are happy to keep regression in -updates that way though
[13:43] <ogra_> wasnt there an emergency process for such cases since we blew up xorg in dapper in an SRU ?
[13:43] <infinity> seb128: I would have happily pushed it through same-day, if it had been tested.
[13:43] <seb128> shrug
[13:43]  * ogra_ thinks there was something about this on the canonical wiki
[13:44] <infinity> ogra_: Even in the most extreme cases, we still require a light bit of QA/verification before we just jam it down user's throats.
[13:44] <cjwatson> Blowing up xorg in dapper is what prompted the introduction of the heavyweight SRU process in the first place.
[13:44] <seb128> I'm testing it now, but options were to either keep a regression unresolved and sit on it or to try a fix from the maintainer
[13:44] <ogra_> infinity, true
[13:45] <seb128> infinity, I guess another option would have been to roll the SRU out in some way
[13:45] <seb128> infinity, still I would like to figure why we considered fine to keep things in that state rather than chasing a tester if that's what blocked the regression fix
[13:45] <infinity> seb128: No one's "sitting on it", we're happy to move, if people actually tested it.  That's really the bottom line here.  I won't argue that we don't need more people testing (we do), but if you have a personal interest in an SRU, doing the testing yourself isn't all that much to ask?
[13:46] <seb128> infinity, I don't have a personal interest in it
[13:46] <infinity> You seem to have made it personal. ;)
[13:46] <seb128> infinity, I've a personal interest it us not letting regression in LTS stable update unaddressed
[13:47] <infinity> Anyhow, I've been barely around since it was accepted, so I'm going to feign ignorance about what's happened in the last few days, all I can go by is the bug log.
[13:47] <seb128> infinity, yeah, because I though that issue was handled last week and I still see it on top of the reported issues list today
[13:48] <cjwatson> "why we considered fine to keep things in that state rather than chasing a tester" - you're assuming agency where there is none, I think
[13:48] <infinity> Anyhow.  I'm going to wander out for a smoke.  If you've managed to reliably verify it by the time I get back, I'll happily promote it.
[13:48] <cjwatson> i.e. the problem is that nobody took ownership of the fact that there was a regression
[13:49] <cjwatson> Nobody is sitting at their desk cackling malevolently at how they get to keep the regression in place :-)
[13:49] <infinity> This all reminds me that I need to write up some bits and bobs based on the mishmash of stuff we got out of the agile-sru session.
[13:49] <seb128> cjwatson, right, I guess the bottom line is "should we have somebody taking ownership of regressions"
[13:49] <cjwatson> Yes!  That was the point of dealingwithcrisis and friends
[13:49] <infinity> One of those things involves making sure that uploaders stay active in the life of an SRU.
[13:49] <seb128> cjwatson, and if the reply is "yes", who and do we have a process?
[13:49] <cjwatson> The answer isn't to compound the problem by promoting furthere fixes without testing.
[13:50] <ogra_> dealingwithcrisis ! that was the name i couldnt remember before
[13:50] <cjwatson> https://wiki.canonical.com/UbuntuEngineering/DealingWithCrisis
[13:50] <cjwatson> seb128: ^-
[13:50] <seb128> cjwatson, right, I get I see it as a failure that mvo asked for help there last week and nobody picked it up
[13:50] <seb128> cjwatson, I'm not sure I consider that bug important enough to warrant doing the full crisis stuff
[13:50] <cjwatson> I think it's possible/reasonable to follow parts of that process without the whole thing
[13:50] <seb128> cjwatson, but for sure it should have been tracked closely to resolution
[13:51] <cjwatson> We don't have to do the whole business of suppressing further distribution of the update if the bug doesn't warrant that
[13:51] <cjwatson> But it has useful advice/process on making sure that somebody stays on top of the problem
[13:51] <seb128> ok, noted for next time, I though that process was for real crisis
[13:52] <seb128> I'm not sure I qualify software-center have a regression lot of users hit but which doesn't break the software to be one
[13:52] <seb128> but it's an issue and an annoyance for sure
[13:52] <infinity> There are varying degrees of crisis.
[13:52] <cjwatson> We haven't really executed that process for some time (which is a good thing), but one of its virtues is that if somebody has the baton on dealing with it right now, they don't get to finish their day without handing off to somebody else.
[13:52] <seb128> well anyway, the bug report about the regression has no steps to reproduce and mvo is not around
[13:52] <infinity> Anyhow, the big issue here is just that people needed to stay on top of it.
[13:53] <seb128> it's just a frequently showing on errors.ubuntu.com
[13:53] <seb128> so not sure how to drive it to verification-done...
[13:53] <cjwatson> As a minimum we should have regression testing.
[13:53] <seb128> I would assume that mvo knows what he's doing (and he got review for the fix as well)
[13:53] <infinity> If it's not too easy to reproduce, waiting on mvo might be fine.  (and this is a reason we need test cases...)
[13:54] <cjwatson> You know, it's still actually possible to use software-center, that kind of thing.
[13:54] <seb128> infinity, we can't always come with testcases for apport bugs
[13:54] <xnox> what's the bug number I can verify - I have precise VM on & I think software-centre bug is affecting me as well
[13:54] <seb128> cjwatson, right, I assume that having it in 5 days in proposed without new issues reported is a good indication that we didn't break it much
[13:54] <infinity> xnox: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1002271
[13:54] <ubot2> Launchpad bug 1002271 in software-center "REGRESSION: crash in cell renderer" [Medium,In progress]
[13:54] <cjwatson> Not without an explicit ack, no.
[13:55] <infinity> xnox: You tried to verify it on quantal, apparently, which went poorly for you. :P
[13:55] <cjwatson> We have no measurements of who's using what in -proposed.  That's a verification-by-prayer approach.
[13:55] <xnox> infinity: aha =) so yeah I am affected.
[13:55] <cjwatson> The aging period was meant as additional insurance, not as an end in itself.
[13:56] <infinity> seb128: And yeah, I feel the pain with backtrace bugs.  I know I've fixed my fair share of segfaults in C based on backtraces that I couldn't reproduce, I'm sure python's no different.  Still, it would be nice if somene could reproduce it.
[13:56] <infinity> seb128: But failing that, as Colin notes, regression testing would at least be nice.
[13:56] <seb128> infinity, right, I've been cross posting on #ubuntu-devel,desktop,bugs
[13:56] <seb128> I can ack it still works for me
[13:56]  * xnox goes to try again, but in the precise VM this time.
[13:57] <infinity> That's helpful data.
[13:57] <seb128> but let's see if I can get a few extra feedback and maybe somebody who has the issue to confirm the fix
[13:57] <infinity> Hopefully, xnox can actually reproduce and verify.
[13:57]  * infinity goes for that smoke now.
[13:58] <xnox> 5.2.2 crashes in Precise VM
[13:58] <xnox> wait, that was quantal
[13:58] <xnox> sorry =)
[13:59]  * xnox downloading stuff
[14:05] <seb128> xnox, for the record bug #1000238 is the quantal issue you have been hitting
[14:05] <ubot2> Launchpad bug 1000238 in software-center "Software-Center crashes on starting" [High,In progress] https://launchpad.net/bugs/1000238
[14:06] <xnox> thanks.
[14:13] <infinity> mdeslaur: Should I assume from your comment on the software-center bug that you can't browse categories with 5.2.2, but you can with 5.2.2.1?
[14:14] <mdeslaur> infinity: I didn't experience the bug with 5.2.2, but my understanding is that simply browsing categories makes the bug occur.
[14:17] <infinity> Hrm.  Yeah, I can't get 5.2.2 to die here. :/
[14:26] <seb128> infinity, cjwatson, mdeslaur: hggdh had the issue and confirms that the update fixes it
[14:27] <mdeslaur> ah, good
[14:27] <infinity> \o/
[14:27] <infinity> Good enough for me.
[14:28] <hggdh> marked -done on it
[14:28] <hggdh> go for the kill
[14:33]  * infinity decides it's time to go watch cartoons and fall asleep.
[15:00]  * SpamapS reads backscroll on software-center issue and is bummed out because its mostly just that we, the SRU team, are a bit behind
[15:06] <seb128> SpamapS, hey, don't get bummed, it was not especially a SRU team issue, rather a miscommunication which did lead to move the buggy version to -updates and then lack of follow up on the update which fixed that issue (which is a release team issue as much as a SRU team one) ... well anyway being sorted at the end, next team we will do proper escalation when that happens so things are better tracked
[15:55] <ScottK> skaet: It might be useful to take a look back after 12.04.1 and see how much SRU activity can be tied back to late feature additions in precise.  It might give us a gauge on if we're being too aggressive.
[15:55] <ScottK> (I'm mentioning this, since I just found such a case)
[15:57] <skaet> ScottK,   yeah,  keeping a list of this as we go along would be interesting data for the next feedback meeting.     Possibly one for the Precise LTS  (in addition to the Quantal) may well be appropriate.
[15:58]  * skaet pondering best method for capturing. 
[15:59] <ScottK> OK.  It looks like Bug #993672  is tied to the new data downloader.
[15:59] <ubot2> Launchpad bug 993672 in update-notifier "Ships malformed interactive upgrade hook which causes translations to be shown in the dialog" [High,Fix committed] https://launchpad.net/bugs/993672
[15:59] <ScottK> So there's one for you.
[15:59] <skaet> Thanks.
[15:59] <knome> skaet, hey :)
[15:59] <knome> skaet, want to approve xubuntu blueprints? :)
[16:00] <slangasek> seb128: so I approved the updated software-center in based on a conversation with Gary, and I told him that yes, we would ignore the aging requirement for this SRU - but that we still needed SRU verification
[16:00] <slangasek> not following the SRU verification process is how the *previous* regression made it to -updates
[16:00] <skaet> knome,  bounce me the links in a pm, and I'll work through them now.
[16:01] <seb128> slangasek, I guess my main concern is that nobody actively tracker a tester or talked to qa about needing to get that one tested
[16:01] <slangasek> qa doesn't test SRUs
[16:01] <seb128> slangasek, so we stayed with a regression from -updates topping errors.ubuntu.com when we had a fix available that we were not able to deploy
[16:01] <slangasek> my understanding was that Gary was going to follow up to get it tested
[16:02] <slangasek> no one had verified that it was actually a fix yet, or that it didn't introduce other regressions
[16:02] <ogra_> probably QA should get resources to actually do the SRU testing then :)
[16:02] <ogra_> at least for main
[16:03] <seb128> slangasek, well, qa doesn't test SRUs, but we ought to find the resources somewhere to deal with regression we land in -updates especially in a LTS
[16:04] <slangasek> yes, and it was my understanding that Gary was doing that
[16:04] <slangasek> so evidently there was a misunderstanding on this point
[16:04] <seb128> slangasek, ok, I will check with him what went wrong there
[16:05] <seb128> slangasek, I still think that sru regressions (especially in a lts) should be release team tracked as well
[16:05] <seb128> slangasek, I guess what went wrong there is that nobody considered that important enough to escalate it as a real incident, seems that was wrong to not do so after fact
[16:05] <seb128> slangasek, since without that we didn't get proper tracking and dropped the ball
[16:06] <utlemming> so it looks like http://changelogs.ubuntu.com is not being updated for Precise. LP: #1005985
[16:09] <cjwatson> utlemming: I believe mvo is about the only person who can do anything about that
[16:10] <cjwatson> unless IS can
[17:59] <scott-work> skaet: did you get a chance to make the topic-q-ubuntu-studio blueprint?  i was hoping to add our blueprints to it
[18:01] <knome> scott-work, you can create that yourself too :)
[18:02] <scott-work> can i?  i shall!
[18:04] <skaet> scott-work,  yup you can,  but I just did it.
[18:04] <skaet> https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-ubuntustudio
[18:04] <knome> heh. :)
[18:05] <scott-work> oh, outstanding, i'll quit the one i was making :)
[18:05]  * knome notes scott-work that he's last, again; https://blueprints.launchpad.net/ubuntu/+spec/topic-quantal-flavor-xubuntu ;)
[18:05] <scott-work> lols, yep
[18:20] <stgraber> SRUs!
[19:10] <knome> skaet, you there?
=== bulldog98_ is now known as bulldog98
[20:40] <stgraber> bdmurray: I thought we agreed at UDS to get rid of the stable/development fix section and just check the bug tasks? (added the sections to my pending srus anyway...)
[20:41] <bdmurray> stgraber: the comment didn't mention either of those only 'statement of impact, test case and regression potential'
[20:42] <bdmurray> stgraber: slangasek should be updateing the SRU wiki page sometime
[20:43] <stgraber> bdmurray: I guess I should have read the comment, just clicked on the URL :)
[20:44] <bdmurray> stgraber: well they really should agree with each other…
[21:29] <cjwatson> xnox: before I forget - I got the LP Debian import cron jobs moved one hour later, which should have the effect of reducing the mean latency by around four to five hours, I think
[22:33] <ScottK> Please don't accept the qt4-x11 binaries before we get a fixed i386 build.
[22:55] <maxb>