[02:26] Really looking forward to parallel builds. One thing I really hate in the morning is finding that the branch I landed last night hasn't been through Buildbot yet. [02:41] jtv: Oh yeah [02:41] jtv: "I've been ignoring IRC and stuff for over 12 hours, and buildbot hasn't passed once!" [02:42] I'm surprised to find myself saying it, but that fact would have been more comforting if at least a build had failed in the meantime. [02:42] Well, db-devel did of course, but that aside. [02:43] buildbot is up to ~ 6 hours a run, too === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugtasks: 3*10^2 [02:44] Might as well put myself in the topic, given it's my last OCR for the year [02:53] StevenK: I'll just join you, for the same reason. === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, jtv | Critical bugtasks: 3*10^2 [02:53] There's been no visible progress in Q/A either [02:55] wallyworld_: I see sinzui landed a branch for you… it's just one of many Q/A blockers right now, but any chance you could get it out of the way? [02:55] jtv: The one that's bad and rolled back? [02:55] jtv: i'll have a look. i didn't realise it was out of buildbot [02:55] wgrant: no, the first blocker on the list. [02:55] Revision 14489 is bad: possible blocker. [02:55] bad, not needstesting [02:56] wallyworld_: we were just discussing how it does take far too long for a branch to come out of buildbot [02:56] Argh, yes, must be the lack of coffee. [02:56] wallyworld_: never mind — it seems to be broken. [02:56] In which case: do you know whether a fix is in the works? [02:56] jtv: yes, bb is too slow. what we are waiting for now is the fix to get through bb [02:56] the rollback in fact [02:56] Ah. [02:57] there's a new mp which is approved which should sort it all out [02:58] The MP has been merged onto DF [02:58] Julian's wrath be damned [02:58] StevenK: have you tried anything yet? [02:59] Not much, to be honest. [02:59] wallyworld_: Have at it [02:59] np. will do [02:59] Should all be easily reproducible locally. [03:04] wgrant, iwnbni there was a "content is private" ff [03:04] ff scope [03:04] Perhaps if we had a way to determine privacy... [03:06] Does anyone here have permission to edit http://blog.launchpad.net/ ? [03:06] Yes. [03:06] in the context of thanks buttons you can do a context.is-private [03:06] *is_private [03:06] huwshimi, me [03:06] poolie: For some things. [03:07] Could one of you take a look and see if there's a bunch of blank lines at the end of the latest post? [03:07] That is a lot of nbsps; [03:08] Fixed. [03:08] openid requires you attempt to click this button [03:08] wgrant: Thankyou! [03:10] np [03:10] huwshimi, how about if i just make you an editor? [03:10] poolie: That would be great [03:10] please thank you mum for giving you an easily greppable name [03:10] I thought I was [03:10] poolie: hah [03:10] *your [03:10] try now? [03:13] poolie: Ah great, thanks heaps [03:27] StevenK, wallyworld_, archive access looks correct on dogfood. Have you tried it? [03:28] sinzui: no. i'm just writing up a mp and will try it as soon as i hit "enter" [03:28] i can try now though [03:28] sinzui: I had a bit of a look. I can have a closer look if you wish. [03:31] sinzui: as me, i went to the link as suggested in the mp and it renders ok [03:32] StevenK, I have tried a few ppas. I think this is good. I can see the build, which could be argued as a no-no, but that is already visible to subscribers [03:32] wallyworld_: s/qastaging/dogfood/ ? [03:32] StevenK: dogfood [03:32] sorry, ambiguous [03:33] I can see the private team and the archive [03:33] StevenK, you can see the index page? [03:33] Of the team, yes [03:33] I cannot see the team page. [03:34] StevenK, are you playing admin again? [03:34] Oh, bloody hell, I think I have a duck [03:34] StevenK: in qas, i get an unauthorised error [03:34] for that link [03:34] * StevenK looks for his duck [03:34] StevenK, I removed myself from commercial admins to be sure I could not see private teams I was not a member of [03:34] which makes sense since the rollback hasn't landed [03:35] Right, I have unducked myself [03:35] Okay, I can see the archive [03:35] I can not see +packages [03:36] But that is expected [03:36] And I can't see the team [03:36] Land it! [03:36] I think I will [03:37] sinzui: I'm very tempted to delete PersonGPGView for being a crime against humanity. [03:37] It does have its probelms [03:38] * wallyworld_ crosses his fingers for 3rd time lucky with this branch [03:38] sinzui: Do you have a suggestion for what I can spend the rest of the day on? [03:38] StevenK, I have been pondering a desktop tool that lets me manage keys and signings without visiting Lp pages. gpg, coc, ssh all suck [03:39] Oh, the gpg edit page lies too [03:40] If you deactivate your key it warns it will deactivate your CoC signature too. But it doesn't. [03:46] StevenK, I wonder if your permission changes for nominations makes this bug any easier to solve https://bugs.launchpad.net/launchpad/+bug/297528 [03:46] <_mup_> Bug #297528: Permissions not checked properly when deciding whether to present "Target" or "Nominate" link < https://launchpad.net/bugs/297528 > [03:46] Hmmm [03:47] This annoys me too, but I think this is not really related to our recent permission changes: https://bugs.launchpad.net/launchpad/+bug/892025 [03:47] <_mup_> Bug #892025: Forbidden following link to configure code hosting <403> < https://launchpad.net/bugs/892025 > [03:49] StevenK, There is actually a featurette I would like to have fixed. I want a page or portlet that lists all the teams I own. i usually cheat and query staging [03:49] sinzui: In terms of the last one, we should not show the link if the user can't see trunk? [03:50] StevenK, I do not think privacy is the issue. I think the user is not an owner or driver so has no permission to set the series branch [03:51] Right. We can actually cheat for that [03:51] BugTask.userHasDriverPrivs(project, user) [03:51] If that's false, no link [03:54] StevenK, Given the misadventures with private teams. I really do not think any of us should work on the social private teams until the branch is qa-ok [03:55] Agreed. [03:56] * StevenK tries to work out which template adds that link [03:56] StevenK, than said I would like to know more about this https://bugs.launchpad.net/launchpad/+bug/611617 [03:56] <_mup_> Bug #611617: private teams cannot be package maintainers

