[00:17] <StevenK> wgrant: I'm reviewing a branch of allenap's. Isn't there an already defined ACTIVE_PUBLISHING_STATES that is PENDING, PUBLISHED already?
[00:19] <wgrant> StevenK: It's active_publishing_status
[00:20] <poolie> hi all
[00:20] <poolie> can someone confirm that it's possible for ubuntu developers to rebind the lp:ubuntu/oneiric/foo alias onto a different branch?
[00:20] <poolie> they do that through the web ui?
[00:20] <StevenK> wgrant: Ah! Thanks!
[00:21] <wgrant> poolie: They can do it through the API.
[00:21] <poolie> ah i see
[00:21] <poolie> is there a tool for that?
[00:21] <wgrant> It was restricted to ~ubuntu-branches until like a month ago
[00:21] <poolie> or a web page describing it?
[00:21] <wgrant> No.
[00:22] <wgrant> It's not a supported workflow.
[00:22] <wgrant> The only reason it's no longer restricted to two people is to remove the celebrity.
[00:22] <wgrant> You would need to talk to the UDD people about whether that should be supported.
[00:22] <poolie> i'm thinking in particular about https://lists.ubuntu.com/archives/ubuntu-devel/2011-July/033777.html
[00:23] <wgrant> poolie: That's a debian-only branch.
[00:23] <wgrant> Last I heard the policy was that official package branches must be complete.
[00:24] <wgrant> Regardless, this is not a Launchpad issue.
[00:24] <wgrant> This is UDD policy.
[00:24] <poolie> :/
[00:25] <lifeless> so the reason for completeness is reproducability
[00:25] <lifeless> debian only branches are entirely lacking there
[00:25] <poolie> i don't think "not a launchpad issue" is a very productive attitude
[00:25] <wgrant> Hm?
[00:25] <wgrant> How not?
[00:25] <wgrant> This is a policy that was set by james_w and co.
[00:25] <poolie> if people are having trouble manipulating ubuntu source, it at least touches on lp
[00:25] <wgrant> Launchpad doesn't set UDD policy...
[00:26] <poolie> it may not be something that ends up being changed in lp
[00:26] <wgrant> Also, everybody that went near UDD has since left Launchpad.
[00:26] <wgrant> bzr or whoever replaced james_w is probably better.
[00:26] <poolie> anyhow, i will talk about it with luke
[00:27] <poolie> i'm not saying "~launchpad must solve this"
[00:27] <poolie> only that i think it's reasonable to ask about it here
[00:28] <wgrant> We can answer technical questions about our dodgy implementation of package branches.
[00:28] <wgrant> But most of this stuff is UDD policy.
[00:28] <wgrant> Which has never had much to do with the LP team.
[00:28] <wgrant> So we are not exactly well-placed to answer questions.
[00:29] <poolie> so, as far as the narrow question
[00:29] <poolie> it is theoretically possible to rebind ubuntu branch aliases, but this should never be done?
[00:29] <poolie> (i realize this won't be actually useful in this case)
[00:29] <wgrant> It is possible (the importer does it).
[00:30] <lifeless> it should be done if the official branch is being entirely replaced
[00:30] <lifeless> but it would be extremely unusual and need notificatoin of some sort to anyone with pending merges, checkouts,e tc
[00:31] <wgrant> The relevant API call is source_package.setBranch.
[00:31] <lifeless> uhm, thats too strong
[00:31] <wgrant> Anybody with upload privileges should be able to do it.
[00:31] <wgrant> But, as lifeless says.
[00:31] <lifeless> its expected that when someone starts working with UDD, that the package they are workig on may involve their higher-fidelity branch replacing the importers branch.
[00:32] <poolie> right
[00:32] <lifeless> but all the branches need to be the same as what the importer creates, or it will stomp over them
[00:32] <lifeless> e.g. full rather than debian only
[00:32] <poolie> though, probably they could just push overwrite the importer's branch, rather than changing the name
[00:32] <poolie> maybe not
[00:32] <lifeless> right
[00:32] <lifeless> a reason to rebind is to get to a branch in the ubuntu namespace
[00:33] <lifeless> rather than in /~ubuntu-branches/ubuntu-branches/... or whatever the workaround before distro namespaces existed was
[00:36] <wgrant> Huh.
[00:36] <wgrant> PackageBugSupervisor
[00:37]  * wgrant demolishes.
[00:42] <StevenK> wgrant: There is a table too
[00:42] <wgrant> Yes.
[00:43] <wgrant> I fear I may need to drop the foreign key in an initial branch, drop the code in a second, and move the table away in a third.
[00:43] <wgrant> So this can wait until we have the process sorted out :/
[00:43] <lifeless> vat is dis ?
[00:45] <wgrant> Table that has been obsolete since like 2007.
[00:45] <wgrant> It's empty.
[00:45] <lifeless> oo
[00:45] <lifeless> clean out da cwap
[00:46] <wgrant> I think I need to drop the foreign key before I can delete the code :(
[00:46] <wgrant> Because of person merges.
[00:46] <lifeless> yes
[00:46] <wgrant> Tests will blow up if they don't handle all foreign keys.
[00:46] <lifeless> thats right
[00:46] <wgrant> Which means DB, code, DB branches.
[00:46] <lifeless> yes
[00:46] <wgrant> Hopefully next week we will have fastdowntime :)
[00:46] <lifeless> or
[00:46] <lifeless> feature flag
[00:47] <lifeless> but that won't help if you're dropping a column in a used table
[00:47] <lifeless> if there are no columns in used tables
[00:47] <lifeless> you should be able to FF it, and add the flag value in the DB patch
[00:48] <lifeless> giving you the less disruptive
[00:48] <lifeless> code DB code
[00:48] <lifeless> sequence
[00:48] <wgrant> That's not a terrible idea. But it's more complicated and involves new code, when DB changes should be cheap soon.
[00:50] <lifeless> its one less downtime window
[00:50] <lifeless> which is not to be sneezed at
[00:52] <LPCIBot> Project db-devel build #756: FAILURE in 5 hr 31 min: https://lpci.wedontsleep.org/job/db-devel/756/
[01:43] <poolie> huwshimi: have a look at bug 816757?
[01:43] <_mup_> Bug #816757: people didn't find the "download diff" link <code-review> <confusing-ui> <ui> <Launchpad itself:New> < https://launchpad.net/bugs/816757 >
[01:44] <huwshimi> poolie: Interesting.
[01:44] <poolie> i'm interested in the particular case but also about how to deal with "Foo is confusing" bugs generally
[01:45] <poolie> i think this particular one is fairly close to being a hard-edged testable bug
[01:47] <lifeless> wgrant: anyhow, please consider it - making db changes cheaper still doesn't make them free (until we're < small num (e.g. 200ms) on all web requests an can just slide them in without disruption)
[01:58] <lifeless> wgrant: 3 /    0  Bug:EntryResource:newMessage
[01:59] <huwshimi>  poolie: This is interesting in that it seems like the download diff link is in a fairly good place (it's in the first place I thought to look when I went to an mp after reading the bug report -  I don't think I've ever tried to download a diff before).
[02:00] <huwshimi> poolie: There could be a number of reasons why people don't notice the feature. It could be as simple as people want to download the diff once they've read it, so the download diff link has scrolled off the page, or I could take a guess at other places that would be more obvious.
[02:00] <huwshimi> poolie: However, that is a not a good approach. The only really good way to figure it out would be with data (otherwise how can I test the change I'm making has actually resulted in people using the link more). What I would like to do is to a/b test it. That way I can quantitatively determine which position/style/wording results in the most use.
[02:00] <poolie> i would have guessed ctrl-f 'download'
[02:00] <poolie> i agree about a test
[02:00] <poolie> i would be thrilled to see someone get data out of logs
[02:01] <huwshimi> poolie: Often people don't think to look for something. Often people only use feature's if they're obvious.
[02:01] <poolie> ah, i also think perhaps having more of a system of what goes where might help
[02:02] <huwshimi> poolie: That's why I think the current location is good. It has a number of controls to do with the current block of content in a header (in this case the content is a diff, we do a similar thing with comments).
[02:03] <poolie> for instance this is a bit like other "downloadable attachments" which in some cases are in portlets
[02:03] <poolie> often those things on the shaded background are fairly uninteresting controls, though
[02:03] <poolie> but, this is just random speculation
[02:25] <LPCIBot> Project devel build #921: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/devel/921/
[02:33] <wgrant> BugTask conjoinment ararrrrrrrgh
[02:36] <wgrant> Perhaps it was all a cruel joke.
[02:44] <StevenK> wgrant: Still?
[03:37] <wgrant> lifeless: Should bug #809719 be closed now we've upgraded/
[03:37] <_mup_> Bug #809719: current lazr.batchnavigator version requires high OFFSET queries <qa-ok> <timeout> <Launchpad itself:Fix Committed by lifeless> < https://launchpad.net/bugs/809719 >
[03:39] <lifeless> yes
[03:39] <wgrant> Thanks.
[03:40] <sinzui> wgrant, r=me
[03:41] <wgrant> sinzui: Thanks!
[04:08] <StevenK> Hmmmm. I think the lazr.restfulclient is going to force a new release of launchpadlib too
[04:37] <nigelb> No one's updating https://dev.launchpad.net/Contributions ?
[04:37] <lifeless> every now and then
[04:38] <nigelb> I wonder if I can drop a cron on my box.
[04:38] <StevenK> Bah, bzr grep doesn't support -A
[04:38] <wgrant> I should land my patches and run it on devpad.
[04:39] <wgrant> Bah, now it crashes with a Unicode error.
[04:39]  * wgrant blames rvba.
[04:42] <wgrant> nigelb: Updated.
[04:42] <wgrant> Ah, it was lool, not rvba.
[04:43] <wgrant> How dare people have non-ASCII names.
[04:43] <nigelb> wgrant: ah, thanks.
[04:44]  * StevenK renames wgrant to Ŵíllíám Ġŕáńť
[04:44] <nigelb> beat me to it ;)
[04:48] <spiv> wgrant: impressive that poolie is at both #6 and #12 of the second list.
[04:48] <wgrant> Yeah.
[04:48] <wgrant> I'm trying to fix that up.
[04:48] <nigelb> I keep forgetting poolie isn't Launchpad per se.
[04:48] <wgrant> The last update should have.
[04:48] <wgrant> But the missing trailing > seems to be breaking something.
[04:49] <wgrant> poolie has like 5 identities, some of them with typos :)
[04:49] <nigelb> lol
[04:50] <poolie> i prodded ohloh a while ago to help get their bzr-format scans going
[04:50] <poolie> i wonder if they work yet
[04:50] <wgrant> It's failed probably 10 times now :/
[04:53] <wgrant> poolie is now promoted from 6 + 12 to 3.
[04:54] <poolie> hooray
[04:54] <poolie> i wonder if i ever set my identity wrongly in bzr, or if it got mangled somewhere in lp?
[04:54] <poolie> istr seeing other duplicates on that list
[04:54] <wgrant> It turns out the typo was actually in my mapping.
[04:55] <wgrant> There is the full 'Martin Pool <mpb@c.c>', 'mpb@c.c', and 'mpb@sf.n'
[04:55] <wgrant> The 'Martin Pool <mpb@c.c' was my fault.
[04:55] <nigelb> heh, I wondered why 6 + 12 = 3 ;)
[04:55] <spiv> wgrant: Now it's james_w that's being robbed :P
[04:55] <nigelb> hmm, need to get 6 more landings to be in top-5
[04:55] <poolie> wgrant: sadly you'll need to evict yourself from that list
[04:56] <poolie> or is it time limited?
[04:56] <nigelb> poolie: but those are pre-canocical days right?
[04:56] <wgrant> spiv: For exactly the same reason. I must have copied it :(
[04:56] <poolie> ah, apparently it is
[04:56] <nigelb> I see only 2010
[04:56] <wgrant> poolie: That's only my pre-Canonical commits.
[04:57] <wgrant> Everything after I joined is with my canonical.com address, which magically gets excluded.
[04:57] <wgrant> But maybe I should remove myself entirely.
[04:57] <nigelb> nah
[04:57] <nigelb> its nice to see what you did *before* joining
[04:57] <wgrant> Gives you something to aspire to :P
[04:57] <nigelb> Yes, that too.
[04:57] <poolie> yes exactly
[04:57] <spiv> wgrant: I suggest grepping for <[^>]*$ :P
[04:57] <nigelb> 128 to go to beat wgrant :P
[04:57] <poolie> i kind of want to see the scoreboard for ~canonical-launchpad too though
[04:58] <spiv> wgrant: I see at least one other unmatched <> pair in those lists.
[04:58] <poolie> and whether non-canonical wgrant beats them
[04:58] <wgrant> poolie: bzr stats
[04:58] <wgrant> Actually, I guess that doesn't quite do it.
[04:58] <wgrant> Since that's number of commits, not number of merges.
[04:58] <wgrant> poolie: I may do that tonight and see what happens.
[04:58] <nigelb> poolie: heh, that should be interesting
[04:59] <nigelb> I'd like to see if the pre-Canonical wgrant beats the Canonical wgrant.
[04:59] <wgrant> spiv: Luke?
[04:59] <spiv> Yeah.
[04:59] <wgrant> That's a real bzr whoami typo.
[04:59] <wgrant> Maybe I will map it.
[04:59] <spiv> Ah, heh.
[05:01] <nigelb> btw, bugzilla will probably soonish have a generic Android app. For triaging bugs.
[05:01] <nigelb> (Full disclosure: I'm writing it)
[05:01] <poolie> nice
[05:01] <wgrant> Hm.
[05:01] <poolie> heh
[05:02] <wgrant> james_w didn't get any extra merges.
[05:02] <wgrant> I guess all the linaro address commits were in branches with canonical commits too.
[05:02] <wgrant> spiv: Any more issues?
[05:03] <poolie> nigelb: for any site in particular?
[05:03] <poolie> or, user
[05:03] <nigelb> poolie: bugzilla.mozilla.org in particular.
[05:03] <poolie> ok
[05:03] <poolie> this is so people can triage on the train or something?
[05:03] <nigelb> exactly :)
[05:03] <nigelb> there are a few people triaging on commute
[05:04] <nigelb> or having to do something quick on commute
[05:04] <spiv> wgrant: hmm, I guess I have some commits that ought to be eligible, but I'm still a member of various launchpad-related teams so it's probably not a surprise that the script excludes me.
[05:05] <nigelb> spiv: er, you aren't Launchpad team now?
[05:05] <spiv> nigelb: bzr
[05:05] <wgrant> spiv: Indeed.
[05:05] <wgrant> spiv: There's no date-based restrictions.
[05:05] <nigelb> Ah
[05:05] <wgrant> spiv: I suspect you are on the Launchpad list because you were Launchpad years ago.
[05:05] <wgrant> Many years ago.
[05:06] <spiv> wgrant: …and still heckling!
[05:07] <wgrant> For now :)
[05:08] <nigelb> heh.
[05:21] <StevenK> How do I make a launchpadlib release?
[05:21] <wgrant> There's not a document in the branch?
[05:21] <wgrant> https://dev.launchpad.net/HackingLazrLibraries#Releases
[05:21] <wgrant> https://lists.launchpad.net/launchpad-dev/msg02076.html
[05:25] <StevenK> Bleh. 1.9.8 is the latest, but we're still using 1.9.3
[05:26] <lifeless> also
[05:26] <lifeless> dev.launchpad.net/ReleaseChecklist
[05:30]  * StevenK confused
[05:35] <StevenK> release series?
[05:37] <wgrant> StevenK: Presumably the Launchpad series name.
[05:37] <wgrant> You could check the code.
[05:37] <StevenK> Which seems to be trunk
[05:37] <StevenK> lifeless: Can you upload launchpadlib 1.9.9 to PyPi?
[05:37] <lifeless> whats your pypi account /
[05:37] <StevenK> I don't have one
[05:38] <wgrant> It does OpenID, so you can fix that quickly.
[05:39] <StevenK> lifeless: The usual suspect. IE, 'stevenk'
[05:40] <lifeless> ok, you can now.
[05:41] <StevenK> Hm
[05:41] <StevenK> Server response (401): basic auth failed
[05:41] <StevenK> :-(
[05:46] <lifeless> StevenK: you may need a regular account
[05:46] <lifeless> https://dev.launchpad.net/Downtime - updated for new world order, could use a set of eyeballs
[05:47] <StevenK> lifeless: Sorted out anyway
[05:47] <lifeless> what was t ?
[05:47] <StevenK> I used the web interface to do it
[06:07] <lifeless> poolie: gentle reminder - please triage bugs you file on LP; no need for another teammember to do it (unless you're genuinely unsure that it is a bug or how it fits in current work plans)
[06:07] <poolie> yeah
[06:08] <poolie> in this specific case i was talking to people about what to do with it
[06:08] <poolie> didn't finish the transaction
[06:08] <wgrant> The janitor took it half-way...
[06:08] <lifeless> someone me too'd it
[06:09] <wgrant> Yeah.
[06:10] <poolie> done
[06:21] <StevenK> How the heck do I express 100 AS rank in Storm?
[06:25] <wgrant> Try SQL('100 AS rank')
[06:26] <LPCIBot> Project db-devel build #757: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/757/
[06:26] <StevenK> But Storm has Alias which does AS?
[06:27] <wgrant> I'm not sure if that works for non-classes.
[06:27] <StevenK> Neither
[06:29] <jtv> StevenK: that may be the best code review I've ever had.
[06:31] <StevenK> Haha
[06:31] <StevenK> Was it as good for you as it was for me? :-)
[06:31] <wgrant> Emphatic condonement of the removal of commercial-compat, or have you been secretly working on something similarly glorious?
[06:32] <StevenK> wgrant: The former.
[06:34] <wgrant> jtv: Given that you have both dogfood access and Translations expertise, could you perhaps be convinced to QA bug #788685?
[06:34] <_mup_> Bug #788685: Enable translating selected Ubuntu universe packages in Launchpad <escalated> <oem-services> <qa-needstesting> <Launchpad itself:Fix Committed by bac> <OEM Priority Project:Invalid> <Ubuntu Translations:Triaged> <pkgbinarymangler (Ubuntu):Fix Released by pitti> < https://launchpad.net/bugs/788685 >
[06:35] <jtv> I can try.  First I'll have to take some time to figure out just what's changed.
[06:35] <jtv> StevenK, wgrant: by the way, mind if I update dogfood at this point?
[06:35] <wgrant> jtv: Not at all.
[06:36] <wgrant> The change is fairly simple, if slightly nauseating.
[07:53] <adeuring> good morning
[07:59] <jtv> hi adeuring
[07:59] <adeuring> hi jtv!
[08:04] <mrevell> Hello
[08:08] <LPCIBot> Project devel build #922: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/devel/922/
[08:13] <allenap> StevenK: Thanks for the review :)
[08:18] <StevenK> allenap: No fair not looking for active_publishing_status :-P
[08:20] <allenap> StevenK: I knew I could rely on splendid chaps such as your good self :)
[09:43] <gmb> StevenK: Are you still around and on-call?
[09:44] <henninge> danilos: hey, are you around?
[09:44] <lifeless> henninge: gl
[09:45] <henninge> gl?
[09:45] <lifeless> henninge: good luck
[09:45] <henninge> ah! ;-)
[09:46] <henninge> lifeless: have you been trying to talk to him about QA for bug 788685?
[09:46] <_mup_> Bug #788685: Enable translating selected Ubuntu universe packages in Launchpad <escalated> <oem-services> <qa-needstesting> <Launchpad itself:Fix Committed by bac> <OEM Priority Project:Invalid> <Ubuntu Translations:Triaged> <pkgbinarymangler (Ubuntu):Fix Released by pitti> < https://launchpad.net/bugs/788685 >
[09:46] <lifeless> henninge: no; I was referring to your bombshell from last night :)
[09:46] <henninge> lifeless: oh! ;-)
[09:46] <henninge> lifeless: thank you ;)
[09:50] <henninge> rvba: Hi!
[09:50] <rvba> henninge: Hi!
[09:51] <henninge> rvba: Could you please do QA for bug 815751?
[09:51] <_mup_> Bug #815751: In initialize_series, the package copier copy method should be called with all the packages from pockets RELEASED, UPDATES, SECURITY. <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/815751 >
[09:51] <rvba> henninge: sure, I'll do that.
[09:52] <henninge> rvba: I am trying to get a deployment together. Thanks. ;-)
[09:52] <wgrant> henninge: Thanks!
[09:52] <henninge> wgrant: can I have your opinion on bug 788685
[09:52] <_mup_> Bug #788685: Enable translating selected Ubuntu universe packages in Launchpad <escalated> <oem-services> <qa-needstesting> <Launchpad itself:Fix Committed by bac> <OEM Priority Project:Invalid> <Ubuntu Translations:Triaged> <pkgbinarymangler (Ubuntu):Fix Released by pitti> < https://launchpad.net/bugs/788685 >
[09:52] <henninge> ?
[09:52] <gmb> StevenK: Point taken :)
[09:53] <StevenK> gmb: :-)
[09:53] <henninge> wgrant: QAing it involves dogfood and such and I know bac was working on figuring that out yesterday.
[09:54] <wgrant> For this sort of thing I think a QA strategy should be devised before landing.
[09:54] <henninge> yes
[09:54] <wgrant> There is not one?
[09:55] <henninge> bac asked me about it yesterday but I could not help him since it was mainly about uploading a source package.
[09:55] <henninge> I havn't done that either.
[09:55] <henninge> So I guess there is none.
[09:55] <henninge> bigjools was helping him, maybe he knows more?
[09:55]  * bigjools otp, yes I know about it
[09:56] <henninge> still otp? that's what bac told me yesterday, too .... ;-)
[09:57] <henninge> wgrant: I'll sort it out with bigjools when he gets otp (the other otp)
[09:57] <wgrant> Thanks.
[09:57] <wgrant> I'll probably still be pingable if you need me.
[09:57] <danilos> henninge, yeah
[09:58] <danilos> henninge, I know bac was talking to bigjools yesterday-ish
[09:58] <danilos> (and only know I realize after reading the full backlog that you've already come to the same point :)
[09:59] <danilos> henninge, I've also got an email from bac
[10:00] <danilos> henninge, he was stuck looking for a package with translations, and I know of one (epiphany-browser)
[10:06] <henninge> danilos: can you take care of the qa, or is that too much to ask?
[10:07] <bigjools> henninge, danilos: hello
[10:07] <bigjools> so, we need a package in universe
[10:08] <bigjools> and you need to add a special header to debian/control
[10:08] <bigjools> bac tried it with one package but it FTBFS
[10:08] <bigjools> so a simple package would be good
[10:09] <danilos> henninge, sure, I'll take it on
[10:13] <henninge> danilos: thanks
[10:24]  * henninge reboots computer
[11:04] <danilos> bigjools, I've uploaded epiphany-browser package to dogfood, can you remind me what the next step is? will it get rejected because I am not the ubuntu guy?
[11:05] <bigjools> danilos: yeah, I'll add you to core-dev
[11:05] <danilos> bigjools, thanks
[11:11] <bigjools> danilos: grar, there's a million danilos!
[11:11] <danilos> bigjools, I am only "danilo" on LP, and you can always look for "Данило" :)
[11:11] <bigjools> No items matched "Данило".
[11:11] <bigjools> :)
[11:12] <danilos> bad, bad search
[11:12] <bigjools> I can't even do ~danilo
[11:12] <wgrant> bigjools: You can also search for 'danilos' and it will always return a username match as the first result.
[11:12] <bigjools> 17 pages of results
[11:12] <bigjools> aha fluked it
[11:13] <wgrant> Er, 'danilo' is the username, but 'danilos' should still get OK IRC nick results.
[11:13] <danilos> I am in, thanks bigjools :)
[11:14] <bigjools> danilos: just processing the upload
[11:14] <wgrant> bigjools: 'danilo' returns danilos as the first result... did it not for you?
[11:14] <bigjools> nope
[11:14] <wgrant> danilos returns him as the third result.
[11:14] <bigjools> yep
[11:15] <bigjools> danilos: 2011-07-27 11:14:48 INFO    Upload was rejected:
[11:15] <bigjools> 2011-07-27 11:14:48 INFO        Unable to find epiphany-browser_3.0.4.orig.tar.bz2 in upload or distribution.
[11:15] <danilos> bigjools, what's the dput option to force the orig.tar.gz to be included as well?
[11:15] <danilos> or was that a debuild option?
[11:16] <bigjools> debuild -S -sa
[11:16] <danilos> bigjools, I should up the version number again?
[11:16] <bigjools> no
[11:16] <danilos> ok
[11:16] <bigjools> dput -f though
[11:17] <danilos> bigjools, yep, using that already, all set now, please try the upload processor again
[11:18] <bigjools> accepted
[11:19] <jml> does "Related bugs" also show bugs that affect me?
[11:20] <poolie> jml i believe it does
[11:20] <danilos> bigjools, I should have probably used the latest oneiric epiphany package from dogfood and not from production, this might fail to build as well
[11:20] <jml> poolie: thanks.
[11:20] <poolie> i think it is "related in any way"
[11:20] <poolie> imbw
[11:20] <bigjools> danilos: we'll see!
[11:20] <wgrant> jml: I don't believe it does.
[11:20] <jml> since I'm working across quite a few projects now, really feeling the need for some more aggregate views.
[11:20] <wgrant> jml: I don't know of any way to find bugs that affect you.
[11:20] <jml> oh no
[11:20] <jml> a conflict of beliefs.
[11:21] <jml> crap. I'm going to have to either try science or consult an authority.
[11:21] <wgrant> It's just an aggregation of the other 4 or 5 views.
[11:21] <wgrant> commented/reported/assigned/whatever
[11:21] <wgrant> There is a simple path of deduction which allows you to work this out :)
[11:21] <danilos> bigjools, yeah :) I'll also prepare a natty package to confirm that one doesn't get translations extracted and uploaded
[11:22] <jml> wgrant: need observations to make deductions.
[11:23] <wgrant> jml: Well, there are some generally applicable observations, I suppose.
[11:23] <wgrant> But anyway, code.
[11:24] <poolie> he's right, i'm wrong
[11:24] <poolie> i think i'm right that related means 'any relation' but lp won't tell you about affecting bugs
[11:25] <wgrant> It's just the union of the other categories in that menu.
[11:25] <jml> that's unfortunate
[11:25] <poolie> right
[11:25] <poolie> there's a bug for it
[11:25] <jml> I've marked bugs as affecting me in the hope that I'd be able to recover that information later
[11:25] <wgrant> Many things are unfortunate, but it seems that people only work this out once they leave Launchpad management :)
[11:26] <jml> wgrant: don't be a dick.
[11:26] <wgrant> It's *possible* there's an API call.
[11:26] <wgrant> I think someone might have added one at some point.
[11:27] <wgrant> Nope, only HWDB's deviceDriverOwnersAffectedByBugs :(
[11:27] <jml> poolie: https://bugs.launchpad.net/launchpad/+bug/323000 fwiw, it's one of the top 10 hot bugs.
[11:27] <_mup_> Bug #323000: Make "this bug affects me too" bugs visible from user profile <lp-bugs> <profile> <Launchpad itself:Triaged> < https://launchpad.net/bugs/323000 >
[11:28] <poolie> yeah, i voted for it
[11:28] <poolie> i would like it alot
[11:29] <jml> well, it's down in my yak stack, whatever that counts for.
[11:29]  * jml has to relocate.
[11:52] <danilos> bigjools, ok, the build finished successfully, I remember us needing to run upload processor again (or something) to get the translations.tar.gz to be pushed through to the translations import queue
[11:53] <danilos> bigjools, I do see the translations.tar.gz on https://dogfood.launchpad.net/ubuntu/oneiric/+queue fwiw
[11:53] <bigjools> danilos: then it worked I guess
[11:53] <danilos> bigjools, right, I'd like to confirm it shows up in the translations queue, because it still doesn't
[11:54] <bigjools> danilos: accept the upload then
[11:54] <danilos> bigjools, how do I do that?
[11:54] <henninge> gary_poster: Hi!
[11:54] <bigjools> danilos: you're in the wrong team, I'll do it :)
[11:55] <danilos> bigjools, heh, people keep telling me that
[11:55] <bigjools> danilos: ok accepted
[11:55] <gary_poster> henninge, hey!
[11:56] <gary_poster> I have another conversation going henninge, just so you know, but no problem as long as you forgive me if it takes me a bit to reply sometimes :-)
[11:56] <danilos> bigjools, do we run the upload-processor again?
[11:57] <bigjools> danilos: I need to run process-accepted
[11:57] <bigjools> running now
[11:57] <danilos> bigjools, ah, ok, thanks
[11:57] <danilos> this is so much fun :)
[11:57] <bigjools> 2011-07-27 11:57:24 DEBUG   Publishing custom epiphany-browser, epiphany-browser_3.0.4-1ubuntu2_i386_translations.tar.gz, epiphany-browser_3.0.4-1ubuntu2_static_translations.tar.gz to ubuntu/oneiric
[11:58] <bigjools> danilos: all done
[11:58] <henninge> gary_poster: that's ok. I just had a quick question on how LP is running and I guess you are not the only one who could answer that.
[11:59] <danilos> bigjools, excellent, it worked; now I'd like to test that we haven't broken anything for natty (i.e. universe packages still can't get translations on), but I got an "upload rejected" email
[11:59] <henninge> gary_poster: actually, I just thought I'll try something else first before asking, so nm me atm. ;-)
[11:59] <danilos> bigjools, actually, "upload rejected" email is because I tried the main archive ;)
[12:00] <danilos> bigjools, so, uploaded to dogfood, and we'll need to go through the same dance again for natty: upload processor, wait for build, and if translations.tar.gz doesn't show up, we are good, if it does, we'll have to check that it doesn't end up in the queue
[12:01] <gary_poster> henninge :-) ok.  looks like other conversation is mostly handled atm, so feel free to ping if you want to later
[12:01] <bigjools> danilos: ok
[12:03] <LPCIBot> Project db-devel build #758: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/758/
[12:06] <danilos> bigjools, can you please run the upload processor then?
[12:06] <bigjools> danilos: 2011-07-27 12:01:41 DEBUG   Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
[12:06] <bigjools> target -updates
[12:06] <danilos> bigjools, ah, natty-updates?
[12:07] <henninge> wgrant: we had some revisions for bug 80902 land and that reverted r13514 back to needstesting.
[12:07] <_mup_> Bug #80902: Can't target bug report from project to distribution, or vice versa <bugs> <disclosure> <javascript> <linaro> <lp-bugs> <project-picker> <qa-needstesting> <questions> <ubuntu-qa> <Launchpad itself:In Progress by launchpad-teal-squad> < https://launchpad.net/bugs/80902 >
[12:08] <bigjools> danilos: yes
[12:08] <henninge> henninge: is that revision ok to be deployed? How can I properly mark it as such without removing needstesting from the others?
[12:10] <danilos> bigjools, done
[12:14] <wgrant> henninge: Fixed.
[12:17] <bigjools> danilos: it should be building
[12:20] <danilos> bigjools, I don't see it happening on https://dogfood.launchpad.net/builders :/
[12:25] <gmb> danilos, Are you OCRing today?
[12:25] <danilos> gmb, oh right, I should be doing that today as well :/
[12:26] <gmb> Yeah, no rest for the weary.
[12:26] <gmb> danilos: If you don't have the brainjuice, I'll happily ping some otther schmuck^Wreviewer
[12:26] <danilos> gmb, I do, I do, but it's best to wait until after the call
[12:26] <gmb> danilos: Okidoke.
[12:28] <bigjools> danilos: sorry it was stuck in UNAPPROVED
[12:29]  * danilos nods in "while of course" style, hoping bigjools knows how to get it out of unapproved state :)
[12:32] <bigjools> danilos: it should be building :)
[12:33] <danilos> bigjools, still don't see it :/
[12:33] <bigjools> argh
[12:33] <bigjools> my fault
[12:34] <bigjools> danilos: now?
[12:34] <danilos> bigjools, nope
[12:35] <danilos> I am looking at https://dogfood.launchpad.net/builders, should I look somewhere else?
[12:35] <bigjools> the build page would be a good start :)
[12:37] <gmb> danilos: So, https://code.launchpad.net/~gmb/lazr.restful/accessor-for/+merge/69416 is the branch, when you've got a second. I think you owe me now ;)
[12:37] <danilos> gmb, sure thing
[12:38] <danilos> bigjools, you mean https://dogfood.launchpad.net/ubuntu/+source/epiphany-browser/2.30.6-1ubuntu6?
[12:39] <wallyworld__> sinzui: ping
[12:40] <danilos> i386 is in 'needs building' state, but I don't know what needs to happen for it to be picked up (that was buildd-manager or whatever the name is now, right)
[12:43] <danilos> gmb, just before I dive in deeper, is the change to versions.cfg really required or just a drive-by fix?
[12:43] <gmb> danilos: It's required to get it to build these days.
[12:43] <danilos> gmb, ah, ok, just checking before I dive in deeper
[12:44] <gmb> danilos: It's not a requirement for my change, per se, but it would have been hard to test otherwise :)
[12:45] <henninge> wgrant: thanks
[12:49] <danilos> gmb, btw, have you tried ensuring all classes are new-style-classes before using super()? (eg. define them as "class Something(object):" instead of just "class Something:") - not sure that'd help, but just an idea
[12:51] <gmb> danilos: Yes, I tried that. Didn't help, unfortunately.
[12:52] <danilos> gmb, ack
[12:54] <henninge> gary_poster: ping
[12:56] <gary_poster> henninge, yo
[12:56] <henninge> gary_poster: from this I see that LP is running in different threads/processes ...
[12:56] <henninge> https://pastebin.canonical.com/24724/
[12:56] <henninge> that is where the race condition comes from.
[12:56] <gary_poster> henninge, threads, yes
[12:56] <danilos> gmb, btw, that versioning of accessors (lines 218-253), what does it exactly do? (the latter part seems clear, but why do we need the 'ensure only one accessor' part)
[12:57] <henninge> gary_poster: that means they share memory?
[12:57] <henninge> gary_poster: I am jumping ahead here.
[12:57] <henninge> gary_poster: I am just trying to figure out what is going on.
[12:58] <gmb> danilos: It's to avoid collisions. If you have an implicit accessor and an explicit one for the same version, which one are you supposed to call to get the value?
[12:58] <gmb> (I cargo culted that, but that's what I took its intention to be)
[12:58] <danilos> gmb, also, I have no suggestions on how to do it, but it seems as if it'd be very nice to have tests for that code
[12:58] <danilos> gmb, oh, ok
[12:58] <henninge> gary_poster: so this is the same on productio?. On process (that gets signalled for log rotation) running in multiple threads. On process per appserver instance.
[12:59] <danilos> gmb, implicit = a regular exported attribute?
[12:59] <gmb> danilos: Ah, good point. There are similar tests for the mutator code, so I'll add some to cover the only-one-accessor-per-version stuff.
[12:59] <henninge> gary_poster: and each process with its own set of log files.
[12:59] <gary_poster> henninge, I am 95% sure they are threads, though production reduces number of threads serving users to 1 at a time.  That still means we have at least two threads: main thread, with asyncore loop (similar to Twisted loop); and worker thread, actually figuring out what to serve
[12:59] <gmb> danilos: Or @accessor_for without @operation_for_version
[12:59] <gary_poster> henninge, each process typically has its own log files
[12:59] <danilos> gmb, cool (don't forget the test for defined in version N gets included in N+1 if it's not too hard :)
[12:59] <gary_poster> hennige, Python's stdlib logging module is supposed to be thread safe
[13:00] <gary_poster> henninge, so is ZConfig, but that's certainly in less usage
[13:00] <gmb> danilos: Sure. I'm sure leonard wrote something that I can rip off ;)
[13:00] <danilos> gmb, excellent :)
[13:01] <henninge> gary_poster: yes, loghandler simply does a close -open sequence with no coordination what so ever.
[13:01] <henninge> no thread safety there.
[13:01] <gary_poster> henninge, "On process (that gets signalled for log rotation) running in multiple threads. On process per appserver instance." If I magically transmute "On" to "One" then that is correct
[13:01] <henninge> what I meant.
[13:02] <gary_poster> I figured, was being silly :-)
[13:02] <danilos> bigjools, btw, nothing is happening with https://dogfood.launchpad.net/ubuntu/+source/epiphany-browser/2.30.6-1ubuntu6/+build/2492859 still? got any ideas?
[13:03] <bigjools> danilos: no, and sorry I can't help right now I'm trying to debug a problem
[13:03] <henninge> gary_poster: I am not familar with threads in python.
[13:03] <gary_poster> henninge: close/open sequence: logging module is supposed to be friendly to that, I thought--unless you mean it is a raw file close?
[13:03] <henninge> gary_poster: that is in ZConfig
[13:03] <danilos> bigjools, np, please ping me when you have some time
[13:03] <henninge> gary_poster: ZConfig.component.logger.loghandler
[13:04] <gary_poster> henninge, right, but I mean, it gets the log files themselves--the file handles--and closes them directly?  OK looking
[13:04] <bigjools> danilos: I just checked the manager log and the builder is failing for some reason
[13:04] <bigjools> probably no chroot available
[13:04] <henninge> gary_poster: AFAIUI, yes.
[13:04] <henninge> gary_poster: yes, "self.stream"
[13:04] <henninge> gary_poster: looks like a standard file handle
[13:05] <deryck> Morning, all.
[13:06] <adeuring> morning deryck
[13:06] <danilos> bigjools, can we perhaps get back to this later when you are done with that debugging, or is it more of a general problem?
[13:06] <gary_poster> henninge, sideways thought: have you checked stdlib logging module to see if they (now?) have a solution for logrotation themselves?
[13:06] <gary_poster> morning deryck
[13:06] <danilos> gmb, btw, r=me as per our discussion
[13:06] <henninge> gary_poster: have not, no.
[13:06] <gmb> danilos: Excellent, thanks.
[13:07] <henninge> Hi deryck! ;)
[13:07] <henninge> gary_poster: so you think it might be best to replace the ZConfig logging stuff?
[13:08] <henninge> s/best/an idea/
[13:08] <gary_poster> henninge, if I were looking at this problem that would certainly be an option on the table.  Moving to something more maintained would be a win.  But looking at that file you were pointing to...
[13:10] <gary_poster> henninge, I don't think closeFiles is dealing with file objects
[13:10] <gary_poster> henninge, the reason why is in "reopenFiles"
[13:10] <gary_poster> it calls h.reopen()
[13:10] <henninge> gary_poster: I  was looking at FileHandler.reopen.
[13:10] <gary_poster> reopen is not on a Python file object
[13:10] <henninge> that is a few lines down.
[13:12] <gary_poster> henninge, ah you might be right there.  Not that this would be necessary, but have you pdb'd in to confirm, by chance?  or verified in logging module?
[13:12] <gary_poster> verifying in logging module docs might be a minimal reasonable solution :-)
[13:13] <gary_poster> henninge, so if your guess is right, then I see two paths to a solution so far
[13:14] <henninge> gary_poster: i just looked into the logging module and self.stream is the stream passed in.
[13:14] <henninge> which in this case is simple "open" call.
[13:16] <gary_poster> 1) confer with Fred Drake and see if you can get a ZConfig change in, or maybe do it ourselves locally and then try to push it upstream.  A simple solution there would be to remove self.stream.close(): Python will close it when it cleans up trash.  Meanwhile, if a thread is still writing to it, it can.
[13:16] <gary_poster> henninge, case closed then
[13:16] <gary_poster> 2) see if logging module has an alternative.
[13:17] <gary_poster> option 1 sounds so easy I would be inclined to try that
[13:17] <gary_poster> coordinating with upstream can be annoying, I grant you :-)
[13:17] <henninge> ;-)
[13:18] <henninge> gary_poster: thanks, I'll look at both (since the first one is so easy) ;)
[13:18] <gary_poster> We could make a local change, see if it helps, and if it does *then* confirm with upstream and try to get a change.  Extra bonus for you: you are gone by then ;-)
[13:18] <gary_poster> ok cool henninge
[13:18] <henninge> gary_poster: it really takes that long?
[13:19] <gary_poster> henninge, what is "it" in that sentence? :-) I meant proving to ourselves that we have fixed the problem.  Since it is intermittent, that might take a little bit.
[13:20] <henninge> oh, ok
[13:20] <gary_poster> henninge, coordinating with upstream depends on the upstream.  Fred is a good guy, but busy, and his company no longer really cares about open source afaict
[13:20] <henninge> "it" was referring to "coordinating with upstream"
[13:20] <gary_poster> gtcha
[13:20] <gary_poster> if he agrees, could be fast
[13:21] <gary_poster> I could mae a release
[13:21] <gary_poster> if he doesn't agree....
 :-)
