[01:43] <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:44] <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:47] <infinity> ScottK: I synced it.
[01:47] <infinity> ScottK: How is it breaking things?
[01:48] <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:49] <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:50] <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:51] <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:53] <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:54] <ScottK> infinity: Thanks.
[01:55] <infinity> As soon as I find somewhere with halfway reliable wireless, I'll mangle this.
[01:57] <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> ;-)
[02:06] <skaet> ScottK, lol.
[02:16] <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:17] <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:18] <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:19]  * 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:20] <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:21] <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:25] <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:26] <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:27] <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:28] <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:37] <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:38] <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:41] <micahg> we already have who can upload :) (and in Ubuntu it should rather be called something like who-uploaded)
[04:00] <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:02]  * micahg had assumed that infinity would take care of that when he was free to do so
[04:03] <micahg> he even said so himself :)
[04:06] <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:07] <slangasek> s/we/why/
[04:07] <micahg> not sure, seemed like the saner thing to do would've been to temporarily drop it
[04:08] <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:09] <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:10] <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:11] <micahg> meh, that's not for trunk
[04:16]  * ScottK wonders if micahg should go to bed ...
[04:17] <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:18] <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:19] <micahg> ScottK: I've got about another hour or so before bed
[04:19] <ScottK> OK.
[04:20] <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?
[05:06] <RAOF> ScottK: I think the next step would be to get you some SRU training.
[05:07] <RAOF> Which wouldn't necessarily be much; it just requires a little organisation.
[05:14] <micahg> RAOF: what about bzr in quantal?
[05:37] <RAOF> micahg: Grrr. The time when I *don't* check that the "fix released" in quantal really means fix released in quantal...
[05:38] <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:40] <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.
[06:23] <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
=== tkamppeter_ is now known as tkamppeter
[06:45] <tkamppeter> cjwatson, hi
[08:22] <Laney> I'm trying to work on the bug to display sync uploaders on +source/package
[08:22] <Laney> but, well, LP.
[08:27] <tumbleweed> ScottK: yeah, I've also been thinking we need a who-uploaded tool
[08:47] <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:48] <Laney> ta
[08:48] <tumbleweed> source<->binary resolution is tricky with lplib when the most recent build failed
[08:50] <Laney> could you go back in history until you hit a build with binaries?
[08:52] <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:53] <tumbleweed> that would be handy
[08:54]  * 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:55]  * tumbleweed can't say it's been an issue for me, though
[08:56] <Daviey> xnox: openerp experience you say.... fancy reviewing an openerp packaging branch?
[08:57] <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:58] <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?
[09:05] <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:06] <xnox> Also note. https://bugs.launchpad.net/bugs/+bugs?field.tag=affects-openerp-itp
[09:10] <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:11] <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:14] <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:16] <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:19] <Daviey> ahh, ISWYM.. yeah, in that case, versioned does indeed make sense.
[09:24] <xnox> Daviey: ok.
[11:30] <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:31] <phillw> http://pastebin.com/hq5EhQcn
[11:43] <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:48] <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 :/
[12:02] <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:03] <jibel> phillw, -> #ubuntu-testing
[12:05] <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:06] <tkamppeter> cjwatson, regressions did not turn up.
[12:06] <cjwatson> Great, thans
[12:06] <cjwatson> *thanks
[12:17] <cjwatson> ^- FWIW that last one was an API accept
[12:18] <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)
=== chuck__ is now known as zul
[13:37] <brendand> skaet, is the release meeting in 20 minutes?
[13:38] <seb128> brendand, no, 1:20
[13:38] <brendand> why oh why can't google calendar cope with time zones!
[13:39] <brendand> or DST, whatever it needs to deal with
[13:39]  * tumbleweed has no trouble with it
[13:40] <tumbleweed> (these days)
[13:41]  * 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:57] <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:59] <xnox> infinity: afterall, as long as we have all the relevant .dsc merge is possible ;-)
[14:01] <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:02] <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:03] <tumbleweed> at least it's obviously a foreign time when its several hours out
[14:17] <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:24] <cjwatson> herton: Yes, an archive admin needs to accept it.  I'm looking now.
[14:25] <herton> cjwatson, thanks
[14:43] <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:44] <cjwatson> (Glad to see the problem's solved, anyway)
[14:45] <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:46] <cjwatson> There's that
[14:46] <cjwatson> Oh, regarding auto-syncs
[14:47] <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:48] <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:49] <skaet> bdmurray,  yeah, post in the channel here,  and one of us will handle.
[14:50] <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:51] <bdmurray> Daviey: even to -proposed?
[14:52] <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:53] <cjwatson> ... please wait two minutes and ask that question again ...
[14:54] <cjwatson> ... he is now :-)
[14:54] <cjwatson> (I had a pending mail to get round to)
[14:55] <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!
[15:36] <tkamppeter> cjwatson, anything still missing for the CUPS SRU to go to -updates?
[15:38] <cjwatson> tkamppeter: err - oh, I thought you were talking about the cups-filters upload?
[15:39] <cjwatson> You mean cups itself?
[15:43] <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:44] <Daviey> mvo: 5.2.3 rejected
[15:45] <mvo> ta
[15:49] <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
[16:05] <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:06] <stgraber> please reject ^
[16:06] <stgraber> another one is coming in a few seconds :)
[16:07] <skaet> lxc rejected
[16:10] <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:11] <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:12] <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:13] <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
=== scott-work_ is now known as scott_work
[16:24] <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:55] <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:57] <cjwatson> herton: already fixed, see bug
[16:58] <herton> cjwatson, cool, thanks
[16:59] <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
[17:00] <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:04] <mvo> seb128: right ok
[17:15] <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:16] <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:17] <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:18] <cjwatson> (lp:launchpad/db-devel r11604)
[17:32] <mvo> seb128: thanks again for your input, I uploaded a new 5.2.2.2 now, with proper instructions etc etc
[17:33] <seb128> mvo, thanks
[17:41] <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:42] <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:47] <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:48] <seb128> SpamapS, yes
[17:48] <seb128> SpamapS, the one from yesterday got rejected to let that trivial one in first
[17:49] <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:50] <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:51] <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:52] <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:54] <mvo> uploaded for quantal is building now too
[17:55] <bdmurray> queue isn't showing it yet
[17:55] <bdmurray> er queuediff
[18:23] <tkamppeter> cjwatson, thank you very much.
=== yofel_ is now known as yofel
[19:17] <seb128> bdmurray, SpamapS, slangasek: can we get that SRU in before it's w.e?!
[19:18] <seb128> bdmurray, SpamapS, slangasek: it's a one liner and we get through several update rounds to avoid issues, what's blocking it?
[19:19] <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:20] <bdmurray> I'm looking at it
[19:20] <seb128> bdmurray, thanks
[19:21] <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:22] <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:23] <slangasek> bdmurray: accepted
[19:23] <seb128> slangasek, bdmurray, mvo: thanks
[19:23] <slangasek> bdmurray: any idea why the diff never showed up?
[19:24] <bdmurray> slangasek: it just says pending in the queue - so does euca2ools
[19:24] <bdmurray> nautilus which is #3 works
[19:25]  * mvo hugs slangasek and bdmurray
[19:25] <slangasek> bdmurray: hmm; I guess that needs following up on
[19:26] <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:27] <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:29] <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:30] <skaet> mvo,  wanted to get the monday images having it if possible.
[19:30] <skaet> (from the overnight dailies),  so testing can start.
[19:32] <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:33] <skaet> mvo,  post in the channel when you've done it.   so we know we can build images then.  :)
[19:34] <mvo> oki
[19:35] <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:36] <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:43] <cjwatson> wah, how can u-m ftbfs
[19:44] <cjwatson> sigh, nvidia rearrangements
[19:45] <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:46] <cjwatson> I'm looking
[19:46] <cjwatson> Leave it with me if you like, it's earlier here than there ...
[19:47] <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:48] <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:49] <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:50] <cjwatson> http://paste.ubuntu.com/1018468/
[19:50] <cjwatson> (thought I might as well update the name of the local copy too)
[19:52] <mvo> cjwatson: looks excellent!
[19:53] <cjwatson> OK, uploading shortly then
[19:53] <cjwatson> ta
[20:05] <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:20] <bdmurray> cjwatson: yeah, I'll sort out my local branch
[20:22] <mvo> skaet: still running, but I call it a day now, monday morning it will be
[20:23]  * mvo waves
[20:23] <skaet> thanks mvo
[20:24]  * skaet appears to have missed him.   
[20:24] <skaet> stgraber,  looks like monday morning manual is the plan.  ^
[20:32] <stgraber> skaet: k
[20:34] <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:37] <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:38] <skaet> that should get it on the radar,  other teams will decide what they'll fix.
[20:38] <mdeslaur> skaet: ok, thanks!
[21:36] <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:38] <cjwatson> doing
[21:39] <stgraber> cjwatson: thanks, that one was bothering me every time I'd go through the pending SRUs (as its status was essentially inaccurate) :)
[21:40] <cjwatson> done
[21:40] <cjwatson> I'll remove that tag once the janitor has noticed
[21:41] <cjwatson> (maybe somebody could extend sru-report to support the verification-done-$RELEASE scheme?)
[21:43] <stgraber> I guess that'd be good yes, might do it next week, can't be too difficult
[22:37] <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:43] <cjwatson> right, that's fine - thanks