< https://launchpad.net/bugs/611617 > [03:57] I really have no clue how to solve that one. [03:57] StevenK, If everything is private there should be no issue, but I think the issue here is that I could copy the package to a public archive [03:58] That is a tough one [03:58] SPR's inherient their privacy from the archive [04:00] I think we should allow it for private archives [04:00] But that then makes copying the SPR out even worse [04:00] Perhaps we should just reject it with a better message === jtv is now known as jtv-afk [04:02] StevenK: With the minor issue that then you can detect private teams. [04:02] This is why our model is so hilariously broken. [04:03] Right [04:03] sinzui: Shall I revert your branch off DF? [04:04] Oh, yes please. Has it clear buildbot? [04:05] PQM, or buildbot? [04:05] (the current approach to social private teams is even more of a trainwreck than legacy disclosure -- it's going to be just about impossible to tell who can see what, which is exactly the problem we're trying to solve) [04:05] I think we should just disclose all private teams. [04:06] The feature is called 'disclosure' after all. [04:06] lol [04:08] sinzui: Right, that configure codehosting thing is easy. [04:16] StevenK, wgrant: I added a comment about how we enforce the spr.maintainer restriction and muse about the options: https://bugs.launchpad.net/launchpad/+bug/611617 [04:16] <_mup_> Bug #611617: private teams cannot be package maintainers

