skaet | slangasek, any insight into who might have updated klibc-utils without updating initramfs-tools? seems to be breaking the overnight builds based on what | 01:43 |
---|---|---|
skaet | is sync-ing in from debian. | 01:44 |
ScottK | I'm trying to figure out who sync'ed klibc ^^^ and got stuck by Bug #1007235. Any other suggestions on who to talk to? | 01:44 |
ubot2` | Launchpad bug 1007235 in launchpad "No way to see who sync'ed a pacakge" [Undecided,New] https://launchpad.net/bugs/1007235 | 01:44 |
infinity | ScottK: I synced it. | 01:47 |
infinity | ScottK: How is it breaking things? | 01:47 |
ScottK | klibc-utils : Breaks: initramfs-tools (< 0.103) but 0.99ubuntu13 is to be installed | 01:48 |
infinity | Oh. | 01:48 |
infinity | I didn't do the current sync that introduced that breakage. | 01:48 |
infinity | That was probably an autosync. | 01:48 |
ScottK | I'm sure it was. | 01:48 |
ScottK | It just seemed suprising we'd suddenly be able to sync klibc. | 01:49 |
ScottK | ... surprising ... | 01:49 |
infinity | We merged it all upstream. | 01:49 |
infinity | So... | 01:49 |
infinity | Yay sync. | 01:49 |
infinity | Until now. :P | 01:49 |
ScottK | Great. | 01:49 |
ScottK | Since you TIL, then I think you get to keep both halves of the installability problem ... (I'm certainly not touching initramfs-tools - way beyond me). | 01:50 |
micahg | a proper breaks could be merged upstream if they'll take a control.in file w/rules | 01:50 |
infinity | I have a break in the next hour, I'll look at either cherry-picking the initramfs-tools bit required to make that breaks valid, or drop the breaks. for now. | 01:51 |
infinity | I was going to merge initramfs-tools anyway, but that might not be a one hour job. | 01:53 |
infinity | Let me poke. | 01:53 |
micahg | err..not control.in, but anyways, I"m just making noise here | 01:53 |
ScottK | infinity: Thanks. | 01:54 |
infinity | As soon as I find somewhere with halfway reliable wireless, I'll mangle this. | 01:55 |
ScottK | For the release team meeting tomorrw: http://www.chrisharding.net/wetherobots/comics/2007-11-12-Delegate.jpg.pagespeed.ce.FnV4r2Ng4x.jpg | 01:57 |
ScottK | ;-) | 01:57 |
skaet | ScottK, lol. | 02:06 |
infinity | ScottK: Cherry-picked pseudo-merge uploaded for now for firefighting reasons, I'll look into doing a proper full merge later when I'm not headless chickening here in Hong Kong. | 02:16 |
ScottK | Sounds good. | 02:16 |
ScottK | skaet: ^^^ | 02:16 |
skaet | thanks infinity, Scottk | 02:16 |
ScottK | It would be really nice if we could tell who did the sync... | 02:17 |
infinity | Like I said, it was almost certainly an autosync, since I synced previously. | 02:17 |
infinity | http://paste.ubuntu.com/1017328/ <-- I already uploaded that, but a quick post-review for me? :P | 02:17 |
ScottK | I'm sure. I just couldn't figure out who had done the manual sync. | 02:18 |
infinity | Oh, I did the manual sync. | 02:18 |
infinity | That should be scrapable from -changes. | 02:18 |
infinity | Not sure if there's any other sane location to find that. | 02:18 |
* infinity looks. | 02:19 | |
ScottK | No .changes file for this one. | 02:19 |
infinity | Yeah, native syncs seem to kinda break the audit trail there a bit. :/ | 02:19 |
ScottK | Which is why I filed Bug #1007235. | 02:20 |
ubot2` | Launchpad bug 1007235 in launchpad "No way to see who sync'ed a pacakge" [Undecided,New] https://launchpad.net/bugs/1007235 | 02:20 |
ScottK | Maybe if you whine in the bug a bit too. | 02:20 |
micahg | ScottK: that's a dupe | 02:20 |
ScottK | Of? | 02:20 |
micahg | bug 861488 | 02:21 |
ubot2` | Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488 | 02:21 |
ScottK | Thanks. | 02:21 |
infinity | micahg: Want to eyeball the diff above for me? | 02:21 |
micahg | infinity: sure | 02:21 |
micahg | infinity: looks sane enough assuming those files are properly put there in quantal | 02:25 |
infinity | ScottK: And yeah, like I thought, manual syncs do still hit -changes. | 02:25 |
infinity | ScottK: https://lists.ubuntu.com/archives/quantal-changes/2012-May/001674.html | 02:25 |
infinity | micahg: Hence the klibc-utils dependency bump. | 02:26 |
micahg | infinity: ah, I wasn't sure what created those files ;) | 02:26 |
ScottK | Interesting. | 02:26 |
ScottK | https://launchpad.net/ubuntu/quantal/+source/klibc/2.0~rc5-1 says "No changes file available." | 02:27 |
infinity | ScottK: There isn't one. | 02:27 |
infinity | ScottK: The message on -changes agrees. :P | 02:27 |
ScottK | OK. | 02:27 |
infinity | ScottK: But LP's mails to -changes are LP-specific faff, with .changes appednded (if available). The first bit still gets sent. | 02:28 |
ScottK | Ah. Right. | 02:28 |
infinity | appednded! Typing is hard. | 02:28 |
wgrant | ScottK, infinity: The bug lies; it is visible through the API | 02:37 |
wgrant | See creator_link on https://api.launchpad.net/devel/ubuntu/+archive/primary?ws.op=getPublishedSources&distro_series=/ubuntu/quantal&source_name=klibc&version=2.0~rc5-1 | 02:37 |
wgrant | Although it may not have been at the time the bug was filed. | 02:38 |
wgrant | Because the implementors of the original feature apparently didn't care about making anything traceable in the slightest :) | 02:38 |
ScottK | So now we just need an Ubuntuish version of who-uploads. | 02:38 |
ScottK | tumbleweed: ^^^ Maybe you'd be up for that? | 02:38 |
micahg | we already have who can upload :) (and in Ubuntu it should rather be called something like who-uploaded) | 02:41 |
slangasek | infinity: so, ah, by faking up the version number for initramfs-tools, you've made https://merges.ubuntu.com/i/initramfs-tools/REPORT go away | 04:00 |
slangasek | infinity: and the package has been failing to import into bzr | 04:00 |
* micahg had assumed that infinity would take care of that when he was free to do so | 04:02 | |
micahg | he even said so himself :) | 04:03 |
micahg | slangasek: the problem is the more appropriate 0.103~ubuntu0 wouldn't have validated the breaks in klibc | 04:06 |
slangasek | yes, so we didn't we just fix the breaks in klibc? | 04:06 |
slangasek | s/we/why/ | 04:07 |
micahg | not sure, seemed like the saner thing to do would've been to temporarily drop it | 04:07 |
infinity | slangasek: I intend to merge it shortly anyway, I didn't see the point in having a delta in klibc. | 04:08 |
micahg | wait, sorry, not really saner (a little tired over here) | 04:08 |
infinity | slangasek: And the breaks was valid regardless (as in, I needed to do the cherry-pick and/or merge). | 04:09 |
infinity | slangasek: As for the package failing to import, I'm not entirely sure why that would be. | 04:09 |
micahg | slangasek: the import failure is a couple months old: http://package-import.ubuntu.com/status/initramfs-tools.html#2012-04-11%2000:19:27.544309 | 04:10 |
micahg | meh, that's not for trunk | 04:11 |
* ScottK wonders if micahg should go to bed ... | 04:16 | |
ScottK | Happy mailmain day (just got my first one). | 04:17 |
ScottK | main/man | 04:17 |
ScottK | barry: ^^^ | 04:17 |
micahg | ScottK: well, I'm just testing stuff ATM, so critical thinking isn't pertinent | 04:17 |
micahg | slangasek: and apparently the importer was already broke for that branch as you just imported the last revision that infinity did (for precise) | 04:18 |
micahg | ScottK: I've got about another hour or so before bed | 04:19 |
ScottK | OK. | 04:19 |
ScottK | Back when we were discussing merging the SRU and release teams, I volunteered to join the SRU team to help out. I got a "thanks", but I've no idea what the next step is on that? | 04:20 |
RAOF | ScottK: I think the next step would be to get you some SRU training. | 05:06 |
RAOF | Which wouldn't necessarily be much; it just requires a little organisation. | 05:07 |
micahg | RAOF: what about bzr in quantal? | 05:14 |
RAOF | micahg: Grrr. The time when I *don't* check that the "fix released" in quantal really means fix released in quantal... | 05:37 |
micahg | RAOF: I thought someone said they were going to modify the script to check the version in the dev release | 05:38 |
RAOF | Yes, that was probably me. | 05:38 |
micahg | RAOF: well, you can poke jelmer to do an upload :) (and to not close tasks that aren't done) | 05:40 |
RAOF | Yeah, I will. | 05:40 |
slangasek | infinity: the package fails to import because the importer fails? :) not saying it's your fault, just pointing out that we're now lacking in tools to help with the merge | 06:23 |
=== tkamppeter_ is now known as tkamppeter | ||
tkamppeter | cjwatson, hi | 06:45 |
Laney | I'm trying to work on the bug to display sync uploaders on +source/package | 08:22 |
Laney | but, well, LP. | 08:22 |
tumbleweed | ScottK: yeah, I've also been thinking we need a who-uploaded tool | 08:27 |
Laney | hmm | 08:47 |
Laney | tumbleweed: could it be that seeded-in-ubuntu gives a false negaitive when binaries are OOD? | 08:47 |
Laney | negative | 08:47 |
tumbleweed | yes | 08:47 |
tumbleweed | known issue | 08:47 |
Laney | ok | 08:47 |
tumbleweed | (well, known to me. no bug filed) | 08:47 |
Laney | ta | 08:48 |
tumbleweed | source<->binary resolution is tricky with lplib when the most recent build failed | 08:48 |
Laney | could you go back in history until you hit a build with binaries? | 08:50 |
xnox | tumbleweed: is it just me, or is it unreasonable that binary-publishing-history doesn't have an (optional) field/link to source-publishing-history | 08:52 |
xnox | in the lplib | 08:52 |
xnox | api | 08:52 |
tumbleweed | that would be handy | 08:53 |
* xnox comes from OpenERP background, where the ORM layer trivially supports one2many and many2one back references which are not stored in the database, but computed on-the-fly and servered to the API consumers | 08:54 | |
* xnox wants that from lplib | 08:54 | |
* tumbleweed can't say it's been an issue for me, though | 08:55 | |
Daviey | xnox: openerp experience you say.... fancy reviewing an openerp packaging branch? | 08:56 |
Laney | he's all over that | 08:57 |
xnox | Daviey: I have been, from the sidelines =)))) I have been mentoring yolanda privately to update and fix packaging. I want her to become contributing developer and make sure she helps maitnaining the package. | 08:57 |
xnox | It's my dream to upload openerp =) in a sane way. | 08:57 |
tumbleweed | pish, don't bother with contributing developer. It's not useful just membership | 08:58 |
Laney | DM :-) | 08:58 |
xnox | tumbleweed: it did mean a lot to her =))))) | 08:58 |
xnox | Laney: that as well. | 08:58 |
Daviey | xnox: So i've been trying to help Yolanda aswell.. but time has been an issue.. Have you reviewed her latest branch, post-NEW-rejection? | 08:58 |
xnox | Daviey: not sure. I have been going back and forth with her. I have seen her branch from 2 days ago I believe. | 09:05 |
xnox | Daviey: I said to Yolanda, that I will consider uploading it to Debian. But from my point of view it is not ready yet. | 09:05 |
xnox | Also note. https://bugs.launchpad.net/bugs/+bugs?field.tag=affects-openerp-itp | 09:06 |
Daviey | xnox: So, i haven't had a chance to look at the branch from 2 days ago.. but do you think it is ok? I'mn happy to NEW review it, but i don't want to get too involved in the packaging now, if i am doing that. | 09:10 |
xnox | Daviey: I understand. My concerns are: (I) should we embed javascript libraries or not? (II) should we support 5.0/6.0/7 series or simply conflict? | 09:11 |
Daviey | xnox: Personally, if embedding can be avoided, it should be done.. But there are a host of packages that embed.. so it shouldn't be a blocker if reasonable effort has been done to avoid it... version numbers? You mean versoned package names? Meh, i don't have an opinion either way | 09:14 |
xnox | Daviey: OpenERP S.A. employes a business model - pay to upgrade. So those who are running 5.0/6.0/7 are stuck with it. Unless they do database migration/ETL themselves. So should we ship /usr/share/openerp/ or should we ship /usr/share/openerp/6.1/ | 09:16 |
xnox | in case we will provide other versions in the future. | 09:16 |
Daviey | ahh, ISWYM.. yeah, in that case, versioned does indeed make sense. | 09:19 |
xnox | Daviey: ok. | 09:24 |
phillw | hi guys, we have a problem with the Mac iso's for lubuntu. The testers cannot ascertain fully what is causing it as there are no logs that they can use to view the issues? | 11:30 |
phillw | http://pastebin.com/hq5EhQcn | 11:31 |
cjwatson | "Nothing in the logs" - sometimes if you aren't familiar with the installer you can miss things. That's why I always encourage people to post logs even if they don't see anything in them themselves | 11:43 |
phillw | cjwatson: hiyas, the guys reporting it are experienced testers. I've asked that they raise a bug, but as it is not installing such details are not going to be there! | 11:48 |
phillw | if it cannot even partition, then there will be no logs :/ | 11:48 |
cjwatson | phillw: Untrue | 12:02 |
tkamppeter | cjwatson, hi | 12:02 |
cjwatson | tkamppeter: hello | 12:02 |
jibel | phillw, logs are stored during installation in /var/log/syslog and /var/log/installer/* | 12:02 |
cjwatson | phillw: And /var/log/partman | 12:02 |
jibel | phillw, -> #ubuntu-testing | 12:03 |
tkamppeter | cjwatson, I have sorted out the CUPS SRU for Precise now. All referenced bugs are either verified for the Precise SRU or reopned/made invalid for Quantal as it turned out that the changes do not cover them. | 12:05 |
tkamppeter | cjwatson, regressions did not turn up. | 12:06 |
cjwatson | Great, thans | 12:06 |
cjwatson | *thanks | 12:06 |
cjwatson | ^- FWIW that last one was an API accept | 12:17 |
cjwatson | I need to make at least one more improvement to the API before I'm prepared to get people to start using a client tool for that, though | 12:18 |
cjwatson | (At the moment, there's no sensible way to filter getPackageUploads short of iterating over everything it returns) | 12:18 |
=== chuck__ is now known as zul | ||
brendand | skaet, is the release meeting in 20 minutes? | 13:37 |
seb128 | brendand, no, 1:20 | 13:38 |
brendand | why oh why can't google calendar cope with time zones! | 13:38 |
brendand | or DST, whatever it needs to deal with | 13:39 |
* tumbleweed has no trouble with it | 13:39 | |
tumbleweed | (these days) | 13:40 |
* ogra_ neither ... it properly shows the meeting at 5pm central european time here | 13:41 | |
tumbleweed | (then again, I also live in a country that doesn't bother with DST, so the meeting time does move around a bit for me) | 13:41 |
infinity | slangasek: I tend to merge packages like that fairly manually anyway, as they require a pretty careful audit, so I'm not really fussed about automated tools having a sad. | 13:57 |
xnox | infinity: afterall, as long as we have all the relevant .dsc merge is possible ;-) | 13:59 |
xnox | tumbleweed: brendand: on the foundations team wiki I have put this (to work around google calendar's brokeness): Held weekly at 1600 UK time BST/GMT (Afternoon tea time) Wednesdays on #ubuntu-meeting @ freenode. | 14:01 |
xnox | http://en.wikipedia.org/wiki/Tea_(meal)#Afternoon_tea | 14:01 |
brendand | xnox, what's weird is if i actually add it to my calendar it says 1600! | 14:01 |
brendand | xnox, but in the creation screen it still says 1500 | 14:01 |
xnox | brendand: yeap. Internally google calendar stores the meetings in the timezone of the event creator, respecting DST changes. | 14:02 |
* xnox bets that screws over the meeting times for anyone in like china/japan/australia | 14:02 | |
tumbleweed | at least it's obviously a foreign time when its several hours out | 14:03 |
herton | cjwatson, hi, I used copy-proposed-kernel.py to try to sync precise ti-omap4 from bug 1004555, from kernel ppa to -proposed, but since yesterday it's sitting on the queue (https://launchpad.net/ubuntu/precise/+queue?queue_state=1). Is there something someone should do to complete it? | 14:17 |
ubot2` | Launchpad bug 1004555 in linux-ti-omap4 "linux-ti-omap4: 3.2.0-1414.19 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004555 | 14:17 |
cjwatson | herton: Yes, an archive admin needs to accept it. I'm looking now. | 14:24 |
herton | cjwatson, thanks | 14:25 |
cjwatson | skaet: FWIW, regarding "who might have updated klibc-utils" - yes, it was an auto-sync. I'm not going to get into manually reviewing auto-syncs for possible problems. Also, shouldn't we be thinking first about getting the problem solved, and only a distant second about whom to blame? :-) | 14:43 |
cjwatson | (Glad to see the problem's solved, anyway) | 14:44 |
skaet | cjwatson, certainly don't expect manual reviewing of the auto-syncs. ;) just trying to figure out who might have a clue about how to sort it. Infinity handled, all good. | 14:45 |
Daviey | I'll admit, when syncing out Ubuntu delta's.. i don't tend to look *too* closely if the Debian version is going to introduce issues.. as the way i see it, if it didn't have a Ubuntu delta, it would have been auto-sync'd. | 14:45 |
cjwatson | There's that | 14:46 |
cjwatson | Oh, regarding auto-syncs | 14:46 |
cjwatson | I'm going to be away for the weekend; I'll have my phone with me, but I haven't managed to get launchpadlib authentication working when sshed into my laptop, so I don't know whether I'll be able to run auto-syncs | 14:47 |
cjwatson | Perhaps somebody who's going to be around could occasionally run it? | 14:47 |
cjwatson | And by "the weekend", I mean "until Tuesday", since we have a double bank holiday here | 14:48 |
bdmurray | I was gonna look at the SRU queue. If I say what I want approved will someone do it? | 14:48 |
cjwatson | I just blacklisted most of the stuff that's whining regularly, so you don't have to be aware of that; there are a couple of packages that have been removed and it's not clear whether they should be reintroduced, but auto-sync defaults to "no" for those so if you just hit enter it should DTRT | 14:48 |
skaet | bdmurray, yeah, post in the channel here, and one of us will handle. | 14:49 |
bdmurray | I'd accept unity-lens-video | 14:50 |
cjwatson | Due to bug 1006917, which I discovered when trying to automate this, you do need to be in ubuntu-core-dev as well as in ubuntu-archive to run auto-syncs. | 14:50 |
ubot2` | Launchpad bug 1006917 in launchpad "Distribution archive owners cannot necessarily copy packages" [Low,Triaged] https://launchpad.net/bugs/1006917 | 14:50 |
Daviey | bdmurray: i'd suggest publishing SRU's over the weekend has bad karma attached to it.. heck, even Friday's. | 14:50 |
bdmurray | Daviey: even to -proposed? | 14:51 |
skaet | Daviey, good point. bdmurray, batch up a list for -release and we'll clean them up on monday? | 14:52 |
Daviey | bdmurray: no, -proposed seems safe to me.. Are you now ~ubuntu-sru ? | 14:52 |
cjwatson | ... please wait two minutes and ask that question again ... | 14:53 |
cjwatson | ... he is now :-) | 14:54 |
cjwatson | (I had a pending mail to get round to) | 14:54 |
Daviey | cjwatson: gotta love open processes :) | 14:55 |
cjwatson | hey, the existing team trained him, said he was ready | 14:55 |
Daviey | works for me! | 14:55 |
tkamppeter | cjwatson, anything still missing for the CUPS SRU to go to -updates? | 15:36 |
cjwatson | tkamppeter: err - oh, I thought you were talking about the cups-filters upload? | 15:38 |
cjwatson | You mean cups itself? | 15:39 |
mvo | if someone could reject the 5.2.3 upload of software-center to precise-proposed that would be nice, there is a 5.2.2.2 with a trivial tweak to the startup time query to the software-center-agent data uploaded now. this is important for the humble bundle integration and really trivial (just tweaking the delay from 30s to 3s) | 15:43 |
mvo | and a review of 5.2.2.2 if possible, it will improve the user experience quite a bit for the humble bundle buyeers | 15:43 |
Daviey | mvo: 5.2.3 rejected | 15:44 |
mvo | ta | 15:45 |
cjwatson | tkamppeter: OK, cups published now. The janitor will close the bugs you've "disconnected", so you'll need to reopen them after it's done that | 15:49 |
stgraber | SRU: I just spotted a regression in the lxc package currently in -proposed. I fixed that regression in quantal and uploaded a new version of the package to -proposed. The fix is trivial (reversed logic in shell script), so would really appreciate it if it could go in ASAP, thanks. | 16:05 |
stgraber | oh, but I forgot to use -v for that upload .... | 16:05 |
* stgraber reuploads | 16:05 | |
skaet | :) | 16:05 |
stgraber | please reject ^ | 16:06 |
stgraber | another one is coming in a few seconds :) | 16:06 |
skaet | lxc rejected | 16:07 |
seb128 | mvo, do you need 5.3 rejected or just do be delayed to after 0.5.2.2 is dealt with? | 16:10 |
seb128 | oh, Daviey already rejected it so ignore that ;-) | 16:10 |
cjwatson | seb128: doesn't matter since we can unreject anyway | 16:10 |
stgraber | and the good one ^ | 16:11 |
seb128 | cjwatson, right | 16:11 |
seb128 | did anyone in the SRU team saw mvo's request earlier to review the 5.2.2.2 update and can get to it today? | 16:11 |
seb128 | would be a shame to delay the fix to next week when those games got advertized around and probably quite some users will install them ;-) | 16:12 |
seb128 | mvo, you probably want a bug report associated with the upload | 16:13 |
seb128 | (just looked to the diff) | 16:13 |
seb128 | mvo, the changelog doesn't have one | 16:13 |
=== scott-work_ is now known as scott_work | ||
ogra_ | skaet, bug 1007512 ... i made it low prio though | 16:24 |
ubot2` | Launchpad bug 1007512 in live-build "building arm livefs proceeds even though flash-kernel is unavailable" [Low,New] https://launchpad.net/bugs/1007512 | 16:24 |
herton | cjwatson, linux-ti-omap4 3.2.0-1414.19 also ended in universe in -proposed instead of main (bug 1004555), similar to what happened to ti-omap4 in oneiric | 16:55 |
ubot2` | Launchpad bug 1004555 in linux-ti-omap4 "linux-ti-omap4: 3.2.0-1414.19 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004555 | 16:55 |
cjwatson | herton: already fixed, see bug | 16:57 |
herton | cjwatson, cool, thanks | 16:58 |
mvo | seb128: yeah, there is no bugreport right now, I can fix that, but really its a trivial one line diff from -30s to +3s | 16:59 |
seb128 | mvo, I'm trying to help you, they started rejecting any SRU which doesn't have a testcase, regression potential and impact on its description | 16:59 |
seb128 | mvo, so I guess one without bug reference has no chance to get approved | 17:00 |
seb128 | mvo, i.e not my call but I suggest you get a bug with the things I list in the description | 17:00 |
mvo | seb128: right ok | 17:04 |
slangasek | cjwatson: so bdmurray was asking about direct queue access as an SRU team member... are we putting people through full AA training for that? | 17:15 |
ScottK | slangasek: I thought not, but with an understanding that they wouldn't touch New stuff. IIRC SpamapS started out that way. | 17:16 |
* slangasek nods | 17:16 | |
slangasek | I see that RAOF and SpamapS are both in ~ubuntu-archive | 17:16 |
cjwatson | they got full training AIUI though? | 17:17 |
cjwatson | or maybe I'm misremembering | 17:17 |
slangasek | RAOF, SpamapS: did you get full AA training? :) | 17:17 |
cjwatson | We don't have much more flexibility until I get bug 648611 fixed | 17:17 |
ubot2` | Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611 | 17:17 |
slangasek | yep | 17:17 |
cjwatson | Although the DB patch for that has landed, so maybe I can move that up | 17:17 |
bdmurray | I thought not based off the release team consolidation email | 17:17 |
cjwatson | (lp:launchpad/db-devel r11604) | 17:18 |
mvo | seb128: thanks again for your input, I uploaded a new 5.2.2.2 now, with proper instructions etc etc | 17:32 |
seb128 | mvo, thanks | 17:33 |
seb128 | SpamapS, cjwatson, slangasek: could one of you review the s-c SRU mvo just did today, it's a 1 liner and as he described "it will improve the user experience quite a bit for the humble bundle buyeers" | 17:41 |
seb128 | i.e would be nice to get it in proposed before the w.e | 17:42 |
mvo | I added some more context info the bug description, hope its clear now what the beneifts are | 17:42 |
slangasek | bdmurray: ^^ any chance you could review this? I'm happy to push the button, but don't have time at the moment to look | 17:47 |
SpamapS | seb128: does it supersede the big one uploaded yesterday? | 17:47 |
seb128 | SpamapS, yes | 17:48 |
seb128 | SpamapS, the one from yesterday got rejected to let that trivial one in first | 17:48 |
SpamapS | seb128: gotchya. It also needs to be uploaded to quantal. | 17:49 |
seb128 | mvo, ^ | 17:49 |
SpamapS | rmadison may be lying to me tho | 17:49 |
mvo | SpamapS: there is no quantal version yet, so it can just be copied | 17:49 |
seb128 | mvo, they stopped doing pocket copies | 17:49 |
SpamapS | mvo: we're pretty late in the cycle. Are you sure thats still safe? | 17:50 |
mvo | oh, ok | 17:50 |
mvo | in this case I can upload it | 17:50 |
slangasek | well, it is safe in this case because it's arch: all python | 17:50 |
mvo | no problem | 17:50 |
SpamapS | toolchain changes and all | 17:50 |
slangasek | but it's simpler if mvo can just upload | 17:50 |
mvo | I will do anything that helpls this SRU | 17:50 |
mvo | (anyone wants a cup of tea?) | 17:50 |
SpamapS | debhelper has advanced too.. not sure if that really matters. :-P | 17:50 |
slangasek | it really shouldn't | 17:51 |
slangasek | :) | 17:51 |
seb128 | mvo, just change the changelog target, debuild -S and dput :p | 17:51 |
slangasek | target /and version number/ ;) | 17:51 |
mvo | old school, bzr-buildpackage ;) | 17:51 |
seb128 | hehe | 17:51 |
SpamapS | bdmurray: ^^ review away sir | 17:51 |
SpamapS | oh and there are two different ones in the proposed queue.. one from 2 hours ago, one from 15 min or so | 17:51 |
mvo | right, the 15min version has a bugnumber | 17:52 |
seb128 | SpamapS, the most recent one has a bug reference that the previous didn't have | 17:52 |
seb128 | i.e reject the old one | 17:52 |
SpamapS | ok | 17:52 |
mvo | seb128 correctly pointed out I should do it the right way | 17:52 |
slangasek | rejected | 17:52 |
seb128 | thanks | 17:52 |
mvo | uploaded for quantal is building now too | 17:54 |
bdmurray | queue isn't showing it yet | 17:55 |
bdmurray | er queuediff | 17:55 |
tkamppeter | cjwatson, thank you very much. | 18:23 |
=== yofel_ is now known as yofel | ||
seb128 | bdmurray, SpamapS, slangasek: can we get that SRU in before it's w.e?! | 19:17 |
seb128 | bdmurray, SpamapS, slangasek: it's a one liner and we get through several update rounds to avoid issues, what's blocking it? | 19:18 |
seb128 | the bug should be in shape, the update is a one liner, the fix is in quantal ... what is missing? | 19:19 |
bdmurray | the diff shows as pending but I guess we could *gasp* manually do it | 19:19 |
bdmurray | in the queue page | 19:19 |
bdmurray | I'm looking at it | 19:20 |
seb128 | bdmurray, thanks | 19:20 |
bdmurray | and w.e.? I have four hours or so left | 19:21 |
seb128 | bdmurray, well, I know how things are going, I'm sure 90% of the SRU queue will still be there on monday ;-) | 19:21 |
seb128 | we just want to make sure that one goes in today | 19:22 |
bdmurray | slangasek: I'd approve software-center if I could | 19:22 |
bdmurray | SpamapS: ^ | 19:22 |
seb128 | bdmurray, thanks ;-) | 19:22 |
seb128 | mvo, ^ | 19:22 |
slangasek | bdmurray: accepted | 19:23 |
seb128 | slangasek, bdmurray, mvo: thanks | 19:23 |
slangasek | bdmurray: any idea why the diff never showed up? | 19:23 |
bdmurray | slangasek: it just says pending in the queue - so does euca2ools | 19:24 |
bdmurray | nautilus which is #3 works | 19:24 |
* mvo hugs slangasek and bdmurray | 19:25 | |
slangasek | bdmurray: hmm; I guess that needs following up on | 19:25 |
slangasek | maybe it's due to load from the humble bundle :P | 19:26 |
bdmurray | heh | 19:26 |
bdmurray | slangasek: did you run sru-accept? I've a local change I wanted to test | 19:26 |
slangasek | I hadn't, I just did the queue accept | 19:27 |
slangasek | what's the bug #? | 19:27 |
bdmurray | I'll do it | 19:27 |
slangasek | oh, you have a local change, right :) | 19:27 |
slangasek | please go ahead | 19:27 |
skaet | mvo, can you do a GnomeAppInstallDesktopDatabaseUpdate | 19:29 |
skaet | Alpha 1 next week... | 19:29 |
mvo | skaet: will monday be good enough? | 19:29 |
* mvo will also do command-not-found and a debian-package-description update | 19:29 | |
skaet | mvo, wanted to get the monday images having it if possible. | 19:30 |
skaet | (from the overnight dailies), so testing can start. | 19:30 |
skaet | if you can't get it done today, first thing on monday? | 19:32 |
mvo | skaet: heh :) I start the extraction run now, if it finishes before my bedtime I do it today, otherwise monday morning. deal? | 19:32 |
skaet | deal. :) | 19:32 |
skaet | mvo, post in the channel when you've done it. so we know we can build images then. :) | 19:33 |
mvo | oki | 19:34 |
mvo | it usually takes some time (~1-4h depending on the amount of data it needs to download) | 19:35 |
stgraber | mvo, cjwatson: Any progress on getting do-release-upgrade working by alpha1? | 19:35 |
mvo | stgraber: it should be close now, I prepeared the meta-release-development update and the new version works for me(tm) and is uploaded, but I think there was a ftbfs | 19:36 |
cjwatson | wah, how can u-m ftbfs | 19:43 |
cjwatson | sigh, nvidia rearrangements | 19:44 |
mvo | yeah, just noticed that too, I have no clue what happend with the "obsolete" nvidia pkg names if it just got killed entirely or just reshuffled :/ | 19:45 |
cjwatson | I'm looking | 19:46 |
cjwatson | Leave it with me if you like, it's earlier here than there ... | 19:46 |
mvo | hrm, hrm, it looks like its simply not installing it, the textfile is still in the 0.2.44 tarball | 19:47 |
mvo | cjwatson: thanks a lot, that would be great, its really getting late(ish) | 19:47 |
cjwatson | but current version is .53 | 19:47 |
cjwatson | (moved into ubuntu-drivers-common) | 19:47 |
mvo | heh :) | 19:48 |
cjwatson | ah, looks like it's just moved to /usr/share/ubuntu-drivers-common/obsolete | 19:48 |
mvo | good point! | 19:48 |
mvo | cjwatson: are you fixing it alreay in u-m or shall I? now that I know the updated location its pretty quick for me, but if you have stated already I am happy of course | 19:49 |
cjwatson | I've started | 19:49 |
mvo | cool, I leave it for you then | 19:49 |
mvo | thanks again! | 19:49 |
cjwatson | though quick review? | 19:49 |
cjwatson | http://paste.ubuntu.com/1018468/ | 19:50 |
cjwatson | (thought I might as well update the name of the local copy too) | 19:50 |
mvo | cjwatson: looks excellent! | 19:52 |
cjwatson | OK, uploading shortly then | 19:53 |
cjwatson | ta | 19:53 |
cjwatson | bdmurray: sru-accept-web-links might have been better branched fresh from lp:ubuntu-archive-tools rather than from your previous branch - it has conflicts | 20:05 |
cjwatson | bdmurray: but I'll merge it and drop out the conflicts | 20:05 |
bdmurray | cjwatson: yeah, I'll sort out my local branch | 20:20 |
mvo | skaet: still running, but I call it a day now, monday morning it will be | 20:22 |
* mvo waves | 20:23 | |
skaet | thanks mvo | 20:23 |
* skaet appears to have missed him. | 20:24 | |
skaet | stgraber, looks like monday morning manual is the plan. ^ | 20:24 |
stgraber | skaet: k | 20:32 |
mdeslaur | hey 12.04.1 team, how do I mark a bug that should get fixed in 12.04.1? | 20:34 |
mdeslaur | ie: bug 755842 | 20:34 |
ubot2` | Launchpad bug 755842 in compiz-wall-plugin "Non-maximized windows which sit on the border of a workspace move when called" [Medium,Fix committed] https://launchpad.net/bugs/755842 | 20:34 |
skaet | mdeslaur, milestone it to 12.04.1 and nominate it to series precise | 20:37 |
mdeslaur | skaet: am I allowed to do that for bugs that are obviously for other teams? | 20:37 |
skaet | that should get it on the radar, other teams will decide what they'll fix. | 20:38 |
mdeslaur | skaet: ok, thanks! | 20:38 |
stgraber | Could an SRU team member copy libgcrypt11 from precise-proposed to precise-updates? It's been confirmed in the bug (verification-done-precise) and is 14 days old. Thanks | 21:36 |
cjwatson | doing | 21:38 |
stgraber | cjwatson: thanks, that one was bothering me every time I'd go through the pending SRUs (as its status was essentially inaccurate) :) | 21:39 |
cjwatson | done | 21:40 |
cjwatson | I'll remove that tag once the janitor has noticed | 21:40 |
cjwatson | (maybe somebody could extend sru-report to support the verification-done-$RELEASE scheme?) | 21:41 |
stgraber | I guess that'd be good yes, might do it next week, can't be too difficult | 21:43 |
tkamppeter | cjwatson, all cups bugs disconnected from the SRU are corrected now, except bugs which are marked duplicate, as there I do not get the menu to change status. | 22:37 |
cjwatson | right, that's fine - thanks | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!