[13:21] <gary_poster> having "proof" that it helps I thought might be a way of getting him to agree more easily
[13:22] <henninge> gary_poster: So, I don't think this can (or should) be pressed into a test of any sort, since race conditions are hard to reproduce reliably.
[13:22] <henninge> gary_poster: that means, if I go for option 1 it is just a matter of removing the line and see if it helps in production, right?
[13:24] <bac> bigjools: when you have time, can you do your thing to get this building?  https://dogfood.launchpad.net/ubuntu/+source/epiphany-browser/2.30.6-1ubuntu6/+build/2492859  (it is the upload danilos did)
[13:24] <gary_poster> henninge, you could probably make a test that showed that the original file was not closed after rotating.  If you do that at a low-enough level then that would be easy.  "easy"? :-) but that would be a ZConfig test.  That would be the kind of thing to write to have it go upstream.
[13:24] <gary_poster> I definitely agree that we do not need a LP test for this change.
[13:24] <bigjools> bac: the builder is failing, I don't know why
[13:25] <bac> oh.  :(
[13:25] <bigjools> well in fact it seems to have fallen over entirely
[13:26] <wgrant> bigjools: The chroot has expired
[13:26] <wgrant> http://librarian.dogfood.launchpad.net/70572775/chroot-ubuntu-natty-i386.tar.bz2 -> 404
[13:26] <bigjools> ferraz is also not responding
[13:26] <wgrant> That could also be a problem.
[13:26] <wgrant> Working for me...
[13:27] <wgrant> So, upload a new natty/i386 chroot, I suspect.
[13:31] <rvba> henninge: sorry, I'm having trouble with my QA ...
[13:32] <rvba> henninge: It's going to take a little bit longer than what I thought ...
[13:34] <henninge> rvba: I am in the stand-up call atm, I can see if I can help you afterwards.
[13:41] <rvba> henninge: I'm trying to work it out with the help of Julian ...
[13:44] <bac> abentley: i thought you could specify a pre-req branch with 'bzr lp-propose' but it isn't documented.  can you do that?
[13:45] <abentley> bac: It auto-detects pre-req branches from a pipeline.  Specifying a pre-req from the commandline is a missing feature.
[13:45] <bac> abentley: ok, i'm not using pipelines, so i'll not use it
[13:45] <abentley> bac: sure.
[13:45] <abentley> bac: just merged and pushed.
[13:47] <deryck> adeuring, abentley, henninge -- forgot to mention that I'll be switching offices in about 45 minutes and will be offline for 20-25 minutes.
[13:47] <abentley> deryck: okay.
[13:51] <rvba> henninge: qa-ok. Endlich.
[13:51] <henninge> rvba: Super!
[13:51] <henninge> rvba: I just came off the call ...
[13:52] <rvba> henninge: Perfect timing :)
[13:53] <wallyworld__> sinzui: you there?
[13:53] <sinzui> I am
[13:54] <wallyworld__> sinzui: i have a failing test i can't figure out without more digging and perhaps you can see the issue
[13:54] <wallyworld__> it's a web service test
[13:54] <sinzui> okay
[13:54] <wallyworld__> take a look at the diff in this mp: https://code.launchpad.net/~wallyworld/launchpad/question-subscribe-webservice/+merge/69433
[13:54] <wallyworld__> it's the test_subscribe()
[13:55] <wallyworld__> the question.subscribe(person) call fails
[13:55] <wallyworld__> with error: TypeError: Could not serialize object <security proxied lp.answers.model.questionsubscription.QuestionSubscription instance at 0xa847c90> to JSON.
[13:55] <wallyworld__> i have modelled the web service stuff for IQuestionSubscription on IBugSubscription
[13:56] <wallyworld__> but i can't see what else i need to do to resolve the issue
[13:56] <wallyworld__> i think there needs to be a json adaptor of some sort
[13:56] <wallyworld__> but if there does, i can't see where it's been set up for IBugSubscription
[13:57] <sinzui> ah
[14:00] <LPCIBot> Project devel build #923: STILL FAILING in 5 hr 51 min: https://lpci.wedontsleep.org/job/devel/923/
[14:00] <sinzui> wallyworld__, I am unfamiliar with the publish_web_link=False arg of  export_as_webservice_entry
[14:01] <wallyworld__> i figured out at one point what it did but can't recall exactly now
[14:01] <wallyworld__> it fails with and without
[14:01] <sinzui> wallyworld__, I have not used that, but your error does imply a url is wanted
[14:02] <sinzui> wallyworld__, I added urls to a few question objects a few months ago to make export work
[14:02] <wallyworld__> i thoought it was trying to turn a QuestionSubscription into a json data object to serialise the result of a subscribe() call, so it is not clear to me atm why a url is needed
[14:03] <wallyworld__> and also bub.subscribe() works
[14:03] <wallyworld__> and it is set up the same way
[14:03] <wallyworld__> bug.subscribe()
[14:04] <sinzui> wallyworld__, removeAnswerContact is already a method on the target. Do you intent the question method to call the QT method?
[14:04] <wallyworld__> yes. the subscription portlet invokes apis on the context object ie question
[14:04] <sinzui> wallyworld__, creating a url is easy and we can try it to see if this solves the problem
[14:05] <henninge> bac: Hi!
[14:05] <wallyworld__> ok
[14:05]  * sinzui tries to write the zcml without caffeine
[14:05] <bac> hi henninge
[14:05] <henninge> bac: any eta on that QA?
[14:05] <henninge> I saw danilo and bigjools where helping?
[14:06] <bac> henninge: there is a problem on dogfood (scroll up to see wgrant's comments about natty chroot) that i'll need to get assistance from bigjools to sort out.  so, no eta.
[14:06] <bigjools> I am busy, and it needs someone to upload a natty i386 chroot to DF
[14:06] <bac> bigjools: who can do that?
[14:06] <bigjools> bac: it needs a losa to get one from production, put it somehwere in the DC where I can get it and then I can upload it
[14:07] <bigjools> bac: scripts/ftpmaster-tools/manage-chroot.py
[14:07] <bac> bigjools: i can facilitate the first part while your snowed under
[14:07] <henninge> bac: thanks for the heads up
[14:08] <sinzui> wallyworld__, try http://pastebin.ubuntu.com/653123/
[14:08]  * wallyworld__ looks
[14:09] <sinzui> wallyworld__, the attribute_to_parent value could also be the id you added to IQuestionSubscription
[14:10] <wallyworld__> i'll try the pastebin as is....
[14:14] <sinzui> wallyworld__, when this is complete will the subscriber portlet load after the page is loaded?
[14:14] <wallyworld__> sinzui: you are a genius. that works. i don't fully understand why (my zope foo is not fully develped)
[14:15] <wallyworld__> i need to add a bit more glue before it works, but it will be the same as bugs - the portlet will load after the page has loaded, yes
[14:16] <sinzui> wallyworld__, I am not a genius. I just did not know about that arg you used. I wrote and export must of answers code you are working with. make me the reviewer since I have read most of this change and It looks good
[14:17] <wallyworld__> sinzui: so, next branch, i need to extend the javascript portlet stuff to allow each subscription entry to specify the web service api to use to "unsubscribe" and then it's pretty much done
[14:17] <sinzui> wallyworld__, you may accidentally fix a timeout bug doing this. the subscriber code can be expensive to use and I did not factor that out of the page load two months ago
[14:17] <wallyworld__> cool, one less critical :-)
[14:18] <wallyworld__> with the bugs portlet, the unsubscribe method will always be "unsubscribe", for questions, it will either be "unsubscribe" or "removeAnswerContext"
[14:20] <wallyworld__> sinzui: i'll finish the mp and then need sleep. btw, i will likely miss the standup since i have to go and pick up a new car from the dealer
[14:20] <sinzui> understood. Your working overtime right now
[14:22] <sinzui> wallyworld__, bug 736003 is the one I was thinking of. I believe this *wont* be affected by your work since it is a question target page.
[14:22] <_mup_> Bug #736003: Distribution:+questions timeouts <questions> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736003 >
[14:22] <wallyworld__> ah, too bad
[14:28] <wallyworld__> sinzui: mp is now ready for review, thanks for the help. i hate leaving stuff unfinished so am glad to get it done.
[14:28] <sinzui> fab
[14:35] <bac> benji: could you have a look at https://code.launchpad.net/~bac/launchpad/getnewcache/+merge/69476 ?
[14:36] <benji> bac: sure
[14:42] <bac> bigjools: mbarnett has prepared a chroot to be uploaded to dogfood:  devpad:~mbarnett/tmp/chroot-ubuntu-natty-i386.tar.bz2
[14:51] <benji> bac: I'm done with https://code.launchpad.net/~bac/launchpad/getnewcache/+merge/69476
[14:52] <bac> thanks benji
[14:55] <henninge> gary_poster: that looks very promising. We could do away with SIGUSR2 handling alltogether.
[14:55] <henninge> http://docs.python.org/library/logging.handlers.html#watchedfilehandler
[14:56] <gary_poster> henninge, +1
[14:57] <gary_poster> henninge, that will probably be more work that the other approach, and it might be tricky because I think ZConfig creates files
[14:57] <gary_poster> I mean, is in charge of our log files
[14:57] <gary_poster> but I would prefer it in the long haul
[14:57] <gary_poster> & I suspect others would too
[14:58] <henninge> gary_poster: ok, I will see how they'd work together.
[14:58] <gary_poster> cool
[14:58] <henninge> thanks  for the info
[15:01] <henninge> gary_poster: the other thing I'd worry about is the extra load that each emit creates by doing the checks on the file.
[15:03] <bac> benji: uh, thanks for catching that little bit of overexuberance in the page template.  clearly i hadn't intended to check that in
[15:06] <gary_poster> henninge, probably not an issue.  any change other than "remove stream.close" will need approval and coordination from losas; if you were concerned about performance then you could check with Robert too, but unless that emit coe is doing a lot more than I expect, I think it should be fine.
[15:07] <henninge> gary_poster: I just found that we have our own WatchedFileHandler implementation in our tree ... ;-)
[15:07] <gary_poster> henninge, heh
[15:08] <henninge> gary_poster: it's identical to upstream, so that was merged into logging.
[15:09] <gary_poster> ah ok
[15:09] <henninge> gary_poster: but it also has this comment:
[15:09] <gary_poster> or vice versa
[15:09] <henninge>             # BACKPORT: Doing a stat on every log seems unwise. A signal
[15:09] <henninge>             # handling log handler might be better.
[15:09] <henninge> ;-)
[15:09]  * henninge goes to look who wrote that comment
[15:09] <gary_poster> it may have been a backport from 2.6
[15:09] <henninge> ah, ok
[15:10] <henninge> yeah, reading module docstring helps
[15:11] <deryck> adeuring, abentley, henninge -- I may drop from IRC as I reboot to recover my system.
[15:11] <deryck> Not sure yet, but if I disappear, that's where I've gone. ;)
[15:11] <abentley> deryck: okay.
[15:11] <henninge> gl
[15:11] <adeuring> deryck: sounds familiar to me today ;)
[15:12] <deryck> adeuring: :)
[15:12] <deryck> thanks, henninge
[15:13]  * henninge learned gl from lifeless today
[15:16] <sinzui> jcsackett, do you have time to mumble
[15:39] <henninge> gary_poster: so, I decided to go with the one-line change.
[15:39] <gary_poster> hrnninge, sounds safest to me :-)
[15:40] <henninge> gary_poster: but this change is not in our tree, I guess I need to create an egg/package?
[15:44] <gary_poster> henninge, right.  Easiest story: Get the most recent ZConfig from our download cache, unpack it, make your change, and then follow instructions in "Work with Unreleased or Forked Packages" section of doc/buildout.txt.  unpacking the ZConfig from download cache takes the place of the svn checkout.
[15:44] <gary_poster> A nicer approach would be to check out svn
[15:44] <gary_poster> push to LP
[15:44] <gary_poster> (or import it)
[15:44] <gary_poster> then make a branch
[15:44] <gary_poster> make your changes
[15:44] <gary_poster> push to LP
[15:44] <gary_poster> follow instructions
[15:45] <henninge> ok, thanks
[15:45] <henninge> gary_poster: we are not using the latest version btw.
[15:45] <gary_poster> henninge, ah interesting.  You could see if latest version has change :-)
[15:45] <henninge> gary_poster: yeah, looking at that now
[15:46]  * gary_poster doubts it
[15:46] <henninge> it says it just adds "SMTP auth for email logging"
[15:46] <henninge> but I am looking at the diff now
[15:46] <gary_poster> there ya go
[15:46] <gary_poster> cool
[15:49] <bigjools> bac, danilos: the build is now starting.
[15:49] <bigjools> sorry for the delay
[15:53] <henninge> gary_poster: nope, no other change. So 2.7.1 is just as good for us.
[15:53] <gary_poster> cool henninge
[15:54] <henninge> I am EOD now, I wil "follow instructions" tomorrow ...
[15:54] <gary_poster> henninge, if you have done the work to verify that the newer version is not a problem for us, upgrading would not be a bad idea
[15:54] <henninge> gary_poster: thanks for your help
[15:54] <gary_poster> then next person does not have to do it
[15:54] <henninge> I am fine with that, too.
[15:54] <gary_poster> your very welcome henninge
[15:54] <gary_poster> "you're," even
[15:54] <henninge> ;)
[15:58] <henninge> gary_poster: zconfig is already on LP
[15:59] <gary_poster> cool
[16:01] <bigjools> gary_poster: about that bug
[16:01] <gary_poster> bigjools, hey!
[16:01] <bigjools> gary_poster: it's indicative of data corruption
[16:01] <gary_poster> (I was explicitly trying to not bother you today, and thus emailing)
[16:01] <gary_poster> ah ok
[16:01] <bigjools> gary_poster: it's possible for something to not have a BQ when it's finished building, but it must have one if it's NEEDSBUILD or BUILDING
[16:02] <bigjools> gary_poster: well I am inbetween interruptions :)
[16:02] <gary_poster> heh
[16:03] <bigjools> gary_poster: so I would not paper over the crack and work out why the data is corrupted
[16:05] <gary_poster> bigjools, ack.  I'll report as such on the bug, thanks.  If I look at https://launchpad.net/~chromium-daily/+archive/dev/+builds?build_state=building then it *looks* like those are all older than the current ones (14.0...)
[16:05] <gary_poster> ah ha yes
[16:05] <gary_poster> those are the bad ones
[16:05] <gary_poster> ok thanks!
[16:06] <bigjools> gary_poster: it's not easy to work this out, unfortunately
[16:06] <bigjools> gary_poster: I have some SQL that fixes these if you want it
[16:06] <gary_poster> because we don't know how those three would have gotten in that state, right?
[16:06] <bigjools> right
[16:06] <gary_poster> bigjools, it
[16:06] <bigjools> it's a bug somewhere else in the code - or it could be someone poking SQL
[16:06] <bigjools> I've not seen it happen for a long time
[16:06] <gary_poster> 's what you want, I'd say.  I'm happy to run the SQL
[16:07] <gary_poster> (arrange it to be run :-) )
[16:07] <bigjools> ok
[16:07] <gary_poster> we can put it in the bug report
[16:07] <bigjools> gary_poster: http://pastebin.ubuntu.com/653198/
[16:07] <gary_poster> and then not close the bug until we figure out something to do to actually provide some diagnostics as to how this might happen
[16:07] <bigjools> replace the XXX with the build ID
[16:08] <gary_poster> bigjools, do you have any easy/soyuz-novice thoughts on what we could do to add diagnostics so we can figure out how this would happen in the future?
[16:08] <gary_poster> (or simply notes I can put in the bug)
[16:09] <bigjools> gary_poster: I would trawl the build manager logs first
[16:09] <bigjools> remember my first rule of soyuz debugging? :)
[16:09] <gary_poster> heh
[16:09] <gary_poster> ok
[16:09] <bigjools> having said that, I don't know how many days of logs we keep for the manager
[16:10] <bigjools> it's quite verbose, so they get rotated often
[16:18] <gary_poster> ack
[16:32] <jml> just running some tests, got this: http://paste.ubuntu.com/653218/
[16:32] <jml> might be new since oneiric upgrade
[16:40] <mtaylor> hey lovely people!
[16:40] <mtaylor> https://help.launchpad.net/Bugs/ImportFormat says that I should file a question to get bugs imported - but there is no file attachment on questions that I can see...
[16:40] <mtaylor> how should I attach the file?
[16:45] <jml> I don't know.
[16:49] <mtaylor> yay!
[16:52] <sinzui> mtaylor, you point to a URL where the the xml is
[16:53] <mtaylor> sinzui: ah.
[16:53] <sinzui> mtaylor, someone will run cleanup script over the xml and test it on staging for you to review. there may be a report of of off ignored items that will require manual changes to the xml
[16:54] <mtaylor> sinzui: excellent. what happens with user ids that aren't valid launchpad user ids?
[16:54] <sinzui> I think profiles are created that users can claim
[16:55] <mtaylor> ok. but if I reference valid launchpad accounts all works as expected, yeah?
[16:55] <sinzui> yep
[16:55] <mtaylor> cool
[16:55] <mtaylor> I think I shall endeavor to make a username mapping before I actually give you a file then
[17:08] <jml> ok
[17:08] <jml> I'm trying to set up a lucid chroot to work around that rabbit timeout problem
[17:09] <jml> so I can submit patches to Launchpad
[17:09] <jml> but I'm told that, " launchpad-dependencies: Depends: python2.6 (>= 2.6.7-2ubuntu1) but 2.6.5-1ubuntu6 is to be installed or python-profiler but it is not installable
[17:09] <jml> "
[17:10] <jml> so, how do I get the correct version of Python?
[17:12] <jml> any help would be much appreciated.
[17:14] <maxb> jml: Enable multiverse
[17:14] <jml> maxb: really? wow. ok. thanks.
[17:14] <jml> maxb: why would a Python be in multiverse?
[17:14] <maxb> python-profiler's licence is a bit odd, IIRC
[17:15] <jml> ahh.
[17:16] <jml> maxb: great. it's installing. thanks.
[17:29] <jml> now rabbitmq won't install
[17:30] <jml> gotta kill the outside one
[17:30] <sinzui> jml, python-profiler is not required on oneiric
[17:30] <jml> sinzui: I can't run the tests on oneiric, http://paste.ubuntu.com/653218/
[17:30] <jml> sinzui: I've spent the last hour setting up a lucid chroot instead.
[17:31]  * sinzui looks at rabbit
[17:33] <sinzui> jml, I get the same error
[17:33] <jml> sinzui: it's nice to feel like part of a crowd
[17:35] <jml> now I get this in my chroot
[17:35] <jml> OperationalError: could not connect to server: No such file or directory
[17:35] <jml> 	Is the server running locally and accepting
[17:35] <jml> 	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
[17:35] <jml> http://paste.ubuntu.com/653266/
[17:37] <jml> maybe that's ... I'll run database-setup & check ports.
[17:38] <sinzui> I would remove the rabbit layer to proceed. Does your test really need it? I avoid the page test layer since it starts lots of services that are rarely needed by an individual test
[17:39] <sinzui> for example, the google layer is used by 2 tests in our suite
[17:40] <jml> sinzui: hmm.
[17:40] <jml> sinzui: it's PageTestLayer. I'm writing a webservice test.
[17:40] <sinzui> :(
[17:40] <sinzui> I hate that upper level
[17:41] <jml> sinzui: yeah, me too. I don't really have a clear vision of an alternative, though.
[17:41] <jml> at least, not for this.
[17:42] <sinzui> I am trying a hack to the timeout
[17:45] <sinzui> jml, I get: /usr/lib/rabbitmq/bin/rabbitmq-server: 63: cannot create /var/log/rabbitmq/rabbit@solstice.log.1: Permission denied
[17:45] <jml> sinzui: you're running oneiric too?
[17:46] <sinzui> yes
[17:46] <sinzui> I think I hacked the actual run command baddly
[17:46] <LPCIBot> Project db-devel build #759: STILL FAILING in 5 hr 42 min: https://lpci.wedontsleep.org/job/db-devel/759/
[17:52] <sinzui> jml, a pdb in _spawn implies rabbitmq did start. I saw four beam.smp process for it
[17:52] <sinzui> This might be a case were we are not reading $HOME/.erlang.cookie
[17:56] <sinzui> jml, looks like the cookie format changed. The server is up
[17:56] <jml> sinzui: ahh. cool.
[17:57] <bac> deryck: bug 788685 is finally marked qa-ok
[17:57] <_mup_> Bug #788685: Enable translating selected Ubuntu universe packages in Launchpad <escalated> <oem-services> <qa-ok> <Launchpad itself:Fix Committed by bac> <OEM Priority Project:Invalid> <Ubuntu Translations:Triaged> <pkgbinarymangler (Ubuntu):Fix Released by pitti> < https://launchpad.net/bugs/788685 >
[17:57] <deryck> bac: excellent!
[17:57] <bac> that frees up many branches as deployable
[17:58] <deryck> bac: ok, great.  I'll see about doing a nodowntime deploy before my day is out.  calls coming up here shortly now.
[17:58] <bac> the conch goes to wallyworld
[18:08] <sinzui> bac, wallyworld__'s bugs are now qa-ok
[18:09] <bac> sinzui: great
[18:21] <sinzui> jml, I really do not know how to fix rabbitmq. I see it running, but our fixture is not connecting to the nodes it started :(
[18:21] <jml> sinzui: :\
[18:21] <jml> sinzui: for the time being, I'm ok with running in lucid.
[18:21] <sinzui> okay
[18:40] <jml> ungh
[18:41] <jml> does whatever linter LP is using now not understand __all__ for re-exports?
[18:43] <jml> just use pyflakes. life will be better.
[18:46] <lifeless> micahg: please use the literal OOPS code, not the urls (there is a bug in ooptools)
[18:50] <lifeless> sinzui: you think we should just <elided> ? (bug 736012)
[18:50] <_mup_> Bug #736012: Person:+mailinglist-moderate timeout <mailing-lists> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736012 >
[18:52] <sinzui> lifeless, 1. we could write a script to remove the spam messages on the because we believe that this timeout was because of historic data
[18:52] <jml> is there a way to do check_permission but to pass in the user?
[18:52] <sinzui> and/or two change the batch size to a smaller number because we believe some list owners are negligent
[18:54] <sinzui> jml, no, but that would be a nice to have
[19:14] <bigjools> bac: https://dogfood.launchpad.net/ubuntu/natty/+source/epiphany-browser/2.30.6-1ubuntu6
[19:15] <bac> bigjools: and nothing shows up here: https://translations.dogfood.launchpad.net/ubuntu/natty/+source/epiphany-browser/+imports
[19:16] <bigjools> bac: does it show up there for oneiric?
[19:16] <bac> bigjools: https://translations.dogfood.launchpad.net/ubuntu/oneiric/+source/epiphany-browser/+imports  -- indeedy
[19:16] <bigjools> bac: qa-ok
[19:16] <bac> yep
[19:16] <bac> bigjools: thanks for your dogfoodness
[19:17] <bigjools> my pleasure
[19:17] <bac> (my mail client insisted on changing that to 'dogwood' every time i typed it.)
[19:30] <lifeless> sinzui: my question was because your comment on the bug was incomplete :)
[19:38] <sinzui> lifeless, my thoughts are still incomplete.
[19:38] <lifeless> sinzui: fair enough
[19:40] <benji> I'm trying to do a bug import (for the first time) and don't see how to do the actual import to staging (reading https://dev.launchpad.net/PolicyAndProcess/BugImportHowto).  Anyone have a hint?
[19:41] <lifeless> have a losa run the script
[19:43] <lifeless> bigjools: hi
[19:44] <lifeless> https://bugs.launchpad.net/launchpad/+bug/816870 quick q for you
[19:44]  * bigjools is not really here
[19:44] <_mup_> Bug #816870: Distribution:+search (package search) timeouts <Launchpad itself:Triaged> < https://launchpad.net/bugs/816870 >
[19:44] <lifeless> why is spr in that query ?
[19:44]  * bigjools looks
[19:44] <lifeless> oh, because it wants a distribution spc
[19:44] <deryck> lifeless: hey.  Trying to get a nodowntime request going.  I udpate this:
[19:44] <deryck> https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
[19:44] <bigjools> in a not-kind-of-here-way
[19:44] <lifeless> bigjools: thanks!
[19:45] <deryck> lifeless: is this right?  And what is the date column for?  Date requested or deployed?
[19:45] <lifeless> deryck: see under 'requested stable deploments'
[19:47] <deryck> lifeless: I don't follow.  Should what I added go under "requested" section?
[19:47] <deryck> or are you directing me at some info there?
[19:47] <bigjools> lifeless: it's making sure that it can match a binary name that's for a source in the distro
[19:47] <LPCIBot> Project devel build #924: STILL FAILING in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/924/
[19:47] <lifeless> bigjools: thanks
[19:47] <lifeless> bigjools: its a little inefficient :P
[19:48] <bigjools> lifeless: welcome to the soyuz data model
[19:48] <lifeless> deryck: the 'requested stable deployments' section has no date in it.
[19:48] <lifeless> deryck: so I think you were looking at the wrong part of the page
[19:48] <bigjools> efficiency was an after thought
[19:48] <deryck> lifeless: ah, gotchas now.  thanks.
[19:48] <lifeless> deryck: you have a request to make - you should follow the in-page docs at the 'requested stable deployments' section.
[19:51] <deryck> lifeless: think I got it now.  Do I ping a losa, or just adding to the wiki page is enough?
[19:53] <thedac> deryck: nodowntime deploy?
[19:54] <deryck> thedac: yes, indeed.
[19:55] <thedac> deryck: If the wiki is updated I will get rolling on it
[19:55] <deryck> thedac: awesome, thanks!
[19:55] <lifeless> deryck: a ping is usual
[19:55] <deryck> lifeless: gotcha.  Thanks for the hand holding. :)
[19:56] <lifeless> deryck: since you want to be around for the end, in case it goes boom
[19:56] <lifeless> deryck: and that means timeliness matters
[19:56] <deryck> ah, ok.
[19:56] <deryck> maybe I shouldn't have started one when I'm about to jump on a call then ;)
[19:56] <thedac> deryck: Do we need to hold off?
[19:56] <lifeless> deryck: it usually doesn't go boom
[19:56] <lifeless> thedac: no, its fine
[19:56] <thedac> ok
[19:57] <thedac> deryck: confirm revno: 13478
[19:57] <deryck> thedac: was just kidding mostly
[19:57] <lifeless> deryck: doing at your EOD would be ill advised though :)
[19:57] <deryck> gotcha :)
[19:57] <lifeless> thedac: that looks wrong
[19:57] <deryck> thedac: no, it's r13535
[19:57] <lifeless> we're running 13503 atm
[19:58] <thedac> huh, is this out of date then: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus
[19:58] <lifeless> thedac: see the 'roll out to' column
[19:58] <lifeless> thedac: and the requested-by column
[19:59] <lifeless> thedac: it may be out of date, but derycks request is sane ;)
[19:59] <benji> my CHR time's up and I didn't even get to questions
[20:00]  * bac CHRs
[20:03] <benji> the bug import?  That was indeed a question, but I got to it from the "bug import questions" link, I expect that there are other open questions
[20:03] <benji> pff, wrong hchan
[20:07] <jml> allenap: finally put up a fix for your *actual* testtools bug, as opposed to the one I thought you meant to file :)
[20:09] <micahg> lifeless: sorry, will do from now on
[20:15] <abentley> jml: I'm liking ExpectedException in general, but I'm thinking it could be generalized to take a Matcher as a parameter.  But assertThat only works in test cases, so maybe it should be TestCase.exceptionMatches ?
[20:16] <jml> abentley: that's what the patch does
[20:16] <abentley> jml: was not aware of a patch.
[20:16] <jml> abentley: https://code.launchpad.net/~jml/testtools/expected-exception-791889/+merge/69546
[20:17] <jml> it just raises AssertionError, rather than calling TestCase.fail
[20:17] <jml> which is almost always the same thing
[20:18] <henninge> anybody about to request a deploy?
[20:18] <abentley> jml: cool.
[20:18] <henninge> if not, I will now
[20:19] <jml> hmm. I should update docs & NEWS
[20:27] <henninge> ah, reloading LPS page helps ...
[20:28] <henninge> deryck: thanks for taking care of the deployment.
[20:29] <henninge> well, the deplyoment *request* ;-)
[20:52] <deryck> henninge: no worries.  It kind of all came together.
[20:54] <deryck> thedac: hi again.  Did the deploy go okay?  Or still in progress?
[20:54] <thedac> deryck: still in progress
[20:55] <deryck> thedac: ok.  thanks.
[20:55] <thedac> I think we are still just pushing code around at this point in the deploy script
[21:53] <wgrant> jml: python-profiler was the one part of the standard library that wasn't in the normal Python packages, because it had a non-free license. Disney bought the company and they only convinced them to relicense it this year. In oneiric and above it's in the core python2.* package.
[21:53] <deryck> I started a deploy with thedac couple hours ago but am now past EOD and need to go.  bad timing on my part. :)
[21:54] <deryck> Can I hand off to someone, to help thedac if he needs it?
[21:54] <wgrant> Sure.
[21:54] <wgrant> thedac: Where are we at?
[21:54] <deryck> wgrant: thanks so much!
[21:54] <wgrant> (thanks for organising the deploy, deryck!)
[21:54] <thedac> wgrant: using deployment-manager it is cranking along
[21:55] <wgrant> lpnet is updated.
[21:55] <wgrant> So we are nearly there.
[21:55] <deryck> wgrant, np!  I'll still claim it as my first deploy, even though I'm handing off. ;)
[21:55] <thedac> Just deployed  to germanium-scripts. It is hard for me to tell exactly how much more we have to go. But I think we are close
[21:55] <wgrant> The webapp is updated, so it's hardly handed off :)
[21:56] <deryck> :)
[21:57] <deryck> ok, until tomorrow then, everyone.....
[22:00] <thedac> wgrant: fyi, at this point the script is just doing cleanup. We should be fully deployed. I will update wiki and email when the script completes
[22:02] <wgrant> Thanks.
[22:11] <wgrant> thedac: Was loganberry's scripts target being deployed at 21:45?
[22:11] <wgrant> thedac: We have an odd piece of cronspam which suggests that either something rather terrible has happened, or the symlink was switched right as a cronjob started at 21:45.
[22:12] <thedac> wgrant: that seems likely. Let me check my scrollback to see if I have a time stamp
[22:14] <wgrant> It seems to be happy now, so I assume that was it, but best to check if we can.
[22:20] <thedac> wgrant that looks like that was it. The time stamp from a few actions prior was at 21:44. I don't have an exact one for loganberry but that has to be it
[22:20] <wgrant> Thanks.
[22:22] <lifeless> win!
[22:23] <lifeless> so thats what, a hundred or so deploys before hitting the race we suspect might exist
[22:23] <wgrant> Yup.
[22:23] <wgrant> I think that's pretty good.
[22:25] <wgrant> lifeless: So, is there a good reason that mailman is still in our tree?
[22:26] <lifeless> wgrant: yes, noone has done the work to make a SOA project out of it
[22:26] <wgrant> That's not a good reason.
[22:26] <lifeless> wgrant: .e.g a network test fake of the xmlrpc service LP offers mailman, and vice versa
[22:26] <lifeless> wgrant: theres no intent to keep it in-tree.
[22:27] <lifeless> wgrant: if that helps.
[22:27] <wgrant> Good, good.
[22:28] <wgrant> It seems like pretty low-hanging fruit.
[22:28] <wgrant> And annoying fruit.
[22:29] <lifeless> I need to blog about this notification change.
[22:29] <lifeless> grah.
[22:32] <wgrant> 'Copied from debian sid in Primary Archive for Debian GNU/Linux' woo
[22:33] <lifeless> is that in prod ?
[22:33] <wgrant> Yes.
[22:34] <wgrant> Of course, an extra 1000 packages also got synced...
[22:34] <wgrant> But, er, baby steps.
[22:34] <lifeless> by mistake ?
[22:34] <wgrant> By bug.
[22:34] <wgrant> Multiple bugs.
[22:34] <wgrant> Only 10 of them actually had Ubuntu changes.
[22:34] <wgrant> So 883 of the erroneous syncs hopefully didn't break too much.
[22:40] <wgrant> jelmer: Around?
[23:03] <wgrant> jelmer: https://pastebin.canonical.com/50371/ <- I'm reverting your publisher-use-debian2
[23:10] <sinzui> StevenK, mumble?
[23:13] <wgrant> gaaaaaaaaa just missed buildbot by 30 seconds
[23:13] <wgrant> 20 seconds, in fact.
[23:31] <LPCIBot> Project db-devel build #760: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/760/