=== tumbleweed_ is now known as tumbleweed
[01:22] <cjwatson> stgraber: s/syncSource/copyPackage/
[01:22] <cjwatson> would probably not have timed out
[01:25] <stgraber> cjwatson: I really should change my bookmark for /devel.html... always looking at the stable API makes me miss all the new shiny async ones
[02:10] <jdstrand> hrm, http://status.ubuntu.com/ubuntu-quantal/canonical-security.html is having a problem
[02:12] <jdstrand> we added several blueprints today and moved some stuff out of the existing ones into the new ones, but the new ones aren't showing up
[02:12] <jdstrand> (they aren't in canonical-security.json)
[02:15] <jdstrand> it's weird cause security-q-catch-all-essential was added today, and it showed up but security-q-apparmor-dev-lxc and security-q-apparmor-dev-dbus did not
[02:15] <jdstrand> and security-q-apparmor-dev-essential did not either
[02:16] <jdstrand> actually, security-q-catch-all-essential was not added today
[02:16] <jdstrand> that was added yesterday
[02:16] <jdstrand> anyhoo, heading out, maybe it'll magically work itself out while I am asleep
[02:21] <skaet> jdstrand,  yeah,  I was talking to cjohnston about it earlier,  he's in Hong Kong right now at Linaro connect, so not quite sure how responsive.
[02:21]  * skaet has a bunch of changes that aren't showing up either.
[02:22] <jdstrand> skaet: well, that is good for me. we made a ton of changes today
[02:22] <jdstrand> skaet: and I was worried it might be releated to what we did
[02:22] <jdstrand> skaet: thanks
[02:23] <jdstrand> skaet: do you know if we will be doing a reset anytime soon? istr that happening sometime within a couple weeks of UDS
[02:24] <skaet> jdstrand,  trend lines will be reset right after FeatureDefinitionFreeze
[02:24] <skaet> (if that's what you mean by a reset)
[02:25] <jdstrand> skaet: ok. I was more talking about the ramp up of work items, but that's fine (I also know I can override the trend line)
[02:25] <skaet> ramp up is interesting data too,  so not sure we should loose that.  ;)
[02:26] <jdstrand> that's cool
[02:48] <jbicha> hi, any volunteers to post http://paste.ubuntu.com/1001275/ to the Ubuntu transition tracker?
[04:09] <ScottK> slangasek: Not sure why you're asking me about python-pam. ENOCONTEXT.
[04:23] <slangasek> ScottK: asking you for advice on what to do with respect to the Debian maintenance status, since it's a python module
[04:23] <slangasek> ScottK: since I'm not interested in being the maintainer myself, I don't know if it's appropriate to arrange for its orphaning and, er, "gift" it to the DPMT?
=== yofel_ is now known as yofel
[07:32] <Laney> Daviey: you can go ahead and accept your backport
[07:33]  * micahg didn't think Daviey was an AA
[07:34] <Laney> as of very recently i think
[07:37]  * Laney → research away day. ttyl.
[07:37] <micahg> I see
[08:06] <Daviey> Laney: thanks
[08:45] <tumbleweed> slangasek: if it was gifted to DPMT it'd still need a real maintainer
[08:51] <xnox> tumbleweed: python-pam is nice
[08:51] <xnox> I've used it onces
[08:52] <xnox> it didn't work though and crashed my session and I have fun time trying to regain root again
[08:53] <tumbleweed> xnox: volunteering to maintain it? :)
[08:53] <xnox> nah
[08:53] <xnox> :P
[08:58]  * xnox my dns lookups are funny
[08:58] <xnox> they timeout
[09:04] <Daviey> i used python-pam for yubikey pam integration.
=== popey_ is now known as popey
[10:01] <knome> when's the baseline set for real in status.ubuntu.com ?
[10:03] <tumbleweed> feature definition freeze
[10:04] <knome> k, thanks
[10:12] <ogra_> hmm, running buildlive for daily-preinstalled gets me: "No valid suites to build for"  ... cjwatson do you have any idea wheer that message comes from, i cant find anything related in either cdimage nor debian-cd code
[10:13] <ogra_> oh, might be livecd-rootfs or live-build
[10:13] <tumbleweed> whee, the unstable sync brought in quite a few FTBFSs http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-quantal.html
[10:14] <ogra_> great, there it is
[10:14] <cjwatson> <cjwatson@sarantium ~/src/ubuntu/livecd-rootfs/livecd-rootfs>$ grep 'No valid' *
[10:14] <cjwatson> BuildLiveCD:    echo "No valid suites to build for" >&2 && exit 1
[10:15] <infinity> ogra_: As I pointed out earlier, some of the arm buildds appear to not have quantal chroots yet.
[10:16] <infinity> ogra_: Which would trigger that error.
[10:16] <ogra_> infinity, oh, so i was right, then i'll stop digging, i though you didnt get to it yet
[11:33] <mvo>  we we  fasttrack 5.2.2.1 to -updates to fix bug ##1002271? this is a bit unfortunate (i.e. miscommunication on our part) that the 5.2.2 should have been superseeded instead of going to updates
[11:33] <mvo> eh, s/we we/could we/ ?
[11:38] <seb128> (the said bug is first on errors.ubuntu.com today)
[11:53] <astraljava> skaet: Apologies for sending the mail a little late. But there was not that much to report anyway. I'm going to miss the meeting, too, so if there are any questions for Xubuntu, please let me know and I can get the answers afterwards.
[12:46] <ScottK> slangasek: Ah.  I get it now.  DPMT generally wants someone real associated with each package, so unless you can convince someone to be the warm body associated with it, it's probably not appropriate.
=== elmo_ is now known as elmo
[14:01] <seb128> the release meeting is in one hour right? (just checking I don't have a wrong time, you never know with google calendar and dst)
[14:12] <zul> can someone promote dwarves-dfsg and python-jsonschema for me, it passed the MIR process
[14:13] <skaet> seb128,  yes
[14:13] <skaet> :)
[14:13] <seb128> skaet, hey, thanks ;-)
[14:14]  * skaet busy working through ubuntu-release emails,  so nick highlight if questions.  :)
[14:18] <cjwatson> zul: Are you about to start (build-)depending on them somewhere?
[14:19] <zul> not yet for jsonschema, but yes for dwarves for libvirt
[14:20] <cjwatson> I've promoted dwarves-dfsg then; please ask once you're about ready to start depending on python-jsonschema - if I move it now, it'll show up in the report to be moved back to universe and it's possible we'll have to go through it all again
[14:20] <zul> cjwatson: ack
[14:21] <ev> would someone be so kind as to demote migration-assistant to universe?
[14:21] <cjwatson> ev: ubiquity needs to be uploaded first
[14:22] <cjwatson> Then it should show up in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[14:22] <ev> cjwatson: good call! Apols, I ran around checking the seeds and things and completely forgot about the missing upload
[14:22] <cjwatson> Hm, actually, not ubiquity
[14:22] <cjwatson> It's in the installer seed
[14:23] <ev> oh? I grepped through ubuntu.quantal
[14:23] <cjwatson> platform.quantal
[14:23]  * ev headdesk
[14:23]  * ev fixes
[15:12] <slangasek> tumbleweed, ScottK: ack; I guess I'll try to do that then, after I get barry to bless the actual python3 porting
[15:12] <slangasek> tumbleweed, ScottK: thanks :)
[15:20] <ev> right, migration-assistant is finally in component-mismatches. Would someone kindly send it to universe?
[15:21] <cjwatson> ev: done
[15:21] <ev> cjwatson: thanks!
[15:24] <barry> slangasek: the port looked good to me.  minor comments, but overall 'approved'
[15:33] <slangasek> barry: did you send your minor comments to the mp?  I apparently don't have them yet
[15:34] <barry> slangasek: i did.  i guess it takes some time for lp to process it
[15:34] <slangasek> okie
[15:34] <barry> (responded via email)
[15:47] <ScottK> RAOF or SpamapS: There's cantor, blinken, and an updated kde-workspace in the queue for precise-proposed.  Would one of you please accept.  That'll complete KDE 4.8.3.
=== nhandler_ is now known as nhandler
[16:23] <bjf> skaet, got a load of kernel packages that need to be copied to various places. at least one from -proposed to -updates and some new ones in the ppa
[16:29] <cjwatson> bjf: Shoot
[16:29] <bjf> cjwatson: oneiric 3.0.0-20.34 from -proposed to -updates
[16:31] <bjf> cjwatson: and then there is a list down at the bottom of the pending-sru report: http://people.canonical.com/~ubuntu-archive/pending-sru.html
[16:31] <cjwatson> bjf: Am I meant to ignore that only one of the bugs associated with that kernel upload has verification-done set?  I vaguely recall that there's some other verification process for the kernel, but I don't know it well.
[16:31] <bjf> cjwatson: let me look
[16:32] <cjwatson> Ah, yes, I see the tracking bug ...
[16:32] <bjf> cjwatson: yes, that's where i was heading
[16:32] <cjwatson> So "certification-tracking-passed" is what you use to mean "good to go"?
[16:33] <cjwatson> And am I meant to copy to -security too, per that bug task?
[16:33] <bjf> charlieS: all states except promote-to-updates and promote-to-security are "Fix Released"
[16:33] <cjwatson> Sorry for all the questions; I don't think I've done this for a while
[16:33] <bjf> charlieS: sorry, meant cjwatson
[16:34] <cjwatson> OK, I think I understand
[16:34] <cjwatson> All of "linux linux-backports-modules-3.0.0 linux-meta"?
[16:37] <bjf> cjwatson: yes please
[16:38] <bjf> cjwatson: not that you weren't aware already, but this is the pile of packages we upload fresh every 3 weeks
[16:38] <cjwatson> loosely aware
[16:38] <bjf> it's a crapload
[16:38] <cjwatson> but I wasn't familiar with the details so needed to read up
[16:38] <cjwatson> copied to security/updates
[16:38] <cjwatson> Should I close the bug?
[16:39] <bjf> cjwatson: just mark you task "promote-to-updates" as "Fix Released"
[16:39] <cjwatson> And promote-to-security since I did that
[16:40] <bjf> cjwatson: ack
[16:41] <cjwatson> Done, feel free to check I didn't screw it up
[16:41] <bjf> cjwatson: we have a bot that watches things and flags problems, i'll keep an eye on it
[16:42] <cjwatson> And you want everything in the "Kernel PPA" section
[16:42] <cjwatson> ?
[16:42] <cjwatson> In fact, is it generally safe for me to just act directly on them whenever I see anything in that section, or am I better off waiting for an explicit request?
[16:43]  * skaet sees cjwatson is handling, and goes back to her blueprint wrangling.  thanks cjwatson.
[16:44] <bjf> cjwatson: yes, if it's in the ppa section it can be handled
[16:44]  * skaet nods
[16:44] <cjwatson> Great, knowing that should improve throughput
[16:44] <skaet> generally bjf just pings, when its been ignored for 12 hours.
[16:45] <bjf> skaet: in this case we are at the end of the "prep" week and i want to be ready for the "verification" week
[16:45] <bjf> skaet: i really try to resist nagging, i know people have a lot of other issues they are dealing with
[16:46] <bjf> cjwatson: when we (people with upload rights) can pocket copy from the ppa to -proposed that will help
[16:49] <cjwatson> You can.  Wanna try?
[16:50] <skaet> bjf,  right now with the transition of pitti to his new role,  reminders are welcome, until we sort out the new flow.
[16:51] <cjwatson> It needs approval by an archive admin, but the copy itself shouldn't be a restricted operation any more.
[16:51] <skaet> \o/
[16:52] <cjwatson> Incidentally I'm marking the main (development release) task on the tracking bugs Invalid, per https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed
[16:52] <bjf> cjwatson: ack
[16:52] <cjwatson> And where necessary approving nominations for stable
[16:54] <cjwatson> bjf: So, 'bzr branch lp:ubuntu-archive-tools' and in there run './copy-proposed-kernel.py lucid linux'
[16:54] <bjf> cjwatson: heh, was just about to ask
[16:56] <stgraber> cjwatson: speaking of which, I'm not sure whether https://code.launchpad.net/~stgraber/ubuntu-archive-tools/pkgsets-improvements/+merge/102543 is somewhere on your list of stuff to look at
[16:57] <cjwatson> stgraber: obviously forgot, I'll have a look, thanks
[16:57] <cjwatson> Let me just untangle myself from this pile of stuff first though
[16:59] <cjwatson> bjf: Any luck?
[17:01] <cjwatson> bjf: Also, I went through all the bugs and fixed up a few bug states; the only one that still looks a bit out of the ordinary is bug 951043
[17:01] <ubot2> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/951043
[17:01] <bjf> cjwatson: have not tried, was assuming since i'd asked you, you would do it and i was going to try on the next packages, i can give it a try now though
[17:01] <cjwatson> bjf: You might as well try now
[17:01] <bjf> cjwatson: will do
[17:02] <cjwatson> Oh, also, I'm going to unquiet queuebot now since most of the autosync noise has probably died down
[17:02] <cjwatson> That'll let me see the copies
[17:02] <cjwatson> (heh, I thought I'd done those accepts enough in advance ...)
[17:04] <stgraber> cjwatson: it's looking at the queues every minute
[17:04] <cjwatson> Yeah, I just miscalculated
[17:05] <bjf> cjwatson: script ran, i see it in the upload queue
[17:06] <bjf> there it blows
[17:06] <cjwatson> Yay
[17:07] <bjf> cjwatson: has the issue been fixed so it can't be accidentally copied to universe ?
[17:07] <cjwatson> No, I'll check it by hand
[17:07] <bjf> cjwatson: ack
[17:07] <cjwatson> But from the looks of things I need to wait until it's published
[17:07] <cjwatson> bjf: Can you go right ahead and do the other copies off pending-sru, then?
[17:07] <bjf> cjwatson: yes, i will try to do so
[17:08] <cjwatson> It should all just work for you
[17:16] <cjwatson> stgraber: merged, thanks
[17:17] <stgraber> np. do_copy will be quite useful for the DMB (as for some weird reason, new uploaders want to also be able to upload SRUs ... :))
[20:47] <bjf> cjwatson, bug 1003534 comment #4
[20:47] <ubot2> Launchpad bug 1003534 in kernel-sru-workflow "linux: 3.2.0-25.40 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1003534
[20:48] <bjf> skaet: ^
[20:49] <infinity> bjf: I'll fix.
[20:49] <infinity> cjwatson: disregard bjf. ;)
[20:49] <bjf> infinity: thanks
[20:49] <bjf> indeed
[20:52] <infinity> bjf: So I don't end up doing this 7 times, is it just precise-proposed/linux that has the problem?  No other pockets or source packages?
[20:52] <bjf> infinity: that's all my bot has bitched about so far
[20:54] <infinity> bjf: Alright, fixed in the next publisher run, then.
[20:54] <herton> bjf, infinity: not only linux, but last entries bitch about linux-backports-modules-3.2.0 as well
[20:55] <herton> the packages with 3.2.0-25.10 version are from lbm
[20:55] <infinity> herton: Ahh, thanks.
[20:55]  * infinity fixes that too.
[20:56] <infinity> Silly me, I didn't notice the comment was truncated.
[20:56] <bjf> infinity: so, this is the first time that i ran the copy-proposed-kernel.py script myself. is the problem there or elsewhere ?
[20:56] <infinity> The problem is that that script can't work right without an archive admin to babysit it.
[20:56] <infinity> Did someone imply otherwise?
[20:57] <bjf> cjwatson suggested i was able to run it
[20:57] <infinity> Well, sure.  You are.  Things just end up in the wrong components. :P
[20:58] <bjf> infinity: ok, so i "can" run it, i just "shouldn't"
[20:58] <infinity> (They always do, and we always clean up, but it's less obvious that cleaning up needs to be done if someone else ran the copy)
[20:58] <infinity> Yeah, probably that. :P
[20:59] <infinity> It's three issues compounded that make it irksome.
[21:00] <infinity> The first is that PPAs are flat (not a bug, just a misfeature, IMO), the second is that NEW packages default to the wrong component (IMO, they should default the same component as their source, a bug exists for this), and thirdly, I believe that PPA->proposed copies skip NEW, though maybe that's been fixed.  I haven't done a copy recently.
[21:00] <infinity> If the latter is no longer true, then you can blame the AA who accepted your copy, perhaps.
[21:00] <infinity> But I think there's no change to override in the queue, so it has to be done later.
[21:00] <infinity> s/change/chance/
[21:01] <bjf> infinity: i think this is good information to pass along to cjwatson, skaet and others
[21:04] <cjwatson> bjf: yeah, I'd been having an evening and hadn't had a chance to run the fixer script
[21:04] <cjwatson> infinity: thanks
[21:04] <infinity> I'm not entirely sure why we have a "fixer script".
[21:04] <infinity> linux and lbm are entirely in main.
[21:05] <infinity> That's not rocket science.
[21:05] <bjf> cjwatson: so, do you agree that I really shouldn't be running that script and that it needs the fine touch of an AA ?
[21:05] <cjwatson> I think there's absolutely no reason why you shouldn't continue to run the script yourself.
[21:05] <cjwatson> An AA has to accept it anyway.
[21:05] <infinity> (As in, the "fix" is just to change-override -c main -S linux, there's no logic needed)
[21:05] <cjwatson> It's only that I wasn't around after the publisher run to fix it.
[21:05] <cjwatson> With syncs, we can't override it in the queue.
[21:06] <infinity> cjwatson: With NEW syncs, that really should be fixed...
[21:06] <cjwatson> Anyway, I'm just going to add this to my list of things to fix in LP.
[21:06] <infinity> cjwatson: Is there a bug for that?
[21:06] <cjwatson> Dunno.
[21:06] <cjwatson> I'm mostly watching TV right now. :)
[21:06] <infinity> Still, fixing the default component bug would paper over this issue.
[21:06] <infinity> And that's probably a one-line fix somewhere.
[21:07] <infinity> Well, maybe a few lines.
[21:07] <infinity> But.
[21:07] <cjwatson> bjf: We'd have had the exact same problem if I'd run the script.  It makes no difference.
[21:07] <infinity> Maybe I should make sure the laptop I take to HK has an LP checkout, and I'll try not to drink myself into a stupor on the plane.
[21:07] <cjwatson> infinity: They indeed don't go through NEW; and that's fixable.
[21:07] <infinity> cjwatson: Yeah, I think I noted that it's not the script that's at fault, just that whoever accepts it needs to be aware.
[21:08] <cjwatson> That sais
[21:08] <cjwatson> said
[21:08] <cjwatson> The copy goes through unapproved
[21:08] <cjwatson> With include_binaries=True
[21:09] <cjwatson> We wouldn't want to have to accept twice in a row
[21:09] <bjf> cjwatson, infinity, i'm perfectly fine running the script and will continue to do so
[21:09] <cjwatson> I'll think about this
[21:09] <infinity> cjwatson: You can override in unapproved too.
[21:09] <infinity> cjwatson: You can override in any queue.
[21:09] <cjwatson> The queue entry only contains the PCJ.
[21:09] <infinity> cjwatson: But I'm not sure that syncs are currently overridable.
[21:10] <cjwatson> The binaries aren't visible separately.
[21:10] <infinity> Right.
[21:10] <infinity> That's really the buggy feature, IMO.
[21:10] <infinity> Well, sync representation in the queue is all kinds of misfeatured.
[21:10] <cjwatson> So unapproved, new, makes no difference, it's what's in the queue entry that matters.
[21:10] <cjwatson> Anyway, gone for now :)
[21:11] <infinity> cjwatson: Before you go...
[21:11] <infinity> cjwatson: Did you intentionally not flush all your syncs from the quantal queue?
[21:56] <cjwatson> infinity: Uh.  No.  I've got it in history, I'll try again in a bit
[22:00] <cjwatson> I think that's it
[22:03] <infinity> cjwatson: Ahh, I could have done it, I just wasn't sure if they were sitting there intentionally.
[22:11] <cjwatson> infinity: No, I think I just ran queue accept before the copy jobs had processed but didn't notice