[02:26] <jtv> 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] <StevenK> jtv: Oh yeah
[02:41] <StevenK> jtv: "I've been ignoring IRC and stuff for over 12 hours, and buildbot hasn't passed once!"
[02:42] <jtv> 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] <jtv> Well, db-devel did of course, but that aside.
[02:43] <StevenK> buildbot is up to ~ 6 hours a run, too
[02:44] <StevenK> Might as well put myself in the topic, given it's my last OCR for the year
[02:53] <jtv> StevenK: I'll just join you, for the same reason.
[02:53] <jtv> There's been no visible progress in Q/A either
[02:55] <jtv> 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] <wgrant> jtv: The one that's bad and rolled back?
[02:55] <wallyworld_> jtv: i'll have a look. i didn't realise it was out of buildbot
[02:55] <jtv> wgrant: no, the first blocker on the list.
[02:55] <wgrant> Revision 14489 is bad: possible blocker.
[02:55] <wgrant> bad, not needstesting
[02:56] <jtv> wallyworld_: we were just discussing how it does take far too long for a branch to come out of buildbot
[02:56] <jtv> Argh, yes, must be the lack of coffee.
[02:56] <jtv> wallyworld_: never mind — it seems to be broken.
[02:56] <jtv> In which case: do you know whether a fix is in the works?
[02:56] <wallyworld_> jtv: yes, bb is too slow. what we are waiting for now is the fix to get through bb
[02:56] <wallyworld_> the rollback in fact
[02:56] <jtv> Ah.
[02:57] <wallyworld_> there's a new mp which is approved which should sort it all out
[02:58] <StevenK> The MP has been merged onto DF
[02:58] <StevenK> Julian's wrath be damned
[02:58] <wallyworld_> StevenK: have you tried anything yet?
[02:59] <StevenK> Not much, to be honest.
[02:59] <StevenK> wallyworld_: Have at it
[02:59] <wallyworld_> np. will do
[02:59] <wgrant> Should all be easily reproducible locally.
[03:04] <poolie> wgrant, iwnbni there was a "content is private" ff
[03:04] <poolie> ff scope
[03:04] <wgrant> Perhaps if we had a way to determine privacy...
[03:06] <huwshimi> Does anyone here have permission to edit http://blog.launchpad.net/ ?
[03:06] <wgrant> Yes.
[03:06] <poolie> in the context of thanks buttons you can do a context.is-private
[03:06] <poolie> *is_private
[03:06] <poolie> huwshimi, me
[03:06] <wgrant> poolie: For some things.
[03:07] <huwshimi> 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] <wgrant> That is a lot of nbsps;
[03:08] <wgrant> Fixed.
[03:08] <poolie> openid requires you attempt to click this button
[03:08] <huwshimi> wgrant: Thankyou!
[03:10] <wgrant> np
[03:10] <poolie> huwshimi, how about if i just make you an editor?
[03:10] <huwshimi> poolie: That would be great
[03:10] <poolie> please thank you mum for giving you an easily greppable name
[03:10] <huwshimi> I thought I was
[03:10] <huwshimi> poolie: hah
[03:10] <poolie> *your
[03:10] <poolie> try now?
[03:13] <huwshimi> poolie: Ah great, thanks heaps
[03:27] <sinzui> StevenK, wallyworld_, archive access looks correct on dogfood. Have you tried it?
[03:28] <wallyworld_> sinzui: no. i'm just writing up a mp and will try it as soon as i hit "enter"
[03:28] <wallyworld_> i can try now though
[03:28] <StevenK> sinzui: I had a bit of a look. I can have a closer look if you wish.
[03:31] <wallyworld_> sinzui: as me, i went to the link as suggested in the mp and it renders ok
[03:32] <sinzui> 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] <StevenK> wallyworld_: s/qastaging/dogfood/ ?
[03:32] <wallyworld_> StevenK: dogfood
[03:32] <wallyworld_> sorry, ambiguous
[03:33] <StevenK> I can see the private team and the archive
[03:33] <sinzui> StevenK, you can see the index page?
[03:33] <StevenK> Of the team, yes
[03:33] <sinzui> I cannot see the team page.
[03:34] <sinzui> StevenK, are you playing admin again?
[03:34] <StevenK> Oh, bloody hell, I think I have a duck
[03:34] <wallyworld_> StevenK: in qas, i get an unauthorised error
[03:34] <wallyworld_> for that link
[03:34]  * StevenK looks for his duck
[03:34] <sinzui> StevenK, I removed myself from commercial admins to be sure I could not see private teams I was not a member of
[03:34] <wallyworld_> which makes sense since the rollback hasn't landed
[03:35] <StevenK> Right, I have unducked myself
[03:35] <StevenK> Okay, I can see the archive
[03:35] <StevenK> I can not see +packages
[03:36] <StevenK> But that is expected
[03:36] <StevenK> And I can't see the team
[03:36] <StevenK> Land it!
[03:36] <sinzui> I think I will
[03:37] <StevenK> sinzui: I'm very tempted to delete PersonGPGView for being a crime against humanity.
[03:37] <sinzui> It does have its probelms
[03:38]  * wallyworld_ crosses his fingers for 3rd time lucky with this branch
[03:38] <StevenK> sinzui: Do you have a suggestion for what I can spend the rest of the day on?
[03:38] <sinzui> 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] <StevenK> Oh, the gpg edit page lies too
[03:40] <StevenK> If you deactivate your key it warns it will deactivate your CoC signature too. But it doesn't.
[03:46] <sinzui> 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 <lp-bugs> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297528 >
[03:46] <StevenK> Hmmm
[03:47] <sinzui> 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> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/892025 >
[03:49] <sinzui> 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] <StevenK> sinzui: In terms of the last one, we should not show the link if the user can't see trunk?
[03:50] <sinzui> 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] <StevenK> Right. We can actually cheat for that
[03:51] <StevenK> BugTask.userHasDriverPrivs(project, user)
[03:51] <StevenK> If that's false, no link
[03:54] <sinzui> 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] <StevenK> Agreed.
[03:56]  * StevenK tries to work out which template adds that link
[03:56] <sinzui> 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 <disclosure> <lp-soyuz> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/611617 >
[03:57] <wgrant> I really have no clue how to solve that one.
[03:57] <sinzui> 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] <StevenK> That is a tough one
[03:58] <StevenK> SPR's inherient their privacy from the archive
[04:00] <StevenK> I think we should allow it for private archives
[04:00] <StevenK> But that then makes copying the SPR out even worse
[04:00] <StevenK> Perhaps we should just reject it with a better message
[04:02] <wgrant> StevenK: With the minor issue that then you can detect private teams.
[04:02] <wgrant> This is why our model is so hilariously broken.
[04:03] <StevenK> Right
[04:03] <StevenK> sinzui: Shall I revert your branch off DF?
[04:04] <sinzui> Oh, yes please. Has it clear buildbot?
[04:05] <StevenK> PQM, or buildbot?
[04:05] <wgrant> (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] <StevenK> I think we should just disclose all private teams.
[04:06] <StevenK> The feature is called 'disclosure' after all.
[04:06] <wallyworld_> lol
[04:08] <StevenK> sinzui: Right, that configure codehosting thing is easy.
[04:16] <sinzui> 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 <disclosure> <lp-soyuz> <privacy> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/611617 >
[04:17] <StevenK> sinzui: If the team is private, they will be disclosed if the SPR is copied to a public archive
[04:18] <wgrant> Perhaps private teams can't have email addresses.
[04:18] <StevenK> And then they can't be maintainers
[04:18] <wgrant> Exactly.
[04:18] <sinzui> wgrant, I have considered such a restriction, I am not sure we can stop it
[04:19] <wgrant> sinzui: Oh?
[04:19] <sinzui> wgrant, I think users would rebel
[04:19] <wgrant> Users can be told that they are wrong :)
[04:20] <wgrant> We need to consider the usecases.
[04:20] <wgrant> And then counter all of them :)
[04:20] <sinzui> I should know how many private teams set the contact address, and how many of those are not an lp list
[04:20] <StevenK> I think we should just forbid it
[04:20] <wgrant> There are difficulties.
[04:20] <wgrant> eg. package maintained by $RANDOM_OEM_TEAM_ADDRESS -- what do we show in LP?
[04:20] <wgrant> However, we already have tonnes of unclaimed teams anyway...
[04:21] <StevenK> Yes, farming for private team names being prime among them
[04:21] <wgrant> A few more won't kill us.
[04:27] <lifeless> yo hohoho
[04:28] <StevenK> lifeless: How was your flight(s)?
[04:28] <StevenK> Sigh. Timeouts on DF
[04:28] <lifeless> inebriated
[04:30] <StevenK> Oh, you've started drinking already? :-P
[05:53] <wallyworld_> StevenK: why does the configure_codehosting method return False? I would have expected to see None
[08:55] <adeuring> good morning
[08:55] <rvba> Hello adeuring.
[08:55] <adeuring> hi rvba!
[09:04] <danhg> Morning
[09:42] <jtv> 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] <wgrant> jtv: You don't have to upload something new.
[09:42] <wgrant> You can copy or retry.
[09:43]  * jtv retries
[09:49] <jtv> wgrant: I wonder if I could reproduce the problem by retrying builds somehow.
[09:51] <wgrant> jtv: That would be the easiest way, yes.
[09:51] <jtv> Question is: what do I retry?
[09:51] <wgrant> Any old failed build that is superseded.
[09:52] <jtv> Superseded by a successful build?
[09:52] <wgrant> Doesn't matter.
[09:52] <wgrant> As long as the source is superseded.
[09:52] <jtv> How do I tell?
[09:52] <wgrant> Just find an old version of something in Ubuntu that has a failed build.
[09:53] <jtv> There's a whole bunch of old test uploads for "hello" on dogfood: https://dogfood.launchpad.net/builders/concordia/+history
[09:53] <jtv> Can I just retry a bunch of those?
[09:53] <cjwatson> 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] <cjwatson> http://paste.ubuntu.com/769864/ is my ~/.dput.cf for dogfood, BTW
[09:54] <cjwatson> pretty sure I uploaded at least one of those 'hello' versions
[09:54] <jtv> cjwatson: I'm afraid I can't.
[09:55] <jtv> Long story, but basically won't work.
[09:55] <jtv> wgrant: maybe you could land colin's branch?
[09:55] <jtv> wgrant: Also, can I just retry one of those "hello" test uploads?
[09:56] <wgrant> If the corresponding source is superseded, sure.
[09:56] <wgrant> Which it may not be because of the lack of regular DF publisher runs.
[09:56] <wgrant> 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] <jtv> wgrant: I can just run the publisher I guess.  Question is: will that definitely supersede the hello uploads?
[09:58] <wgrant> If they're in the same domination context.
[09:59] <jtv> They're all identical except in version number.
[09:59] <wgrant> Or you could just find a failed build from dapper or something.
[09:59] <wgrant> The packages don't matter.
[09:59] <wgrant> The location does.
[10:00] <jtv> These are the only builds I see for this builder.  The other builders are disabled
[10:00] <wgrant> Is that relevant?
[10:00] <wgrant> Things will build on any builder that's configured correctly.
[10:01] <wgrant> And for our purposes we can configure concordia and clementine any way we want.
[10:02] <jtv> OK
[10:02] <jtv> linux and gnome-shell may be a bit much to build here.
[10:03] <jtv> Ah!  base-files.
[10:04] <jtv> wgrant: base-files on ferraz had some older, failed builds.  Will that work?
[10:05] <wgrant> I'm not sure how that would affect anything.
[10:06] <jtv> Discuss.
[10:07] <wgrant> The builder isn't relevant.
[10:07] <wgrant> We don't even really care to any significant degree if the build succeeds or not.
[10:08] <wgrant> We care that builds still dispatch, and that builds are correctly marked superseded when they are superseded.
[10:08] <jtv> Right.  My concern right now is to try and get builds marked superseded, to see if that works.
[10:10] <jtv> 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] <wgrant> Retry any build for a superseded source.
[10:13] <wgrant> If it doesn't immediately start building, check the builder configuration.
[10:14] <wgrant> And reassign one of the builders to match the build's config.
[10:14] <wgrant> Even if it's for like powerpc or something.
[10:14] <wgrant> Because we don't care if it fails.
[10:14] <jtv> Can I enable some builders?
[10:15] <cjwatson> 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] <bigjools> cjwatson: sure
[10:15] <wgrant> jtv: Only if "some builders" ⊂ {ferraz,rubidium,concordia,clementine}
[10:16] <jtv> Aren't those the only ones we have on dogfood atm?
[10:16] <wgrant> Nothing else is accessible.
[10:16] <jtv> Also, why a _proper_ subset?
[10:16] <wgrant> Sure, but the others can be revived on DF if someone is sufficiently misguided or creative :)
[10:16] <wgrant> Because I am lazy at tracking down Unicode characters :)
[10:17] <wgrant> ⊆ if you must
[10:17] <cjwatson> bigjools: hooray
[10:17] <jtv> Thank you.
[10:18] <cjwatson> (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] <jtv> I certainly hope so.
[10:20] <jtv> We've got some fixes lined up for it.
[10:20] <wgrant> 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] <wgrant> Whereas all Soyuz rollouts at the moment require close observation.
[10:21] <jtv> You call it observation, I call it disaster tourism.  Looks like some builds on dogfood are now stuck in the uploading phase.
[10:21] <wgrant> jtv: There's a cron job for that.™
[10:21] <bigjools> jtv: you need to run a script
[10:21] <wgrant> Probably disabled, though.
[10:21] <bigjools> it is
[10:21] <wgrant> Don't enable that, or bigjools will SMACK YOU ON THE HEAD
[10:21] <bigjools> DF doesn't have enough coal
[10:21] <jtv> bigjools: thank you, I'll just run a script then shall I?
[10:21] <bigjools> jtv: perfect :)
[10:21] <wgrant> bigjools: Well, more than puppet steals all of the little coal that DF has...
[10:22] <bigjools> tell me about it
[10:22] <jtv> But... but... what about its _carbon footprint_?  :)
[10:22] <jtv> bigjools: any script in particular..?
[10:22] <bigjools> jtv: it needs to be bigger
[10:22] <wgrant> bigjools: That's also behind most of the recent PPA builder unreliability, it turns out.
[10:22] <jtv> bigjools: run a bigger script?
[10:22] <wgrant> bigjools: puppet is causing the hosts of several builders to OOM
[10:22] <bigjools> jtv: "crontab -l" and find the process-upload that deals with builds
[10:22] <jtv> “It's Puppet!  Help!”
[10:23] <bigjools> wgrant: \o/
[10:23] <bigjools> nobody pays attention to memory usage when coding these days
[10:24] <wgrant> and also ruby.
[10:24] <bigjools> that's the tradeoff with GCed languages
[10:24] <wgrant> Well.
[10:24] <wgrant> Python is particularly bad.
[10:24] <wgrant> And Ruby is far worse than Python.
[10:24] <wgrant> It's not really the GCedness.
[10:24] <bigjools> let me guess... puppet is Python?
[10:24] <wgrant> Puppet is Ruby.
[10:24] <soren> Ruby
[10:24] <jtv> Python is mostly bad in how much memory it uses in the first place.
[10:24] <wgrant> jtv: Right.
[10:24] <bigjools> well when you start doing your own new/malloc, you are very aware of memory :)
[10:24] <wgrant> The GC is not a problem.
[10:25] <jtv> process-upload --builds has finished
[10:25] <bigjools> depends on the problem
[10:25] <jtv> 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] <bigjools> how many GCs are there for Java? :)
[10:25] <bigjools> jtv: +1
[10:26] <jtv> bigjools: java is different.  It produces more garbage.
[10:26] <bigjools> I was horrifed a school teaching kids how to use MS products in an "IT" lesson
[10:26] <bigjools> fix grammar as appropriate --^
[10:26] <jtv> IObjectCreationFactory object_creation_factory = new ObjectCreationFactory(); IMyObject my_object = object_creation_factory.makeObject();
[10:26] <wgrant> bigjools: That's pretty universally nowadays.
[10:26] <wgrant> Computing courses are MS + Java.
[10:26] <bigjools> wgrant: an Aussie school :/
[10:27]  * jtv prefers informatics over information technology, really
[10:27] <wgrant> bigjools: Oh, you mean like a primary or secondary school?
[10:27] <bigjools> I handed them my business card and talked about Ubuntu
[10:27] <bigjools> primary
[10:27] <wgrant> IT classes involve teaching Microsoft Office
[10:27] <bigjools> exactly
[10:27] <wgrant> And old versions of Dreamweaver.
[10:27] <wgrant> Or FrontPage 2000.
[10:27] <wgrant> Although my old high school recently started teaching VB6 in year 8.
[10:27] <wgrant> Let's just ignore that VB6 was superseded 9 years ago.
[10:28] <wgrant> At least it's something.
[10:28] <jtv> wgrant: "year 8" as in "2003 years ago"?
[10:28] <wgrant> 2003 was year 7, tyvm.
[10:28] <jtv> Well they were 1-based then.
[10:28] <jtv> As can still be observed in VB6.
[10:29] <wgrant> Heh
[10:29] <jtv> Apparently Dijkstra once proposed the compromise of having arrays start at 0.5.
[10:29] <wgrant> Although my uni teaches Python, then goes into C, then Java, then Haskell and Prolog.
[10:29] <wgrant> No C++, which is odd.
[10:30] <jtv> It's not a great teaching language today.
[10:31] <cjwatson> Mine started with ML on the grounds that more or less nobody knew it already so it created a level playing field.
[10:31] <wgrant> Huh, interesting choice.
[10:32] <jtv> It's supposed to be pretty good, no?
[10:32] <rvba> IIRC I started with OCaml based on the same assumption I guess.
[10:32] <cjwatson> It's not a bad language.
[10:32] <cjwatson> Not that I've retained very much of it.
[10:32] <wgrant> Oh, sure, it's not bad. Just a rather unconventional choice for a first, I would have thought.
[10:32] <wgrant> jtv: How goes the dogfood wrangling?
[10:32] <cjwatson> Right, it was because the course population was part self-taught-programmers and part people starting from scratch.
[10:33] <wgrant> cjwatson: Ah.
[10:33] <jtv> wgrant: still building an old hello.  But I'm not sure it's properly superseded.
[10:33] <wgrant> cjwatson: These days they tend to just ignore the self-taught people and let them rot.
[10:33] <cjwatson> Speaking as a self-taught programmer, I liked our approach. ;-)
[10:33] <wgrant> 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] <cjwatson> My MUM was taught Algol 68
[10:34] <bigjools> thankfully I had already taught myself C
[10:34] <cjwatson> On punched cards
[10:34] <bigjools> is this turning into a your mum joke? :)
[10:34] <cjwatson> No, I'm actually serious :-)
[10:34] <bigjools> I know :/
[10:34] <cjwatson> Oh, maybe it was 60
[10:34] <bigjools> my uni was so up to date
[10:34] <wgrant> 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] <bigjools> wgrant: I'll see about that when I get there
[10:35] <jtv> Getting a $100 discount on a $150 license must be better than a $0 discount on a free license.
[10:35] <bigjools> I already converted my local school here :)
[10:35] <wgrant> jtv: The schools have to pay nothing.
[10:35] <bigjools> it's insidious MS practice
[10:35] <wgrant> jtv: The state government pays it all.
[10:35] <wgrant> And it's not cheap.
[10:35] <jtv> bigjools: So THAT's it.  You're done here, time to move to the next one
[10:36] <wgrant> Exactly.
[10:36] <wgrant> It's a very effective abusive Microsoft tactic.
[10:36] <wgrant> So all the schools see is that all this Microsoft software is completely free!
[10:36] <wgrant> No licensing concerns whatsoever.
[10:39] <wgrant> jtv: That source doesn't look very superseded.
[10:40] <wgrant> However, the build succeeded, so that's one case tested...
[10:41] <wgrant> Is the publisher still going, or has the dominator broken?
[10:41] <wgrant> There's like 40 versions of hello published in precise-release, which is somewhat unconventional.
[10:41] <gmb> 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] <jtv> wgrant: yay!  The other build I was waiting for says "Build for superseded Source."
[10:44] <wgrant> jtv: That sounds qa-ok if there's no traceback around.
[10:44] <jtv> Where would I find the traceback?
[10:44] <jtv> The builder went back to idle, by the way, as it should.
[10:44] <wgrant> /srv/launchpad.net/dogfood-logs/buildd-manager.log or something like that.
[10:44] <wgrant> That's a good sign.
[10:46] <wgrant> jtv: Looks like this is close to deployable.
[10:46] <wgrant> (the bad rev has an untagged rollback in r14500)
[10:51] <jtv> wgrant: a few things that _might_ be bad in the logs, though I'm hoping they're not:
[10:51] <jtv> Builder 'clementine' rescued from 'bb672c8535728724706a9b7885dba0c11f084c5b': 'No job assigned to builder'
[10:51] <jtv> Builder 'clementine' being cleaned up from ABORTED
[10:52] <bigjools> that's ok
[10:52] <jtv> This is after some no-route-to-host errors for clementine.
[10:52] <wgrant> That's fine.
[10:52] <wgrant> Just clementine being clementine.
[10:53] <jtv> concordia logs some frightening but, on closer inspection, probably okay stuff: ***** RESULT ***** etc.
[10:53] <wgrant> That's normal.
[10:53] <wgrant> Soyuz likes stars.
[10:53] <jtv> No tracebacks.
[10:53] <jtv> I have to leave very soon.  bigjools, is this enough for you to carry on with?
[10:54] <bigjools> jtv: did you retry a failed, superseded build?
[10:55] <bigjools> that's all you need
[10:55] <jtv> Yes.
[10:55] <bigjools> then it's ok
[10:55] <jtv> I marked it qa-ok.
[10:55] <wgrant> Two tiny bits of abentley QA, then you can deploy.
[10:55] <wgrant> Oh, and jelmer.
[10:56] <jtv> When does db-devel get updated?
[10:57] <jelmer> oh, hullo
[10:57] <wgrant> jtv: At the next */10 after buildbot completes.
[10:57] <wgrant> jtv: Why?
[10:58] <jtv> Got a db-devel branch waiting to land, once a particular devel revision has been merged in.
[10:58] <wgrant> Ah.
[10:58] <jtv> Won't pass tests without that revision.
[10:59] <wgrant> Really?
[10:59] <wgrant> Oh.
[10:59] <wgrant> Right.
[10:59] <jtv> It's the test, mind you, not the "real" code
[10:59] <wgrant> Because the populator tests will create them unset.
[10:59] <wgrant> Never mind me.
[10:59] <jtv> Exactly.
[11:08] <jtv> 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 <disclosure> <qa-untestable> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/849683 >
[11:08] <jtv> Please let me know now if I left anything out!
[11:09] <bigjools> jtv: ok!
[11:09] <jtv> 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] <wgrant> cjwatson: I have a suspicion it's arch differences.
[11:32] <wgrant> I've only seen it on i386 so far.
[11:32] <wgrant> buildbot/ec2 are amd64
[11:32] <cjwatson> It started somewhere between r14434 and r14450
[11:32] <cjwatson> (Because I didn't see it while working on refactor-cron-germinate, which I branched from r14434)
[11:33] <wgrant> Ah, hm.
[11:33] <wgrant> Interesting.
[11:33] <cjwatson> Although I'll verify that in a bit ...
[11:39] <cjwatson> wgrant: Sorry, I'm wrong.  I must just not have run those tests.
[11:47] <cjwatson> Ah
[11:47] <cjwatson>     recipients = [
[11:47] <cjwatson>         format_address_for_person(person)
[11:47] <cjwatson>         for person in filter(None, set(candidate_recipients))
[11:47] <cjwatson>             if person.preferredemail is not None]
[11:47] <cjwatson> So that's non-deterministic because it depends on what order set(candidate_recipients) happens to iterate in
[11:47] <StevenK> Is that in notify() ?
[11:48] <cjwatson> lib/lp/soyuz/adapters/notification.py:get_upload_notification_recipients
[11:48] <StevenK> Because it looks horrifingly familar
[11:48] <StevenK> It is
[11:48] <cjwatson> Maybe TestMailer.send should sort?
[11:48] <StevenK> That's notify(), effectively
[11:48] <cjwatson> Rather than imposing sorting on production
[11:48] <bigjools> IIRC something sorts somewhere
[11:48] <cjwatson> Doesn't seem to here
[11:49] <cjwatson> reject_changes_file calls get_upload_notification_recipients and passes the answer to send_email
[11:49] <StevenK> cjwatson: Most of that code is my fault.
[11:49] <cjwatson> er, send_mail
[11:50] <StevenK> cjwatson: However, you should have seen it before I hacked it to pieces.
[11:51] <cjwatson> How about I file a bug and ignore to-address ordering failures in the branch I'm working on?
[11:53] <StevenK> cjwatson: So, to-address ordering is actually causing you issues?
[11:54] <cjwatson> Yes
[11:54] <cjwatson> Let me file this bug and point you to it rather than repeating it all :-)
[11:57] <cjwatson> StevenK: bug 904220
[11:57] <_mup_> Bug #904220: Soyuz tests with lists of e-mail addresses are non-deterministic <Launchpad itself:New> < https://launchpad.net/bugs/904220 >
[11:58] <StevenK> Hmmm, I see.
[11:59] <StevenK> Interesting how set() behaves differently on i386 vs amd64.
[11:59] <wgrant> Hardly.
[11:59] <wgrant> The ordering is undefined.
[11:59] <StevenK> Well, *I* find it interesting. You may not.
[12:01] <bigjools> in a testicle scratching kind of way
[12:01] <StevenK> bigjools: While I remember, it looks like the instant diff works fine!
[12:01] <bigjools> yay!
[12:01] <StevenK> bigjools: However, it doesn't AJAX-ify the other information that creating a diff shows
[12:01] <bigjools> there's a bug about that
[12:02] <StevenK> bigjools: Such as "Diff against target". Is there a bug?
[12:02] <StevenK> Ah
[12:02] <bigjools> look for tag "longpoll"
[12:02] <bigjools> this is why only ~launchpad can see it for now
[12:08] <StevenK> bigjools: How are you breaking Kindle screens so easily?!
[12:08] <bigjools> StevenK: I have no idea
[12:08] <bigjools> but they are happy to keep sending replacements
[12:10] <StevenK> I read a blog post about this recently. How Kindles started as expensive electronics device and was treated with kid gloves and so on, and has declined to, "Oh, whatever, it's like $80."
[13:15] <cjwatson> bigjools: I'd like to fix bug 619088; it's been annoying me for a while.  Is there likely to be any problem with just changing FTPArchiveHandler to remove a slew of "are there any udebs to publish" conditionals?
[13:15] <_mup_> Bug #619088: d-i indices in -proposed appear and disappear <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/619088 >
[13:16] <cjwatson> (Also bug 118227 and probably bug 240965.)
[13:16] <_mup_> Bug #118227: main/debian-installer missing from Release files <feature> <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/118227 >
[13:16] <_mup_> Bug #240965: publisher doesn't deal with pockets becoming empty <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/240965 >
[13:17] <bigjools> cjwatson: hard to say without looking in more detail but it can't be that hard
[13:21] <cjwatson> I don't know why it was made conditional in the first place; I'm assuming it was a misplaced sense of tidiness
[14:05] <sinzui> gmb, do you have time to review my branch fixes https://code.launchpad.net/~sinzui/launchpad/builds-without-component-0/+merge/85400
[14:20] <gary_poster> hi mrevell. bac sent out an email yesterday to launchpad-dev titled "Milestone tags".  It is in response to an escalated request from Danilo.  This affects you because our current proposed solution will (minimally) add a relatively small feature to milestones (you can tag them) and project groups (you can see a report of blueprints and bugs filtered by the milestones that have a given tag).  sinzui has given his blessing for this idea, and indeed
[14:20] <gary_poster> it began with his brainwave.  We'd like to proceed with this on the sprint right now.  May we?  Would you like a call to discuss?
[14:21] <sinzui> I think danilo also blessed the proposal
[14:21] <gary_poster> (mrevell, Danilo has given his blessing on the general approach, and we are working on mockups now
[14:21] <gary_poster> )
[14:21] <cr3> hi folks, I would appreciate some assistance with the concept of bug subscriptions in Launchpad. yesterday, I unsubscribed to the dell-team bugs as can be seen from the following screenshot but I'm still being emails with the X-Launchpad-Message-Rationale set to "Subscriber @dell-team": http://people.canonical.com/~cr3/bug_subscriptions.png
[14:21] <gary_poster> right sinzui, thank you
[14:21] <cr3> might there be something I'm not understanding about this feature?
[14:22] <mrevell> gary_poster, otp. I saw the email, have been in solid calls today so far. Will ping when I'm free.
[14:22] <gary_poster> thanks mrevell.
[14:22] <sinzui> cr3 a feature is new behaviour that requires guidance and acceptance by stakeholders
[14:23] <cr3> sinzui: this is new behavior, as far as I can tell, and it's not getting my acceptance so far :(
[14:23] <sinzui> :)
[14:23] <cr3> sinzui: but it does require guidance though, so I'm all yours :)
[14:24] <gary_poster> cr3, it is still possible to to get emails.  If you look at that page and expand all reasons why you get emails, it should give you a reason.  If not, AFAIK this is a recent regression
[14:25] <cr3> sinzui: I had been looking forward to this feature for a while to reduce the volume of bug mail I receive and simplify my procmail rules, without having to unsubscribe from teams to preserve access to their online bugs, branches, etc.
[14:25] <cr3> gary_poster: I toggled the "other subscriptions" link, my screenshot is the only item in the list
[14:26] <sinzui> cr3 we know something is a bug because there are already rules from stakeholders/someone that we can see are contradicted. When a bug is escalated, we should not need to treat the fix as a feature. In some cases, a bug is escalated because the stakeholder believes it will achieve their goal, but it does not, Understanding the motive for the escalation cane reveal a feature-like issue
[14:26] <gary_poster> cr3, then correct, you should not be getting anything from this list.  We have tests for the behavior and it has been in the wild for some time now without complaints I know of, so this may be an odd regression
[14:26] <cr3> gary_poster: here's the full page screenshot: http://people.canonical.com/~cr3/bug_subscriptions_full.png
[14:27] <gary_poster> (sinzui, you know cr3 is talking about bug subscriptions and not milestone tags, right?)
[14:27] <cr3> gary_poster: this applies to a bunch of lists, not only dell-team. I receive a *lot* of email
[14:27] <sinzui> gary_poster, I do not :)
[14:27] <cr3> gary_poster: do your tests cover private teams/bugs?
[14:27] <gary_poster> sinzui :-)
[14:28] <gary_poster> cr3, yes, I think so.  the page you showed me shows that there is a reason you still receive email.
[14:28] <gary_poster> cr3, the first box under "Other subscriptions" is the explanation
[14:28] <cr3> gary_poster: but it says: You do not receive emails from this subscription.
[14:28] <gary_poster> cr3, and the way to address it is to follow the advice on the right
[14:28] <gary_poster> cr3, that is a separate subscription
[14:29] <gary_poster> cr3, that is *your* subscription in the second box
[14:29] <gary_poster> cr3, the first box is a subscription for a team of which you are a part
[14:29] <gary_poster> cr3, that gets into mailman sending stuff
[14:29] <gary_poster> cr3, we can't control at that level
[14:30] <gary_poster> cr3, so you need to ask the Dell team to unsubscribe generally (or disable your emails from that list I guess)
[14:30] <cr3> gary_poster: ok, so I absolutely need to contact the administrator of the team so that I don't receive bug mail anymore, right?
[14:31] <gary_poster> cr3, yes.
[14:31] <gary_poster> cr3, and the request will be this:
[14:31] <gary_poster> cr3, could we no longer be subscribed as a team, so I can control what emails I receive?
[14:33] <cr3> gary_poster: can I find instructions to do this, I'm not finding such an option in the +edit page of a team of a team I can obviously edit :)
[14:43] <gary_poster> cr3, sorry was on call.  You are not an administrator of the team, or else the action links on your subscription page would show you what you could do about this.  As it is, the action (right-hand) link for that box gives you the only option you have: contact the administrators.  I suggest that you do this.  The link there takes you straight to the contact page and you can send them an email.  Give them a link to the page you are on now.  For admi
[14:43] <gary_poster> nistrators, when they look at the full list of "Other subscriptions" they will be able to see and disable these subscriptions from this page.
[14:44] <gary_poster> cr3, actually...
[14:45] <gary_poster> cr3, it looks like they are *directly subscribed* to this bug.  This is different that the blanket structural subscription.  Again, this page should explain to the administrator why this has happened, and what they can do about it,
[14:45] <gary_poster> .
[14:47] <abentley> adeuring: lay it on me.
[14:47] <adeuring> abentley: https://code.launchpad.net/~adeuring/launchpad/bug-903852/+merge/85651
[14:50] <cr3> gary_poster: so I need to edit how a team is subscribed to all bugs while looking at the +subscriptions page of a specific bug as an administrator, right? if so, sounds like this option should be provided from the team overview or the team bugs landing page...
[14:51] <cr3> gary_poster: so, I'm looking at a +subscriptions page as an administrator and I see what you mean: Edit this subscription. however, this seems to give me the option of changing the volume of bug mails sent, not whether the members of the team can unsubscribe themselves. might I be misunderstanding something?
[14:54] <abentley> adeuring: Our style guide recommends "!Y.Lang.isUndefined()" (or isValue) rather than "!== undefined"
[14:54] <adeuring> abentley: ah, ok, I'll change it
[14:55] <abentley> adeuring: For the loop that's causing a lint error, you could use Y.each.  It's a pretty nice interface.
[14:55] <adeuring> abentley: ok
[14:56] <flacoste> sinzui: i have another potential gotcha for you around the LimitedView permission
[14:56] <sinzui> oh dear
[14:56] <flacoste> sinzui: it's not a big deal really, more of a polish thing
[14:57] <flacoste> well, maybe, it's more than polish
[14:57] <flacoste> but it's fairly easy to solve
[14:57] <flacoste> the LP API uses the launchpad.View permission to check if should give the link to an object
[14:57] <sinzui> ah
[14:57] <flacoste> otherwise, the link will be the tag:redacted-....
[14:57] <flacoste> one
[14:58] <sinzui> Ian and I discussed that...well we guessed that
[14:58]  * sinzui reports bugs
[14:59] <abentley> adeuring: did you consider making SORT_KEYS a mapping?  Seem that would make the lookup simpler.
[15:00] <adeuring> abentley: the data must be sorted: the order in the object defines the order of the sort buttons on the listing pages
[15:01] <flacoste> sinzui: simply changing the configued permission to check would to the trick
[15:01] <flacoste> sinzui: as this is only an optimizaiton to see if the user will be able to get anything out of the object
[15:02] <flacoste> sinzui: actually marshalling catches exception Unauthorized exceptiond substitutes the redacted tag
[15:02] <abentley> adeuring: JavaScript associative arrays actually are ordered, but I'm quite happy not to depend on that fact.
[15:02] <adeuring> abentley: yes, but now the original dat is defined in Python...
[15:03] <gary_poster> cr3, sorry was on call again.  Could you give me another screenshot of the +subscriptions page with you as an administrator?
[15:04] <cr3> gary_poster: http://people.canonical.com/~cr3/bug_subscriptions_admin.png
[15:09] <abentley> adeuring: This looks like a nice improvement r=me.
[15:09] <adeuring> abentley: thanks!
[15:09] <gary_poster> cr3, that's a different bug
[15:09] <gary_poster> cr3, the options show depending on how you are subscribed
[15:09] <cr3> gary_poster: indeed, one for which I'm an administrator :)
[15:09] <gary_poster> cr3, and who you are
[15:10] <gary_poster> cr3, right, but it's a completely different situation
[15:10] <gary_poster> well, a different situation
[15:10] <gary_poster> cr3, on http://people.canonical.com/~cr3/bug_subscriptions_full.png it says that you are subscribed because the dell team is directly subscribed to the bug.
[15:11] <cjwatson> bigjools: damnit.  working on that failing test in refactor-cron-germinate now ...
[15:11] <gary_poster> cr3, so the things you want to do there are (less importantly) unsubscribe the team from that bug and (more importantly) figure out why the dell team was subscribed to that bug, and if it was automatic, change things so that it is not automatic
[15:12] <gary_poster> only admins can do that kind of thing, and will get info about it
[15:12] <cr3> gary_poster: I'm pretending that I'm the person that I will be contacting with the message you suggested: could we no longer be subscribed as a team, so I can control what emails I receive?
[15:14] <cr3> gary_poster: hm, I don't think that will happen, I think logs of bugs are still going to be assigned to the dell-team and many other teams I happen to be a member of because that's how they work
[15:14] <gary_poster> cr3, I'm on a sprint.  I want to help you.  Maybe we could go faster on a call so I can get back to the sprint?  Skype would be easiest for me.  I have voip set up but I haven't tried it
[15:16] <sinzui> abentley, can you review https://code.launchpad.net/~sinzui/launchpad/builds-without-component-0/+merge/85400
[15:17] <abentley> sinzui: sure thing.
[15:17] <cr3> gary_poster: thanks for the offer, very nice of you. I now understand the feature better and it seems to require changes on the side of the teams about their policy for bugs
[15:17] <gary_poster> cr3, right
[15:17] <gary_poster> cr3 (which the page can help them with, fwiw, but policy changes can require discussion)
[15:19] <gary_poster> cr3 (fwiw, Launchpad has disabled most of these team subscriptions so that people can get the emails they want.  some team emails can be controlled by LP, but if a mailing list is involved, or if a direct subscription is involved, there's only so much we can do))
[15:20] <sinzui> I see test_view_with_component has a rubbish comment. Sorry
[15:21] <cr3> gary_poster: yeah, I now have a much better understanding of what's going on. I wish there was a way to communicate this more clearly somehow in the web interface so that you don't have to deal with people like me trying to wrap their brains around the problem :)
[15:22] <gary_poster> cr3, me too :-) there probably is, but this was the best the mockup/user testing process came up with for this time around.  It's a complex situation
[15:22] <cjwatson> bigjools: Test fixed.  Sorry about that!  Would you mind resubmitting?
[15:23] <bigjools> cjwatson: yes, can you remind me of the MP URL please?
[15:29] <cjwatson> bigjools: https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624 - it's still thinking about the updated diff, but the fix was http://bazaar.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/revision/14471
[16:04] <abentley> deryck: could you review the refactoring? https://code.launchpad.net/~abentley/launchpad/cleanup/+merge/85689
[16:06] <deryck> abentley, look at you asking me before the diff is up…. ;)
[16:07] <abentley> deryck: diff is up now.
[16:08] <deryck> abentley, ah, only 1500!  That's baby diff in js! :)
[16:08] <deryck> abentley, sure, I'll do it.
[16:08] <abentley> deryck: Thanks.
[16:08] <rick_h__> abentley: have a sec for that assistance?
[16:09] <abentley> rick_h__: sure.
[16:09] <rick_h__> abentley: diff: https://code.launchpad.net/~rharding/launchpad/link_tags_894726/+merge/85673 and I seemed to have killed the test here: https://pastebin.canonical.com/57117/
[16:09] <rick_h__> abentley: but in looking at the test that fails I don't see it hitting this BugTaskListing stuff at all
[16:10] <abentley> rick_h__: looking...
[16:13] <abentley> rick_h__: nothing looks obviously wrong in that regard.
[16:14] <rick_h__> abentley: ok, updating devel and going to run the test there to see if it's not me
[16:14] <rick_h__> abentley: any other suggetsions on how to generate the urls I should rethink?
[16:14] <rick_h__> abentley: it feels a litlte bit dirty in the model like that, but works
[16:14] <abentley> rick_h__: So you're assuming that the URL doesn't have a query, but I don't know why that would be true.
[16:15] <rick_h__> abentley: the thought was this was a partial solution /easy hack. It doesn't remember things, just resets you to that tag view
[16:16] <rick_h__> abentley: so it's not cascading the options through the tag link click
[16:16] <abentley> rick_h__: But isn't it going to generate URLs like http://bugs.launchpad.net/bzr?order_by=importance?field.tag=bar ?
[16:17] <abentley> rick_h__: Anyhow, to generate these urls, you do canonical_url(bugtask)
[16:18] <abentley> rick_h__: No, wait.
[16:18] <rick_h__> abentley: no, the getURL() doens't seem to have the query params
[16:18] <rick_h__> abentley: and the tag link isn't in relation to the current bugTask item
[16:19] <abentley> rick_h__: So, canonical_url(target, rootsite=bugs) should generate the url for a listing page.
[16:20] <rick_h__> abentley: target_context?
[16:21] <abentley> rick_h__: maybe.
[16:21] <abentley> rick_h__: What does the existing code do?
[16:22] <rick_h__> the current code builds a string of the tags and sets it to the tags property of the model build
[16:22] <rick_h__> abentley: ^
[16:23] <abentley> what
[16:23] <abentley> rick_h__: is the model build?
[16:24] <rick_h__> abentley: sorry, meant the tag attr of the model property that's built
[16:25] <abentley> rick_h__: No, what does the existing code that generates URLs for tags do?
[16:26] <rick_h__> abentley: oh, so I just needed to build a url like the ones built in the .pt files: tal:attributes="href string:${context/target/fmt:url}/+bugs?field.tag=${tag}">tag</a>
[16:26] <rick_h__> abentley: so in order to get at the url of the current request, I found self.request.getURL() which seems to return a nice base url for the current request
[16:27] <rick_h__> abentley: and I manually build the ?field.tag=$tag onto the end of the url and return it as part of the model
[16:28] <rick_h__> abentley: so in order to do that I had to make the request argument to the BugTaskListingItem required vs an option kwarg
[16:29] <abentley> rick_h__: So the literal translation of that is something like canonical_url(bugtask.context.target, view_name="+bugs") + "field.tag=" + tagname
[16:30] <rick_h__> abentley: ok, I'll try that out and then back out the request argument changes
[16:30] <rick_h__> abentley: thanks
[16:31] <abentley> np
[16:32] <abentley> rick_h__: I'm somewhat surprised to see that canonical_url doesn't support specifying query params.
[16:34] <abentley> rick_h__: It looks like there's potential for XSS here.
[16:34] <rick_h__> abentley: right, since it doesn't go through the tal filter?
[16:34] <rick_h__> abentley: looks like context is a protected attribute as well so looking at how to put this together
[16:35] <abentley> rick_h__: I think the issue is that <>& are not going to be escaped if you just do "+tagname"
[16:36] <rick_h__> abentley: right, checking mustache's escaping options
[16:36] <abentley> rick_h__: But they're escaped by mustache, so that should be fine.
[16:36] <rick_h__> abentley: are they? ok cool
[16:36] <abentley> {{}} escapes, {{{}}} doesn't.
[16:36] <rick_h__> abentley: gotcha, works for me
[16:58] <bac> flacoste: i've created bug 904335 and moved the 'escalated' tag to it
[16:58] <_mup_> Bug #904335: Project groups need  a way to aggregate project milestones <escalated> <linaro> <Launchpad itself:Triaged> < https://launchpad.net/bugs/904335 >
[16:59] <flacoste> bac: did you remove the escalated tag from the other one as well?
[16:59] <bac> flacoste: i did
[16:59] <flacoste> bac: thanks! and for testing the -proposed candidates
[17:00] <bac> flacoste: np
[17:24] <deryck> abentley, r=me with some minor formatting things I'll mention in my comment.
[17:40] <sinzui> jcsackett, are you really about with net, or 3g?
[17:44] <jcsackett> sinzui: i still have net atm.
[17:44] <sinzui> jcsackett, do you have few minutes to discuss limitedview pages on mumble
[17:45] <jcsackett> sinzui: certainly, just a moment whilst i fire up mumble.
[17:53] <abentley> deryck: thanks.
[17:54] <deryck> abentley, np!
[17:56] <drunk_rambler> needed leads on how i can start of contributing to ubuntu
[18:21] <rick_h__> abentley: have time to review? https://code.launchpad.net/~rharding/launchpad/link_tags_894726/+merge/85673
[18:21] <abentley> rick_h__: sure.
[18:21] <rick_h__> abentley: ty
[18:23] <abentley> rick_h__: since bugtask.target is not going to vary, it seems strange to call canonical_url(self.bugtask.target, view_name="+bugs") more than once.
[18:23] <rick_h__> abentley: true
[18:27] <abentley> rick_h__: Here again we have the unfortunate pystache scoping bug.  It would be nice to do { "mustache_model": {tag_url_base: canonica_url(target)}, bugtasks[…]}, but tag_url_base wouldn't be visible in a loop.
[18:28] <rick_h__> abentley: right, I'm pushing a change to generate a tag_base_url and then the completion just takes that + tag string to generate the url
[18:28] <rick_h__> abentley: but yea, the wasted iterations :(
[18:45] <abentley> rick_h__: Do we still need tags, or can tag_urls replace it?
[18:46] <abentley> rick_h__: what's the &nbsp for?
[18:47] <rick_h__> abentley: we don't use tags, I guess I thought it made sense to keep as part of the model
[18:47] <rick_h__> abentley: but if I moved tag_urls onto tags perhaps that would be best and you could get at the tag strings easily
[18:48] <abentley> rick_h__: No, if we don't use it in the mustache template, we shouldn't have it in the mustache model.
[18:48] <rick_h__> abentley: the &nbsp; was just because of lint I had to newline the {{tags}}{{/tags}} and I wanted to be sure we always get the space seperation
[18:48] <rick_h__> abentley: ok, I'll move the tags_urls to just tags then
[18:49] <abentley> rick_h__: The newline after </a> should ensure that we get space separation, without imposing extra spacing.
[18:50] <rick_h__> abentley: yes, the &nbsp; was just the most clear way to indicate a space MUST be here
[18:52] <rick_h__> abentley: updates pushed
[18:54] <abentley> rick_h__: I think the changes to lib/lp/bugs/browser/cvereport.py are unnecessary.
[18:55] <abentley> rick_h__: other than that, this looks fine.
[18:55] <rick_h__> abentley: ok, thanks
[18:56] <abentley> rick_h__: I note that the review is marked "work in progress".  Is that done now?
[18:57] <rick_h__> abentley: yes, I just marked the bug in progress. I had forgotten to do that earilier
[18:57] <rick_h__> abentley: guess it flipped the status
[18:57] <rick_h__> abentley: ah nvm, wrong 'in progress'
[19:14] <lifeless> benji: / gary_poster: did jtv nab you guys to talk translation stats jobs ?
[19:15] <gary_poster> lifeless, I've asked benji to investigate and connect with jtv.  AIUI, he is hoping to talk to gmb, because benji believes that some of those scripts are still being run
[19:16] <gary_poster> lifeless, that's benji's top priority ATM
[19:16] <lifeless> cool.
[19:16] <gmb> benji, gary_poster, et. al.: I'm finally back online and available to talk should I be needed.
[19:16] <lifeless> Its my understanding that the new job is a good step but missed a couple of key bits from the analysis done on /one/ of the earlier bugs
[19:17] <lifeless> I wanted to say that its great to see things being made more incremental, and even if more work is needed to get it fully covering the issues etc - its great to see it being tackled.
[19:18] <gary_poster> lifeless, that's what I got from jtv's bug too.  the other key bits *may* be handled elsewhere.  gmb, thanks.  benji knows the questions he needs to ask you better than I.
[19:20] <gary_poster> lifeless, on an unrelated note, I have gotten my lxc stuff in a very broken state.  When I try to use lxc-create it doesn't succeed because the container does not have network access.  This is despite having the local.conf per your instructions, and ifconfig reporting a virbr0 around.  Do you know any resources I have to get some help with this?  I doubt this is something I can contact normal Ubuntu support with
[19:21] <gary_poster> note that this was working fine earlier on the same machine. :-/
[19:21] <lifeless> gary_poster: hallyn or spamaps in #ubuntu-server will be good contacts.
[19:21] <gary_poster> ok thanks
[19:22] <lifeless> that said, can you paste the exact config you are using, and the output of
[19:22] <lifeless> sudo brctl show
[19:22] <lifeless> ip route
[19:28] <abentley> deryck: A further tweak: https://code.launchpad.net/~abentley/launchpad/cleanup-2/+merge/85731
[19:29] <lifeless> gary_poster: I will reply to the tag thing after I've had a few more hours to cogitate and recover from last nights party
[19:33] <deryck> abentley, ok, about to go to lunch for my dentist appointment.  I'll look when I get back.
[19:33] <abentley> deryck: sure.
[20:20] <lifeless> gary_poster: would you mind moving your draft onto the original LXC page? Its confusing to me to have two pages to worry about updating
[20:20] <gary_poster> lifeless, sure, yeah.  You don't mind losing the natty info?
[20:20] <lifeless> gary_poster: We don't need natty instructions at all now
[20:21] <gary_poster> ok cool
[20:21] <lifeless> gary_poster: only needed it until O was released.
[20:21] <gary_poster> I'll do it in just a sec.  call
[20:21] <lifeless> staff need to be running lucid/O/P anyhow; and community contributors can always look in the page history if they want old docs.
[20:26] <gary_poster> ack
[20:55] <jtv> cjwatson: I'm unexpectedly temporarily back... I see you're in dogfood.  Mind if I upgrade it?  Involves a restart of its launchpad instance, buildmaster etc.
[20:56] <gary_poster> jtv, hi!  benji, look, I see jtv!
[20:56] <lifeless> lol
[20:56] <jtv> No you don't.
[20:56] <gary_poster> oh, it was a mirage...
[20:56] <jtv> Yes.
[20:56] <lifeless> 'I see absent people'
[20:56] <gary_poster> Have uyou seen any droids?
[20:56] <jtv> Go back to work.  You'll forget this ever didn't happen.
[20:56] <cjwatson> jtv: just a screen session doing nothing of importance; feel free.  Will that be up to r14516?
[20:56] <jtv> This isn't the jtv you're looking for.
[20:56] <lifeless> we have to update our 500 page
[20:56] <gary_poster> :-)
[20:57] <lifeless> http://www.flickr.com/photos/girliemac/6509400855/in/set-72157628409467125 courtesy mwhudson
[20:57] <jtv> cjwatson: it'll be the latest, uh, devel I think.
[20:57] <benji> jtv: hi, have a second to talk about bug 903532?
[20:57] <jtv> benji: I would say "yes" but your second is already up.  :)
[20:57]  * jtv throws an impatient look at the resident bugbot
[20:58] <jtv> Ah, that one.
[20:58] <jtv> Yes, I'll give you a whole minute if you want.
[20:58] <gary_poster> lifeless, hee hee :-)
[20:58] <cjwatson> jtv: Excellent, that'll include the thing I'll need to QA RSN, then.
[20:59] <mwhudson> http://www.flickr.com/photos/girliemac/sets/72157628409467125/ has been posted to twitter 546 times in the last day
[20:59] <mwhudson> (according to isitold.com)
[20:59] <gary_poster> heh
[20:59] <cjwatson> jtv: (Incidentally: is upgrading dogfood just a matter of running 'upgrade-dogfood-launchpad'?)
[20:59] <jtv> Yes, it should be.
[20:59] <jtv> I'm doing that right now, in fact.
[21:00] <benji> jtv: first, I can't find evidence (other than the statistics not being right) that verify-pofile-stats-daily and verify-pofile-stats have been disabled; of course, verify-pofile-stats had collapsed under its own weight some time ago, as I understand it
[21:00] <jtv> It used to be a bit more depends-on and now-run-the-other but I don't like that stuff.  Looks too much like work.
[21:00] <jtv> benji: I didn't find them in the cron tabs.
[21:00] <benji> jtv: where are the cron tabs?
[21:01] <jtv> lp:lp-production-crontabs I think.
[21:01] <jtv> bzr+ssh://bazaar.launchpad.net/%2Bbranch/lp-production-crontabs/
[21:02] <jtv> jelmer, frankban: do you think you'll be able to finish your pending Q/A soon?
[21:04] <benji> jtv: that's exactly what I was looking for, thanks!  we need to get those reinstated -- well verify-pofile-stats-daily, my understanding is that verify-pofile-stats is essentially useless now
[21:04] <jtv> Correct on both counts.
[21:04] <jtv> Unfortunately we still _need_ verify-pofile-stats!
[21:04] <sinzui> abentley, can you see this branch https://code.qastaging.launchpad.net/~private-registry-test-team/+junk/newtest2
[21:05] <abentley> sinzui: yes.
[21:05] <sinzui> fab. thanks abentley
[21:06] <gary_poster> jtv, we need it but reinstating will accomplish nothing without more work, right jtv?
[21:06] <jtv> gary_poster: that follows logically, yes.
[21:07] <benji> jtv: can you unpack that a bit, the ghost of Danilo thinks otherwise, see comment #9 on bug 781274
[21:07] <_mup_> Bug #781274: rosetta-pofile-stats script takes more than a week to complete <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/781274 >
[21:07] <frankban> jtv: yes I will finish my QA work within an hour
[21:08] <jtv> frankban: great, thanks
[21:09] <jtv> benji: that would only apply if the bug it refers to had been fully fixed.
[21:09] <jtv> Instead, we now have a partial implementation.
[21:10] <jtv> What the bug specified (with a bit of excessive detail that I would argue with, which I'll skip over for now) is “do the statistics updates in a separate job, and have each job update not just a single POFile but its entire sharing set.”
[21:10] <jtv> The latter part is not implemented AFAICS.
[21:11] <jtv> Which leaves us without the biggest thing the statistics script did for us: patch up statistics for POFiles that were affected by changes in shared translations.
[21:11] <benji> jtv: gotcha, that leads me to the second half; I can't say that I completely understand the details of how the shared translations need to be updated when an individual POFile is changed; will you outline that for me?
[21:12] <jtv> It's not so much that shared translations need to be updated, but that they _are_ updated and the statistics need to reflect that.
[21:12] <jtv> A template can share translations with a bunch of other templates.
[21:13] <jtv> Therefore, a POFile can share translations with other POFiles: those whose templates share with its template, translated to the same language.
[21:13] <jtv> Say POFile A shares with POFile B.
[21:13] <jtv> They are both completely untranslated.
[21:14] <jtv> Going through the UI for POFile  A, I translate POTMsgSet x.
[21:14] <jtv> But x is also shared with B's template.
[21:14] <jtv> We always updated statistics for A at this point,
[21:14] <jtv> but B obviously also needs its statistics updated because it is no longer completely untranslated.
[21:15] <jtv> There was no code to do that immediately; too complex and too costly.
[21:15] <jtv> Instead, we relied on the statistics updater that was already in place.
[21:16] <jtv> And so, in the current design, the pofilestatsjob needs to look up a full set of sharing POFiles and update all their statistics.
[21:16] <jtv> In my opinion the current design is not that great for template imports, where we'd basically have to look up the sharing set twice (and once in the critical path).  But that's another topic.
[21:18] <jtv> benji: still with me?
[21:18] <benji> jtv: I have a glimmer of understanding of the words you are saying.  Do you know of a place in the code which we already "full set of sharing POFiles"?
[21:18] <jtv> You're hitting a sore spot there.
[21:18] <jtv> No, we don't have that.
[21:18] <jtv> What we have is code to look up a full set of sharing templates.
[21:19] <jtv> So you'd have to go over the full set of sharing templates (POTemplateSharingSubset IIRC), and for each, look up their POFile for the language you're interested in.
[21:20] <jtv> Also, the template import code needs to do this for all languages that any of the sharing templates are translated to.  Which is why I would have preferred for POFileStatsJob to refer to a POTemplate and an optional language, rather than a POFile.
[21:20] <jtv> A POFile is basically a tuple of a POTemplate and a language.  But who's to say there's always a POFile?
[21:23]  * benji considers buying a very large whiteboard.
[21:27] <benji> jtv: so... it looks like I need to make the job use POTemplateSharingSubset.getSharingPOTemplates(POFile_this_job_is_about.template) to get a set of templates and then call updateStatistics on each of those templates
[21:27]  * benji crosses his fingers.
[21:28] <jtv> benji: you'll be happy to hear that that is almost entirely correct.  The only small missing detail is in what you call updateStatistics on:
[21:28]  * deryck hates going to the dentist
[21:28] <jtv> for each of those sharing templates you need to find the POFile (if any) that translates it to POFile_this_job_is_about.language.  And if there is one, call updateStatistics on that POFile.
[21:28] <benji> oh! yeah; I need to go from the templates to... /some/ set of POFiles, right?
[21:29] <jtv> deryck: speak up!  Can't hear what you're saying with that novocaine jaw.
[21:29] <jtv> benji: yes, and tragically there's no direct support for that.  Not that it'll be _very_ hard, but still.
[21:32] <benji> jtv: thanks much
[21:32] <jtv> HTH
[21:34] <gary_poster> thank you jtv and benji.  jtv, sorry to drag you into this...early in the morning?  late at night?...but much appreciated.
[21:35] <jtv> gary_poster: pretty much exactly inbetween.  Just got off an 8-hour bus ride, hence the weird times.
[21:35] <gary_poster> oof, jtv.  ok, well...rest well? :-)
[21:35] <jtv> Thanks
[21:36] <jtv> Don't feel guilty; I was awake anyway and chose to log in.
[21:36] <gary_poster> :-) thanks
[21:41] <deryck> abentley, r=me on that mechanical name change.
[21:42] <abentley> deryck: thanks.
[22:07] <sinzui> jcsackett, http://curtis.hovey.name/2011/09/12/misadventures-with-gnome-javascript/
[22:10] <jtv> hi sinzui — is there any prospect of getting deployment unblocked?  I see there's no rollback for that bad revision yet.
[22:11] <cjwatson> jtv: There is, it just didn't have the rollback tag
[22:11] <jtv> Odd actually: the deployment report says 14490 is both deployable and bad.
[22:11] <cjwatson> jtv: r14500
[22:11] <jtv> Thanks.
[22:11] <jtv> That's right after mine, actually.
[22:12] <cjwatson> But I guess we need r14491 QAed first ...
[22:12] <jtv> Yes.  Been up there for a while.
[22:12] <jtv> jelmerrrrr!
[22:14] <cjwatson> jtv: Oh, do we still have a tree from a little before r14516 on mawson somewhere?  My QA procedure for refactor-cron-germinate involves doing a timed publisher run with the old code
[22:15] <jtv> cjwatson: if only we had a technology to manage multiple revisions of source code somehow  :)
[22:15] <cjwatson> Hm, which might involve switching /srv/launchpad.net/codelines/current back for a while
[22:15] <cjwatson> I'm less than convinced that trying to run the publisher from any other path will work
[22:16] <jtv> The publisher is just a script — I would've thought you could run that from any tree.
[22:16] <cjwatson> e.g. LAUNCHPADROOT=${TEST_LAUNCHPADROOT:-/srv/launchpad.net/codelines/current}
[22:16] <cjwatson> in cron.germinate
[22:16] <cjwatson> so yes I can override it there ...
[22:16] <cjwatson> Oh, actually, that looks like the only place.
[22:17] <jtv> Once you get into publish-ftpmaster there shouldn't be any hard-coding of paths.  You may want to check the configs though.
[22:17] <cjwatson> Where should I look?
[22:17] <jtv> Mainly for the runparts directories I guess.
[22:17]  * jtv digs
[22:18] <jtv> cjwatson: my best guess so far is /srv/launchpad.net/codelines/lp-production-configs
[22:19] <cjwatson> ./dogfood-publish/launchpad-lazr.conf:run_parts_location: cronscripts/publishing/distro-parts
[22:22] <cjwatson> so I think that part is OK
[22:28] <jtv> cjwatson: my system suddenly shut down.  Last I see in my log is where you found the config for the run-parts stuff.  In practice though I don't think dogfood-publish is maintained; I always just run the publisher under the dogfood config.
[22:33] <cjwatson> jtv: Unfortunately dogfood doesn't have a run_parts_location, which is rather important here.
[22:34] <jtv> If none is set up, I think the script uses the one from the source tree it's running from.
[22:34] <jtv> But don't take my current word for it; I documented whatever it does.  :)
[22:35] <cjwatson> # Location where the run-parts directories for publish-ftpmaster
[22:35] <cjwatson> # customization are to be found.  Absolute path, or path relative to the
[22:35] <cjwatson> # Launchpad source tree, or "none" to skip execution of run-parts.
[22:35] <cjwatson> dogfood ultimately inherits "none"
[22:36] <cjwatson> dogfood-publish does seem to mostly inherit from dogfood, though
[22:37] <jtv> I think it's broken, but may be worth trying.
[22:37] <cjwatson> I should be able to run the publisher from r14515 without putting that tree's database in place, I guess
[22:37] <cjwatson> (I have a built tree in /srv/launchpad.net/codelines/r14515)
[22:38] <cjwatson> I think I might wait for garbo-hourly to finish before trying to time anything, though.
[22:38] <cjwatson> Hmm, that might take a while ...
[22:38] <lifeless> probably want to kill it, it will take the whole hour I expect
[22:39] <lifeless> it runs out of time on a 4-way box
[22:39] <lifeless> or is it 6. Much cpuness anyhow
[22:39] <cjwatson> Is that going to interfere with anyone's plans for dogfood?
[22:43] <cjwatson> I guess not.  Killing
[22:49] <cjwatson> 2011-12-14 22:44:26 DEBUG   Querying which suites are pending publication...
[22:50] <cjwatson> publisher on mawson has been sitting at that for five minutes - I know mawson is slow but is it that slow?
[22:50] <cjwatson> Maybe I should just run cron.germinate in isolation, at this rate
[22:50] <cjwatson> (That would be just as good for QA.)
[22:53] <cjwatson> I'll do that rather than growing old.
[23:05] <jtv> cjwatson: it's not supposed to be that slow, no.
[23:06] <cjwatson> cron.germinate itself doesn't need lp-query-distro.py pending_suites, only other lp-q-d operations that complete quickly, so I can avoid whatever the problem is.
[23:09] <cjwatson> Hmm.  This is a bit awkward.  I can't QA this on dogfood because it has suites that don't have seeds ...
[23:09] <jtv> Can't you limit it to specific suites?
[23:09] <cjwatson> No, that doesn't make sense.
[23:09] <cjwatson> What's going on ...
[23:10] <cjwatson> * Downloading http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.rusty/STRUCTURE
[23:10] <jtv> Bear in mind though that the dogfood archive isn't complete.
[23:11] <jtv> Anyway, the horizon is turning grey.  Time to get those few more hours.  Good luck!
[23:11] <cjwatson> find_operable_series is apparently producing different results from lp-query-distro.py development
[23:11] <cjwatson> Which is sad.  This might be qa-bad, but I'll look some more
[23:21] <cjwatson> Is there any problem with me using anoint-dogfood-admin on myself so that I can investigate this?  I think it might actually not be a production problem, but I need to change the status of a couple of dogfood Ubuntu series to make sure of that
[23:22] <cjwatson> (dogfood has multiple Ubuntu series in status DEVELOPMENT or FROZEN; production will only ever have one)
[23:32] <StevenK> cjwatson: It is not a problem, you can make yourself an admin.
[23:33] <cjwatson> Thanks
[23:53] <poolie> hi all