< https://launchpad.net/bugs/611617 > [04:17] sinzui: If the team is private, they will be disclosed if the SPR is copied to a public archive [04:18] Perhaps private teams can't have email addresses. [04:18] And then they can't be maintainers [04:18] Exactly. [04:18] wgrant, I have considered such a restriction, I am not sure we can stop it [04:19] sinzui: Oh? [04:19] wgrant, I think users would rebel [04:19] Users can be told that they are wrong :) [04:20] We need to consider the usecases. [04:20] And then counter all of them :) [04:20] I should know how many private teams set the contact address, and how many of those are not an lp list [04:20] I think we should just forbid it [04:20] There are difficulties. [04:20] eg. package maintained by $RANDOM_OEM_TEAM_ADDRESS -- what do we show in LP? [04:20] However, we already have tonnes of unclaimed teams anyway... [04:21] Yes, farming for private team names being prime among them [04:21] A few more won't kill us. [04:27] yo hohoho [04:28] lifeless: How was your flight(s)? [04:28] Sigh. Timeouts on DF [04:28] inebriated [04:30] Oh, you've started drinking already? :-P [05:53] StevenK: why does the configure_codehosting method return False? I would have expected to see None [08:55] good morning [08:55] Hello adeuring. [08:55] hi rvba! [09:04] Morning === mpt_ is now known as mpt [09:42] wgrant: I couldn't manage to trigger a build on dogfood last time; maybe I just dput it wrong. On phone now; will see if I can get help [09:42] jtv: You don't have to upload something new. [09:42] You can copy or retry. [09:43] * jtv retries [09:49] wgrant: I wonder if I could reproduce the problem by retrying builds somehow. [09:51] jtv: That would be the easiest way, yes. [09:51] Question is: what do I retry? [09:51] Any old failed build that is superseded. [09:52] Superseded by a successful build? [09:52] Doesn't matter. [09:52] As long as the source is superseded. [09:52] How do I tell? [09:52] Just find an old version of something in Ubuntu that has a failed build. [09:53] There's a whole bunch of old test uploads for "hello" on dogfood: https://dogfood.launchpad.net/builders/concordia/+history [09:53] Can I just retry a bunch of those? [09:53] jtv: All the sysadmin bits are done now; do you think you could send https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 to EC2 for me? [09:54] http://paste.ubuntu.com/769864/ is my ~/.dput.cf for dogfood, BTW [09:54] pretty sure I uploaded at least one of those 'hello' versions [09:54] cjwatson: I'm afraid I can't. [09:55] Long story, but basically won't work. [09:55] wgrant: maybe you could land colin's branch? [09:55] wgrant: Also, can I just retry one of those "hello" test uploads? [09:56] If the corresponding source is superseded, sure. [09:56] Which it may not be because of the lack of regular DF publisher runs. [09:56] I can only run ec2 from my lucid container, which I swore not to start up for at least a few days after EOY. [09:58] wgrant: I can just run the publisher I guess. Question is: will that definitely supersede the hello uploads? [09:58] If they're in the same domination context. [09:59] They're all identical except in version number. [09:59] Or you could just find a failed build from dapper or something. [09:59] The packages don't matter. [09:59] The location does. [10:00] These are the only builds I see for this builder. The other builders are disabled [10:00] Is that relevant? [10:00] Things will build on any builder that's configured correctly. [10:01] And for our purposes we can configure concordia and clementine any way we want. [10:02] OK [10:02] linux and gnome-shell may be a bit much to build here. [10:03] Ah! base-files. [10:04] wgrant: base-files on ferraz had some older, failed builds. Will that work? [10:05] I'm not sure how that would affect anything. [10:06] Discuss. [10:07] The builder isn't relevant. [10:07] We don't even really care to any significant degree if the build succeeds or not. [10:08] We care that builds still dispatch, and that builds are correctly marked superseded when they are superseded. [10:08] Right. My concern right now is to try and get builds marked superseded, to see if that works. [10:10] What I'm trying to get out of you is which build I could retry at this point to trigger that code path. [10:13] Retry any build for a superseded source. [10:13] If it doesn't immediately start building, check the builder configuration. [10:14] And reassign one of the builders to match the build's config. [10:14] Even if it's for like powerpc or something. [10:14] Because we don't care if it fails. [10:14] Can I enable some builders? [10:15] bigjools: would you be available to send https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 to EC2 for me? Neither jtv nor wgrant can, at the moment [10:15] cjwatson: sure [10:15] jtv: Only if "some builders" ⊂ {ferraz,rubidium,concordia,clementine} [10:16] Aren't those the only ones we have on dogfood atm? [10:16] Nothing else is accessible. [10:16] Also, why a _proper_ subset? [10:16] Sure, but the others can be revived on DF if someone is sufficiently misguided or creative :) [10:16] Because I am lazy at tracking down Unicode characters :) [10:17] ⊆ if you must [10:17] bigjools: hooray [10:17] Thank you. [10:18] (Hmm. Do we think there'll be an opportunity for a cocoplum rollout after this at some point before the end of the year, what with lots of people being away?) [10:20] I certainly hope so. [10:20] We've got some fixes lined up for it. [10:20] If we can deploy the poppy fix in the next day or two, future cocoplum rollouts should be relatively harmless and require minimal supervision. [10:20] Whereas all Soyuz rollouts at the moment require close observation. [10:21] You call it observation, I call it disaster tourism. Looks like some builds on dogfood are now stuck in the uploading phase. [10:21] jtv: There's a cron job for that.™ [10:21] jtv: you need to run a script [10:21] Probably disabled, though. [10:21] it is [10:21] Don't enable that, or bigjools will SMACK YOU ON THE HEAD [10:21] DF doesn't have enough coal [10:21] bigjools: thank you, I'll just run a script then shall I? [10:21] jtv: perfect :) [10:21] bigjools: Well, more than puppet steals all of the little coal that DF has... [10:22] tell me about it [10:22] But... but... what about its _carbon footprint_? :) [10:22] bigjools: any script in particular..? [10:22] jtv: it needs to be bigger [10:22] bigjools: That's also behind most of the recent PPA builder unreliability, it turns out. [10:22] bigjools: run a bigger script? [10:22] bigjools: puppet is causing the hosts of several builders to OOM [10:22] jtv: "crontab -l" and find the process-upload that deals with builds [10:22] “It's Puppet! Help!” [10:23] wgrant: \o/ [10:23] nobody pays attention to memory usage when coding these days [10:24] and also ruby. [10:24] that's the tradeoff with GCed languages [10:24] Well. [10:24] Python is particularly bad. [10:24] And Ruby is far worse than Python. [10:24] It's not really the GCedness. [10:24] let me guess... puppet is Python? [10:24] Puppet is Ruby. [10:24] Ruby [10:24] Python is mostly bad in how much memory it uses in the first place. [10:24] jtv: Right. [10:24] well when you start doing your own new/malloc, you are very aware of memory :) [10:24] The GC is not a problem. [10:25] process-upload --builds has finished [10:25] depends on the problem [10:25] All serious programmers should go through stages of manual memory allocation. And preferably machine code, to teach them how useful structured programming is. [10:25] how many GCs are there for Java? :) [10:25] jtv: +1 [10:26] bigjools: java is different. It produces more garbage. [10:26] I was horrifed a school teaching kids how to use MS products in an "IT" lesson [10:26] fix grammar as appropriate --^ [10:26] IObjectCreationFactory object_creation_factory = new ObjectCreationFactory(); IMyObject my_object = object_creation_factory.makeObject(); [10:26] bigjools: That's pretty universally nowadays. [10:26] Computing courses are MS + Java. [10:26] wgrant: an Aussie school :/ [10:27] * jtv prefers informatics over information technology, really [10:27] bigjools: Oh, you mean like a primary or secondary school? [10:27] I handed them my business card and talked about Ubuntu [10:27] primary [10:27] IT classes involve teaching Microsoft Office [10:27] exactly [10:27] And old versions of Dreamweaver. [10:27] Or FrontPage 2000. [10:27] Although my old high school recently started teaching VB6 in year 8. [10:27] Let's just ignore that VB6 was superseded 9 years ago. [10:28] At least it's something. [10:28] wgrant: "year 8" as in "2003 years ago"? [10:28] 2003 was year 7, tyvm. [10:28] Well they were 1-based then. [10:28] As can still be observed in VB6. [10:29] Heh [10:29] Apparently Dijkstra once proposed the compromise of having arrays start at 0.5. [10:29] Although my uni teaches Python, then goes into C, then Java, then Haskell and Prolog. [10:29] No C++, which is odd. [10:30] It's not a great teaching language today. [10:31] Mine started with ML on the grounds that more or less nobody knew it already so it created a level playing field. [10:31] Huh, interesting choice. [10:32] It's supposed to be pretty good, no? [10:32] IIRC I started with OCaml based on the same assumption I guess. [10:32] It's not a bad language. [10:32] Not that I've retained very much of it. [10:32] Oh, sure, it's not bad. Just a rather unconventional choice for a first, I would have thought. [10:32] jtv: How goes the dogfood wrangling? [10:32] Right, it was because the course population was part self-taught-programmers and part people starting from scratch. [10:33] cjwatson: Ah. [10:33] wgrant: still building an old hello. But I'm not sure it's properly superseded. [10:33] cjwatson: These days they tend to just ignore the self-taught people and let them rot. [10:33] Speaking as a self-taught programmer, I liked our approach. ;-) [10:33] And then they go and do stuff like spend implausible amounts of time on Ubuntu and LP instead. [10:33] * bigjools was taught algol68... [10:34] My MUM was taught Algol 68 [10:34] thankfully I had already taught myself C [10:34] On punched cards [10:34] is this turning into a your mum joke? :) [10:34] No, I'm actually serious :-) [10:34] I know :/ [10:34] Oh, maybe it was 60 [10:34] my uni was so up to date [10:34] bigjools: .au schools are unlikely to do anything except Microsoft, because all the state education departments have hugely expensive contracts with Microsoft which give unlimited licenses of just about every product to primary and secondary schools. [10:35] wgrant: I'll see about that when I get there [10:35] Getting a $100 discount on a $150 license must be better than a $0 discount on a free license. [10:35] I already converted my local school here :) [10:35] jtv: The schools have to pay nothing. [10:35] it's insidious MS practice [10:35] jtv: The state government pays it all. [10:35] And it's not cheap. [10:35] bigjools: So THAT's it. You're done here, time to move to the next one [10:36] Exactly. [10:36] It's a very effective abusive Microsoft tactic. [10:36] So all the schools see is that all this Microsoft software is completely free! [10:36] No licensing concerns whatsoever. [10:39] jtv: That source doesn't look very superseded. [10:40] However, the build succeeded, so that's one case tested... [10:41] Is the publisher still going, or has the dominator broken? [10:41] There's like 40 versions of hello published in precise-release, which is somewhat unconventional. [10:41] stub, I've updated https://code.launchpad.net/~gmb/launchpad/openid-data-integrity-bug-894390/+merge/84750; could you take a look when you get a second? [10:43] wgrant: yay! The other build I was waiting for says "Build for superseded Source." [10:44] jtv: That sounds qa-ok if there's no traceback around. [10:44] Where would I find the traceback? [10:44] The builder went back to idle, by the way, as it should. [10:44] /srv/launchpad.net/dogfood-logs/buildd-manager.log or something like that. [10:44] That's a good sign. [10:46] jtv: Looks like this is close to deployable. [10:46] (the bad rev has an untagged rollback in r14500) [10:51] wgrant: a few things that _might_ be bad in the logs, though I'm hoping they're not: [10:51] Builder 'clementine' rescued from 'bb672c8535728724706a9b7885dba0c11f084c5b': 'No job assigned to builder' [10:51] Builder 'clementine' being cleaned up from ABORTED [10:52] that's ok [10:52] This is after some no-route-to-host errors for clementine. [10:52] That's fine. [10:52] Just clementine being clementine. [10:53] concordia logs some frightening but, on closer inspection, probably okay stuff: ***** RESULT ***** etc. [10:53] That's normal. [10:53] Soyuz likes stars. [10:53] No tracebacks. [10:53] I have to leave very soon. bigjools, is this enough for you to carry on with? [10:54] jtv: did you retry a failed, superseded build? [10:55] that's all you need [10:55] Yes. [10:55] then it's ok [10:55] I marked it qa-ok. [10:55] Two tiny bits of abentley QA, then you can deploy. [10:55] Oh, and jelmer. [10:56] When does db-devel get updated? [10:57] oh, hullo [10:57] jtv: At the next */10 after buildbot completes. [10:57] jtv: Why? [10:58] Got a db-devel branch waiting to land, once a particular devel revision has been merged in. [10:58] Ah. [10:58] Won't pass tests without that revision. [10:59] Really? [10:59] Oh. [10:59] Right. [10:59] It's the test, mind you, not the "real" code [10:59] Because the populator tests will create them unset. [10:59] Never mind me. [10:59] Exactly. === matsubara-afk is now known as matsubara [11:08] bigjools: I left instructions on bug 849683. Would be most grateful if you could pursue. [11:08] <_mup_> Bug #849683: {B,S}PPH Populator are temporary

