| RAOF | doko: Re bug# 1088771 - I still see two python2.7 uploads in the precise-unapproved queue, not a single merged upload? | 01:16 |
|---|---|---|
| xnox | doko: sorry, lp doesn't let one do that =( noticed the update. | 01:34 |
| ScottK | doko and xnox: It's an open LP bug that you can't re-add a deleted task. | 01:38 |
| === mmrazik is now known as mmrazik|afk | ||
| popey | ScottK: what can we do to move bug 1126205 forward? | 13:25 |
| ubot2 | Launchpad bug 1126205 in libdbusmenu-qt (Ubuntu) "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress] https://launchpad.net/bugs/1126205 | 13:25 |
| ScottK | popey: I'm not at all convinced it should move forward. | 13:25 |
| popey | obviously we want to minimise the impact and not raise other issues.. | 13:26 |
| ScottK | Fundamentally, we moved feature freeze later in the cycle for feature work to get done before it. We said up front we'd generally say no after that. | 13:27 |
| ScottK | So far this one seems not entirely well thought out and I'm not sure the long term implications make it worth while. | 13:27 |
| seb128 | that's an user visible regression though | 13:28 |
| seb128 | qt apps stop having their menus integrated | 13:28 |
| ScottK | That's a separate issue. | 13:28 |
| seb128 | you could argue it was a mistake to land qt5 with the regression and it's a bugfix | 13:28 |
| ScottK | This is about having support extended to Qt5 where it's never existed. | 13:28 |
| ScottK | No, it's a mistake not to have ported appmenu and libdbusmenu to Qt5 properly. | 13:29 |
| seb128 | qt5 est just a new version of qt | 13:29 |
| ScottK | Re-adding the Qt4 design to Qt5 is a gross hack. | 13:29 |
| seb128 | well, there is no room to re-implement that before release | 13:29 |
| knome | are we freezing tomorrow as planned? | 13:31 |
| stgraber | knome: I was hoping for some more release team members to reply to my thread on ubuntu-release@lists.u.c but as it stands, based on current input (mine and ScottK), I'd go with being conservative and freeze tomorrow at 21:00 UTC | 13:37 |
| Riddell | ScottK: yes mediacentre is separate application from active, but I'm thinking it would be useful to run on tablet type devices | 13:40 |
| Riddell | it's not a complete desktop shell as far as I've seen it | 13:40 |
| ScottK | I see. OK then. | 13:41 |
| knome | stgraber, ok, thanks | 13:48 |
| ogra_ | stgraber, i would have commented (since i think your proposal is sound) but i'm not in the release team | 13:48 |
| JackYu | cjwatson: We have uploaded our changes on ubuntukylin-default-settings package. Would you please upload your change and rebuild an iso for testing? | 14:39 |
| cjwatson | JackYu: livecd-rootfs uploaded, thanks - will rebuild a bit later | 14:49 |
| JackYu | cjwatson: great, thank you:) | 14:52 |
| ScottK | seb128 and popey: I approved it. | 14:55 |
| seb128 | ScottK, thanks! | 14:55 |
| * popey hugs ScottK | 14:56 | |
| ScottK | popey: Please note that there's a draft "S" schedule out there. Feature freeze is tentatively August 22nd. Please plan to land stuff well before then. | 14:57 |
| popey | ScottK: noted | 14:59 |
| Daviey | I am right in saying that a *.changes for an SRU that includes two deb versions, say a merge.. must be done with debuild -v, for the bug tasks to be handled appropriately ? | 15:34 |
| ogra_ | Daviey, right | 15:34 |
| ogra_ | (not sure about bug tasks specifically, but thats a general rule for merges) | 15:35 |
| Daviey | That was my thinking, but someone reported tey saw some cleverness with bug numbers being handled from -proposed to -updates. | 15:37 |
| xnox | Daviey: there is some cleverness. But it's best to create correct .changes. I started to call $ debuild -v`oldver`, where oldver is this script http://paste.ubuntu.com/5652578/ | 15:40 |
| xnox | works very quickly, correctly queries target release for me & generates correct .changes for me =) | 15:40 |
| cjwatson | Daviey: almost all the problems with not using -v are fixed | 15:41 |
| cjwatson | pending-sru tracks them and the bugs *usually* get closed | 15:41 |
| Daviey | xnox: yes, i do the same. I referenced it on ubuntu-devel last year. :) | 15:41 |
| cjwatson | the one case I'm aware of where it still doesn't work properly is when the package was not previously in -updates | 15:41 |
| Daviey | cjwatson: So is debian/changelog parsed back to creation ? | 15:42 |
| cjwatson | in that case LP won't properly close the bugs from intermediate versions on copy to -updates | 15:42 |
| cjwatson | Daviey: back to either the last version in -updates if there is one, or failing that only the most recent entry | 15:42 |
| Daviey | it parses back to <= lasyt published version? | 15:42 |
| Daviey | ok, thanks | 15:42 |
| cjwatson | so, IOW, you should use -v if the package was not previously in -updates as an LP bug workaround; otherwise you don't need to bother | 15:43 |
| Daviey | cjwatson: Well, i was more wondering if it's required to reject SRU's not uploaed with -v | 15:43 |
| cjwatson | Daviey: proper use of -v will never hurt, though | 15:43 |
| === medberry is now known as med_ | ||
| ogra_ | using -v also helps people that just read the -changes ML :) | 15:43 |
| cjwatson | ogra_: I think that's also fixed except for the caveat above | 15:44 |
| ogra_ | ah, cool | 15:44 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/1102870 is the remaining bug here | 15:44 |
| ubot2 | Launchpad bug 1102870 in launchpad "Copies use naïve ancestry check to calculate previous version for notifications and bug closures" [High,Triaged] | 15:44 |
| cjwatson | Daviey: I started trying to fix this type of bugs precisely because it really annoys me to have to reject SRUs for trivial things like that :) | 15:44 |
| ogra_ | whhee, with UTF-8 fun in the title | 15:44 |
| Daviey | I wrote parsing for sru-accept based on using the uploaded *.changes. It does break that :) | 15:44 |
| cjwatson | I don't see that in lp:ubuntu-archive-tools ... | 15:45 |
| Daviey | cjwatson: I just wrote it this morning, not yet committed | 15:45 |
| Daviey | but i'll change the logic now. | 15:45 |
| cjwatson | Daviey: then you should just iterate back over all the changes back to the last published version - there's an example of doing that somewhere else in u-a-t | 15:46 |
| Daviey | cjwatson: I did that elsewhere, i have code for that | 15:46 |
| cjwatson | sru-report does it. I think sru-release may need it too | 15:46 |
| cjwatson | Daviey: I would say, if the package is already in -updates you're definitely safe; if not, you're safe if all the bug numbers are only in the most recent version; otherwise I might do something like reject but regen the .changes locally with -v and reupload for them | 15:47 |
| Daviey | cjwatson: Well, i was looking to put this functionally into queue, as 'sruaccept' | 15:47 |
| cjwatson | otherwise it's just kind of an annoying round-trip | 15:47 |
| cjwatson | Daviey: mm, I was wondering if it should be a separate tool to drive the whole review process - bdmurray has a work item for that somewhere ... | 15:47 |
| cjwatson | it should at least be library functionality that could be used by such a tool, IMO | 15:48 |
| Daviey | Oh he does? I was mainly doing this because it sucks to parse for bug numbers by hand. | 15:48 |
| cjwatson | well, queuediff does that for you :) | 15:48 |
| cjwatson | but yeah, it's not entirely ideal | 15:48 |
| cjwatson | Daviey: it's on https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-sru-queue-velocity | 15:49 |
| cjwatson | if you wanted to write a review tool I suspect he wouldn't mind :) | 15:49 |
| Daviey | bdmurray: Have you been able to touch this at all? | 15:50 |
| bdmurray | Daviey: the review tool, no not yet | 15:50 |
| Daviey | bdmurray: I might scratch an itch, if it helps you along - feel free to use it.. otherwise replace it. :) | 15:51 |
| cjwatson | Daviey: I would say a good first step would be, rather than adding "queue sruaccept", change sru-accept to be able to accept the upload and snarf bug numbers out of it before it does the bug processing | 15:51 |
| cjwatson | It makes a bit more sense that way round to me, as queue is kind of supposed to be a pretty thin wrapper around the LP queue operations | 15:52 |
| cjwatson | And I think it's equivalent work, possibly even a bit easier | 15:52 |
| Daviey | cjwatson: well, I was starting to through stuff into an sru-common.py, which does the lifting.. then it can be driven from sru-accept or queue - as preference. | 15:53 |
| Daviey | throw* | 15:53 |
| cjwatson | yeah, that probably makes sense | 15:54 |
| cjwatson | I'm all for libraries | 15:54 |
| xnox | cjwatson: is desktop respinning or still not fully fixed/ready to be respun? | 16:02 |
| cjwatson | respinning | 16:03 |
| xnox | ack. | 16:03 |
| cjwatson | I'm doing all the ones that failed today, meetings permitting | 16:03 |
| stgraber | cjwatson: so I think I'll add that rebuild field to the tracker DB in the next release (maybe for 13.04 still, most likely early 13.10). By default it'll be set to "0" (no rebuild needed), "1" will be rebuild-requested and "2" will be rebuild-in-progress. There will be an authenticated API call to retrieve the list of requested rebuilds and another call to update the status from "1" to "2". | 16:36 |
| stgraber | cjwatson: from the UI point of view, we'll get two buttons, one to request a rebuild and one to cancel a rebuild request (only possible when state = "1" as if it's "2", it's too late to cancel) | 16:36 |
| cjwatson | stgraber: sounds good, thanks | 17:31 |
| cjwatson | for those who weren't on the mumble call in question: this is a plot to make it easier for us to mass-rebuild images by piggybacking on ISO tracker status, and to kill two birds with one stone by using this to implement a way for flavour admins to get a respin by pushing a button on the tracker and waiting for a frequent cron job | 17:32 |
| cjwatson | blam. publish-release now in Python. | 17:33 |
| cjwatson | infinity: so I see you're on duty for publishing beta-2 next week; it might not be a terrible idea to make sure I'm around for the actual publish-release step, since this'll be the first real-world test of that new code and I may have to fix the odd thing up on the fly | 17:35 |
| infinity | cjwatson: Fun, fun. WCPGW? | 17:35 |
| cjwatson | exactly | 17:35 |
| cjwatson | I've unit-tested at least some cases | 17:35 |
| cjwatson | ok, all the other images that failed earlier are respinning now | 17:41 |
| cjwatson | (ubuntukylin, xubuntu, wubi, zh_CN) | 17:41 |
| cjwatson | and I'm going out | 17:41 |
| * slangasek waves | 17:42 | |
| stgraber | utlemming: finally found some time to look into that SSO issue with the QA tracker, hoping to get a fix or at least a clue as to what's going wrong this afternoon | 17:58 |
| utlemming | stgraber: k, let me know, and I'll be happy to do tests | 17:58 |
| stgraber | utlemming: current plan is to dump the xml of the whole openid authentication sequence and check whether it's the tracker not requesting the team membership info or if it's the SSO service sending a partial reply | 18:00 |
| === psivaa is now known as psivaa_afk | ||
| stgraber | utlemming: can I get you to try logging in again? | 18:21 |
| utlemming | stgraber: interesting...I saw the team option | 18:23 |
| stgraber | utlemming: it appears to work fine with my test account here (had to tweak a regexp, I'm suspecting it was eating part of the team name) | 18:23 |
| utlemming | stgraber: and now I see the aministration tag | 18:23 |
| stgraber | utlemming: ok, are you granted the matching rights? (do you see checkboxes next to images and an Administration link in the menu) | 18:23 |
| stgraber | ok, cool | 18:23 |
| stgraber | so looks like that's one problem solved | 18:23 |
| utlemming | stgraber: yeah, this looks good | 18:24 |
| utlemming | thanks :) | 18:24 |
| stgraber | and I tested the API with up to 20 teams and it still works, so apparently SSO itself does the right thing | 18:24 |
| stgraber | ok, so now I can setup access for the Kylin folks | 18:24 |
| stgraber | utlemming: can you remove my test account from the cloud images release team? | 18:28 |
| utlemming | stgraber: sure | 18:29 |
| stgraber | gave myself a WI on foundations-r-future-release-infrastructure to add the required QATracker bits so we can do the whole nusakan<->tracker respin magic | 18:34 |
| stgraber | (targeted to end of April) | 18:34 |
| marrusl | Hi release folks... can I ask someone to look at approving alsa-utils in both the quantal and precise queues? as crazy as it sounds, it's actually blocking some people. :) | 20:15 |
| marrusl | that, and it's really, really a nothing patch. :) | 20:15 |
| stgraber | marrusl: you want the SRU folks actually ;) (but same channel and definitely quite a bit of overlap between the two teams) | 20:17 |
| marrusl | stgraber, ah! good point. hey, at least I got the right channel. ;-) | 20:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!