[07:10] <tumbleweed> ScottK: that'll require a data format change, but yes, I see it would be useful
[07:11] <ScottK> Thanks.
[08:34] <cjwatson> SRU team folks will want to update ubuntu-archive-tools; this makes it so that you don't have to manually accept copies to -updates any more
[08:36] <tumbleweed> would it be possible to have the sru copies into -updates show up in -changes with the original uploader?
[08:43] <seb128> @SRU team: unity is verified, but 2 of the bugs have been set back from verification-done to verification-needed because software-center used the same bug references
[08:44] <seb128> what's the standard way to deal with that? setting them back to -done would make unity green but screw s-c in a symmetric manner
[08:46] <cjwatson> tumbleweed: probably - please file an LP bug
[08:49] <tumbleweed> cjwatson: sure
[09:02] <infinity> tumbleweed: Aww, but I like the inflated stats.
[09:03] <infinity> seb128: Just talk to whomever's SRU day it is, and make them aware of the situation.
[09:03] <infinity> (And yes, using tags, which aren't task-specific, for this is really annoying)
[09:07] <seb128> slangasek, ^ it's your SRU day I think ;-)
[09:08] <infinity> seb128: Oh, but it's Friday, we don't release on Fridays.
[09:08] <infinity> seb128: So, remind me on Monday. :P
[09:08] <seb128> you don't release on fridays? is that a new rule?
[09:09] <infinity> Yeah, newish.
[09:09] <seb128> I had the opposite discussion with slangasek a month ago
[09:10] <infinity> I'm not sure slangasek believes in the "no one's around to fix it if you break it" theory.  But many of the rest of us appear to, and overruled him. :P
[09:10] <seb128> when I said "can I get a review before thursday evening, I want that SRU out this week and would prefer avoid friday's landing" and he replied "why would friday be an issue for an SRU, they are supposed to be tested"
[09:10] <infinity> Erm, a "review" implies it was going from unapproved->proposed?
[09:10] <seb128> though maybe in my case it was a new SRU to be accepted in proposed
[09:10] <seb128> not a move to -updates
[09:10] <infinity> We do that, but not releases to -updates.
[09:10] <seb128> ok
[09:10] <seb128> slackers!
[09:10] <seb128> ;-)
[09:11] <infinity> You'll note it's the manager who ended up on the short shift. ;)
[09:11] <infinity> Sneeeaky.
=== henrix_ is now known as henrix
[11:02] <cjwatson> Daviey: Any chance you could chase down bug 1002248?  The build failures are getting annoying
[11:02] <ubot2> Launchpad bug 1002248 in mythbuntu-default-settings "[quantal] xfce4-utils is deprecated in 4.10" [Undecided,Fix committed] https://launchpad.net/bugs/1002248
[11:10] <Daviey> cjwatson: wilco
[11:11] <cjwatson> thanks
[11:48] <cjwatson> In https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed I have a work item as follows: "ensure that builds to CURRENT/SUPPORTED distroseries get a build score bump over DEVELOPMENT/FROZEN DSes"
[11:49] <cjwatson> Does anyone remember why this was?  I can see arguments either way, and in any event it's surprising that a spec about use of -proposed in the development series would be calling for the development series to be deprioritised
[11:49] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-buildds-usage "Adjust the score for frozen series" was IIRC calling for the priorities of builds in frozen series to be raised
[11:50] <cjwatson> Either way, I'm confused
=== yofel_ is now known as yofel
[13:17] <ScottK> Guessing, since I wasn't there, it seems reasonable that -proposed for the development release shouldn't have the same bump as for earlier release as I can't think of any reasons that are applicable.
[13:18] <ScottK> For post-release propose, you want things built quickly since people run with -proposed and and you want to avoid breaking systems and it's the exact opposite for the development release.
[13:19] <ScottK> For post-release you might have an urgent bug that needs to get built and out the door right away.  For the development release, if that was the case you probably wouldn't be in -proposed.
[13:20] <tumbleweed> yeah, once everything goes into -proposed, stable's -proposed loses its slight advantage
[13:34] <SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/php5/
[13:34] <SpamapS> Can I get an ACK to go ahead and sponsor that debdiff in (for bug 1014044) for precise-proposed ?
[13:34] <ubot2> Launchpad bug 1014044 in php5 "PHP5-FPM not reporting errors to web server (nginx)" [Medium,In progress] https://launchpad.net/bugs/1014044
[13:35] <SpamapS> bug 1006738 is the more important fix
[13:35] <ubot2> Launchpad bug 1006738 in php5 "php5-fpm segfaults with error 4 in libc-2.15.so" [High,In progress] https://launchpad.net/bugs/1006738
[13:35] <stgraber> SpamapS: looking
[13:35] <SpamapS> both really straight forward patches
[13:36] <stgraber> the second bug is missing the usual rationale/testcase/regression potential
[13:37] <stgraber> also, are these affecting default installs? (the main criteria for something to be considered for 12.04.1)
[13:37] <ScottK> For server it's part of the lamp task.
[13:37] <ScottK> So it could be default install.
[13:38] <ScottK> Depends on exactly what you mean by default.
[13:38] <SpamapS> php5-fpm is not part of that task IIRC
[13:38] <SpamapS> Its sort of "the new way" that people are running php
[13:38] <ScottK> Oh.
[13:39] <stgraber> and the first one seems to be nginx specific (based on the title)
[13:39] <SpamapS> its not
[13:39] <SpamapS> any webserver using php5-fpm for fastcgi serving of php will suffer
[13:40] <SpamapS> As far as the test case/reg potential for the segfault.. I'm working on extracting that from the upstream bug report
[14:12] <babyface_> jamespage,  precise-server-ec2-daily are failing .  http://10.98.0.1:8080/view/Precise/view/ISO%20Testing/job/precise-server-ec2-daily/168/
=== arosales1 is now known as arosales
[16:12] <slangasek> infinity: I didn't think I was actually being all that subtle about it ;)
[16:12] <slangasek> seb128: but yeah, as infinity says, we'll publish SRUs to -proposed on friday but not release them to -updates
[16:12] <seb128> slangasek, ok, makes sense
[17:03] <dpm> hi all, I've uploaded the language packs for the upcoming 12.04.1 release, which are now in the unapproved queue. Generally pitti takes care of approving them, but he's away. Could someone help me approving them so that they land in precise-proposed? https://launchpad.net/ubuntu/precise/+queue?queue_state=1
[17:04] <stgraber> ^ as been approved as an exception, so please review even if it was uploaded after the deadline
[17:04] <stgraber> *has
[17:09] <dpm> stgraber, sorry, I just jumped into the channel, are you referring to the langpacks, or something else?
[17:09] <stgraber> dpm: yeah, that comment was for the langpacks so the SRU team knows that they should review it even if it was uploaded after 21:00 UTC yesterday
[17:22] <dpm> anyone around to do the langpacks review?
[17:29] <stgraber> slangasek: ^ (according to the schedule, it's your day ;))
[17:40] <slangasek> yes
[17:40] <slangasek> dpm, stgraber: you're not actually expecting any review of these, right?  since they're quite unreviewable
[17:40] <slangasek> i.e., you just need them accepted, yes?
[17:41] <stgraber> slangasek: yeah, just having them accepted should be enough. IIRC the common problems with the langpacks are missing packages but we'll have that checked with the first Edubuntu build (as it includes all the langpacks)
[17:42]  * slangasek watches to see what the API client does with 820 langpack accepts in one call
[17:43] <dpm> slangasek, pitti generally accepts them after having manually tested one or two of them, which I did as well (running the -ca one now without any noticeable regression)
[17:44] <slangasek> dpm: right, I'll consider that good enough
[17:44] <dpm> cool, thanks
[17:44] <slangasek> now it's just a matter of seeing whether the api client explodes ;)
[17:55] <stgraber> slangasek: I see that one also landed in New, so I guess that one will need accepting + promoting
[17:57] <infinity> stgraber: overriding and accepting, you mean. :P
[17:59] <stgraber> infinity: indeed
[17:59] <infinity> (I took care of the ones in NEW)
[18:00] <stgraber> ^ hmm, wondering if something weird happened on LP or if it's just queuebot getting confused ;)
[18:03] <infinity> stgraber: Maybe queuebot's having issues with the massive langpack-ridden queue?
[18:04] <slangasek> ok, langpacks being accepted now, after tweaking the queue script to not be O(n^2)
[18:04] <slangasek> (https://code.launchpad.net/~vorlon/ubuntu-archive-tools/queue-item-scaling/+merge/118166)
[18:04] <infinity> stgraber: What's the heuristic for "approved"?  Is it actually checking a state, or is it looking for a lack of state (ie: no longer in unapproved, and also not rejected)?
[18:06] <stgraber> infinity: it's returning that if the package is no longer in Unapproved and .status != "Rejected"
[18:06] <stgraber> so yeah, if it only gets a partial set out of LP for some reason, it'd mark them as accepted
[18:06] <infinity> stgraber: Right, that matches the above behaviour for me, then.
[18:06] <infinity> stgraber: I'm guessing it's timing out or otherwise failing to load the massive queue, so things are being "removed", and then "readded" when the next run succeeds.
[18:06]  * ScottK resists the temptation to fix slangasek's grammar in the commit message.
[18:07] <stgraber> infinity: well, if it was actually getting a timeout, it wouldn't do anything and would dump it to the log. The weird thing is that it doesn't seem to timeout.
[18:07] <infinity> stgraber: Is this one of those datasets that "pages" in the API, and you're not paging to the end?
[18:08] <infinity> ScottK: Not a fan of ironic use of poor grammar?
[18:08] <stgraber> I'm currently assuming I'm getting all of them in a single call, but it could be that it's not the case
[18:08]  * stgraber checks the doc for series.getPackageUploads(status=queue)
[18:08] <ScottK> infinity: Are you sure it was ironic?
[18:08] <infinity> ScottK: Knowing slangasek, it almost certainly was.
[18:09] <ScottK> Sure, but it's more fun to ignore that.
[18:10] <infinity> ScottK: Well, even if he wasn't a language nut, he's also in PDX, and everyone there does everything ironically.  It's a bylaw.
[18:10] <slangasek> ScottK: it's not in the commit message, just in the mp ;)
[18:11] <ScottK> OK.
[18:11] <ScottK> You know how much I use merge proposals.  I thought they were the same.
[18:11] <stgraber> mute queue unapproved precise-proposed
[18:11] <stgraber> will unmute once the langpacks are all gone :)
[18:12] <skaet> :)
[18:13] <slangasek> ScottK: I would of course never do bad grammar somewhere /permanent/
[18:13] <ScottK> ;-)
[18:13] <infinity> I'm pretty sure I've used "don't work so good" in changelogs.
[18:15] <slangasek> ok, langpacks all accepted
[18:16] <stgraber> unmute queue unapproved precise-proposed
[18:17] <slangasek> anyone know anything about the firefox in precise-proposed new?
[18:18] <ScottK> Similar to the one in oneiric/natty proposed New as well.
[18:18] <ScottK> IIRC micahg  knows about it.
[18:20] <slangasek> I'm having trouble finding any binaries that are actually new in those uploads
[18:20] <slangasek> so have no idea why they're in the new queue
[18:20] <slangasek> micahg: ^^?
[18:21] <stgraber> slangasek: if you have some time to review unapproved, can you start with live-build and debian-installer?
[18:23] <micahg> slangasek: it's to fix a regression, it should make it into the point release
[18:37] <infinity> slangasek: Anything installed via "apt-get install task^" is considered manual.
[18:37] <slangasek> how unfortunate
[18:37] <infinity> slangasek: That's vaguely by design (and why we use tasks instead of installing the metapackages), but it has some drawbacks, like having the initial set of headers be manual, while all subsequent ones are auto.
[18:38] <slangasek> that implies libraries that are part of tasks will never be correctly autoremoved
[18:38] <infinity> slangasek: It's also unfortunate for libraries.
[18:38] <infinity> slangasek: Yeah.
[18:38] <slangasek> and explains behavior I've seen myself in the past :)
[18:38] <slangasek> anyway, accepted now
[18:38] <infinity> slangasek: The reasoning was that we don't want all of ubuntu-desktop to be autoremoved if you remove the metapackage, but the library behaviour is irksome.
[18:39] <slangasek> yeah, I understand
[18:39] <infinity> (The real solution is probably to not have transitive dependencies in tasks, but that's a Really Hard Problem to solve)
[18:39] <stgraber> infinity: I pushed the matching seed change now that d-i got in -proposed
[18:40] <infinity> stgraber: Danke.
[18:41] <infinity> stgraber: You missed one omap4.
[18:42] <infinity> stgraber: (I tend to just use "echo supported-installer-common installer | xargs sed -i -e 's/oldabi/newabi/g'" for those changes, since computers are much better at this than my old eyes)
[18:42] <stgraber> infinity: gah... fixed
[18:55] <stgraber> slangasek, infinity: cyphermox and I have been trying to get a network-manager upload to the archive (quantal) but it's being silently dropped apparently
[18:55] <stgraber> is there some log you can access to check what's going on or should I poke #launchpad-ops?
[18:56] <infinity> stgraber: "Silenty dropped" usually implies "so broken that it can't effectively reject it".
[18:56] <stgraber> infinity: debdiff: http://paste.ubuntu.com/1127603/
[18:56] <stgraber> .changes: http://paste.ubuntu.com/1127607/
[18:56] <infinity> The diff is less interesting than the actual source and changes.
[18:57] <cyphermox> there's nothing special about it ;)
[18:58] <infinity> It could also be that poppy is having a hissy fit.  Are you uploading via sftp or ftp?
[18:58] <cyphermox> ftp
[18:58] <stgraber> ftp
[18:58] <cyphermox> stgraber tries too
[18:58] <cyphermox> ah
[18:58] <cyphermox> I could try over sftp
[18:58] <infinity> sftp goes through an entirely different set of machinery.
[18:58] <cyphermox> alright
[18:58] <infinity> Though, it's usually the one that's broken. :P
[18:58] <cyphermox> hehe
[18:59] <cyphermox> fwiw I tried via chinstap too, but that didn't change a thing
[18:59] <infinity> I see a bunch in the failed queue.  Sec.
[19:00] <infinity> With zero indication as to why.  Swell.
[19:01] <cyphermox> oh yay
[19:01] <slangasek> ahhh why is queuediff totem showing me a diff between 3.0.1 (in the queue) and 3.3.4 (nowhere near)?
[19:02] <stgraber> slangasek: I also noticed that the LP diff seems to diff against rejected uploads too (like it did with base-files)
[19:04] <slangasek> sigh
[19:05] <infinity> cyphermox: So, are you sure you used a key that's in the Ubuntu keyring?
[19:05] <infinity> cyphermox: (I note you have two keys in LP, you signed the package with the newer one)
[19:06] <cyphermox> yes. the same key as all uploads i've ever done
[19:06] <infinity> Kay.
[19:06] <cyphermox> just tried over sftp; we'll see
[19:06] <stgraber> infinity: that was my first guess and why I asked cyphermox for the source so I could try to sign it myself and upload it
[19:07] <cyphermox> infinity: also, I would have received a rejection message in that case, no?
[19:07] <dpm> ok, time to call it a day. Thanks slangasek and stgraber for taking care of the language packs
[19:07] <stgraber> infinity: interestingly, the exact same source and changes uploaded to a PPA get accepted just fine
[19:07] <dpm> have a great weekend everyone!
[19:07] <stgraber> cyphermox: IIRC, no, invalid GPG key is a silent reject
[19:07] <cyphermox> heh, well, I've been using the same as usual anyway
[19:08] <infinity> Yeah, I re-signed for kicks, and mine also failed.  Time to take this to lp-ops.
[19:09] <slangasek> network-manager hasn't managed to end up in some crazy unusable packageset, has it?
[19:09] <cyphermox> crazy unusable packageset?
[19:10] <cyphermox> NM is uploadable by core, desktop, and network-manager IIRC
[19:11] <slangasek> yes, that's how it's meant to be configured
[19:11] <slangasek> I'm asking if something has gone wrong: )
[19:11] <cyphermox> not that I know of ;)
[19:12] <cyphermox> I wouldn't know where else to look for issues there than edit_acl.py; which reports http://paste.ubuntu.com/1127635/
[19:12] <cyphermox> looks right
[19:12] <stgraber> edit-acl looks happy (in both core and network-manager + generic component upload rights in main)
[19:23] <cyphermox> infinity: did you already bring it up or should I?
[19:25] <infinity> cyphermox: https://oops.canonical.com/?oopsid=OOPS-3ec836710bf79c21af430a2f88cbfc0d
[19:25] <ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=3ec836710bf79c21af430a2f88cbfc0d
[19:25] <infinity> cyphermox: Hope that helps. :P
[19:28] <cyphermox> oh yay
[20:31] <micahg> can someone please deNEW the firefox SRU in natty/oneiric?
=== LordOfTime is now known as TheLordOfTime
[21:08] <slangasek> micahg: done - sorry, it slipped my stack
[21:08] <micahg> slangasek: no problem, thanks, now I can comment in the bug :)
[22:39] <cjwatson> yay, copy-report works from lillypilly
[22:39] <cjwatson> https://launchpad.net/ubuntu/+source/libapache-mod-security/+publishinghistory
[22:40] <jdstrand> \o/
[22:40] <jdstrand> you scared me for a second. I only just pocket copied that a bit ago :)
[22:41] <cjwatson> I trust you didn't copy it to -updates too, and that was indeed a valid test of my machinery
[22:42] <jdstrand> indeed
[22:42] <jdstrand> regular 'ol copy to -security
[22:42] <jdstrand> or is it ol'?
[22:44] <cjwatson> dropping the d at the end not some random letter at the start, I trust
[22:45] <cjwatson> anyhow, that means copy-package.py can die die die
[22:52] <jdstrand> woohoo!
[22:55] <cjwatson> though I get annoying mail about the copies; must fix that ...
[22:59] <cjwatson> Maybe it should not send e-mail when copying between two pockets in the same archive
[23:00] <micahg> it's a nice audit trail
[23:01] <micahg> at least for -proposed -> -updates
[23:01] <cjwatson> Which you didn't have before anyway
[23:01] <cjwatson> At least, copy-package.py never sent mail
[23:01] <cjwatson> You can see the difference in https://lists.ubuntu.com/archives/oneiric-changes/2012-August/thread.html
[23:01] <cjwatson> If you want a proper audit trail, isn't +publishinghistory better?
[23:02] <micahg> sure, but that requires more work AIUI
[23:02] <cjwatson> Hm?
[23:02] <micahg> it shows who copies between proposed and updates?
[23:02] <cjwatson> Yes
[23:02] <infinity> And, some day, +publishinghistory may actually tell me who did what.
[23:02] <cjwatson> Oh, no
[23:02] <cjwatson> It should
[23:03] <micahg> heh
[23:03] <cjwatson> Please file a bug
[23:03] <infinity> I think it probably fits in with the queue audit trail bug.
[23:03] <cjwatson> Still, I don't buy that you suddenly need an audit trail that you never had for the -security => -updates autocopies
[23:03] <cjwatson> infinity: That's more general; I'd prefer a separate one for this
[23:03] <cjwatson> LP already stores this information, so it's just a UI matter of exposing it
[23:04] <micahg> cjwatson: oh, for those we don't need it, it's more useful to see who promoted what to updates
[23:04] <infinity> Which is probably just cargo-culting, then, from how it displays who requested deletions?
[23:05] <cjwatson> >>> pubs[0]
[23:05] <cjwatson> <source_package_publishing_history at https://api.launchpad.net/1.0/ubuntu/+archive/primary/+sourcepub/2595496>
[23:05] <cjwatson> >>> pubs[0].creator
[23:05] <cjwatson> <person at https://api.launchpad.net/1.0/~ubuntu-archive-robot>
[23:05] <cjwatson> ^- example
[23:07] <cjwatson> infinity: I'd need to test, but I rather expect it's about as hard as http://paste.ubuntu.com/1127996/
[23:08] <micahg> Bug #1032857
[23:08] <ubot2> Launchpad bug 1032857 in launchpad "+publishinghistory should show who did the copies" [Undecided,New] https://launchpad.net/bugs/1032857
[23:09] <micahg> I think as a side note, it's nice to see on -changes when SRUs are promoted
[23:09] <infinity> cjwatson: Looks complicated. :P
[23:10]  * cjwatson wonders also why oneiric-changes got two mails
[23:10] <cjwatson> And natty-changes
[23:11] <cjwatson> Doubtless a null copy, but that shouldn't have sent mail
[23:11] <cjwatson> Maybe I should reduce the frequency to hourly as a temp workaround ...
[23:11] <micahg> weirdly, one had content and one didn't
[23:11] <cjwatson> Or maybe copy-report can do a better check for that
[23:11] <cjwatson> Yes, hence my thesis that the second was a null copy
[23:11] <cjwatson> i.e. there was already a pending SPPH in -updates from the first one
[23:11] <cjwatson> but the publisher hadn't completed yet
[23:12] <cjwatson> And indeed I got an OOPS
[23:12] <infinity> Yeah, the publisher is dead slow today.  Langpack days hurt.
[23:12] <micahg> ah
[23:13] <infinity> And libreoffice translation tarballs too.
[23:13] <infinity> All things translations. :P
[23:13] <cjwatson> Ah, it's basically bug 1023372
[23:13] <ubot2> Launchpad bug 1023372 in launchpad "Direct-copying an already-published package OOPSes" [Critical,Triaged] https://launchpad.net/bugs/1023372
[23:13] <cjwatson> Ish