< https://launchpad.net/bugs/849683 > [11:08] Please let me know now if I left anything out! [11:09] jtv: ok! [11:09] It looks as if, if I wanted to play things fast & loose, I could pqm-submit the second branch right now. But… [11:16] * jtv is off. HNY! [11:31] * cjwatson tries to bisect that test problem jtv mentioned yesterday (swapped e-mail addresses in a few soyuz tests) [11:32] cjwatson: I have a suspicion it's arch differences. [11:32] I've only seen it on i386 so far. [11:32] buildbot/ec2 are amd64 [11:32] It started somewhere between r14434 and r14450 [11:32] (Because I didn't see it while working on refactor-cron-germinate, which I branched from r14434) [11:33] Ah, hm. [11:33] Interesting. [11:33] Although I'll verify that in a bit ... [11:39] wgrant: Sorry, I'm wrong. I must just not have run those tests. [11:47] Ah [11:47] recipients = [ [11:47] format_address_for_person(person) [11:47] for person in filter(None, set(candidate_recipients)) [11:47] if person.preferredemail is not None] [11:47] So that's non-deterministic because it depends on what order set(candidate_recipients) happens to iterate in [11:47] Is that in notify() ? [11:48] lib/lp/soyuz/adapters/notification.py:get_upload_notification_recipients [11:48] Because it looks horrifingly familar [11:48] It is [11:48] Maybe TestMailer.send should sort? [11:48]