[00:34] <lifeless> I wonder
[00:34] <lifeless> are implicitly created accounts subject to the name blacklist ?
[00:42] <cjwatson> How long does qastaging take to update after a buildbot run finishes?
[00:42] <wgrant> 40ish minutes
[00:42] <wgrant> Let's see how it's going.
[00:43] <wgrant> Bah
[00:43] <wgrant> buildbot poller missed it.
[00:43] <wgrant> So it won't start for another 5 minutes.
[00:44] <wgrant> And it will take 30 minutes to update.
[00:44] <cjwatson> OK, I can probably get some QA done tonight then
[00:45] <wgrant> What do you have that's QAable on qastaging?
[00:45] <cjwatson> It's pretty much all dogfood, but it's easier to wait for qastaging so that the deployment report is up to date ...
[00:46] <wgrant> Heh
[00:46] <wgrant> That's what I thought.
[00:46] <lifeless> gmb: https://bugs.launchpad.net/launchpad/+bug/484712
[00:46] <_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers <bugwatch> <lp-bugs> <Launchpad itself:Triaged by gmb> < https://launchpad.net/bugs/484712 >
[00:46] <lifeless> gmb: would like feedback/status update (if only to unassign yourself and say that it hasn't been tested...)
[00:48] <cjwatson> wgrant: Speaking of which; can I commandeer mawson in a bit, after I'm done with a couple of chores?  You seem to be the only other person logged in.
[00:48] <wgrant> cjwatson: Sure, I'm just abusing its database.
[00:48] <wgrant> Nothing that should affect you.
[00:49] <cjwatson> That won't get clobbered by a code update?
[00:49] <wgrant> No.
[00:49] <cjwatson> Oh, of course, NDT means obviously not
[01:04] <wgrant> Query count test failures are a little painful now...
[01:04] <wgrant> They include full tracebacks :)
[01:25] <lifeless> heh, bad linkificaition on https://bugs.launchpad.net/launchpad/+bug/499438
[01:26] <_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
[01:27] <lifeless> cjwatson: what do you think the reaction would be to disabling anonymous ftp uploads ?
[01:29] <cjwatson> Hard to say
[01:30] <cjwatson> from a quick look at cocoplum:~lp_queue/ubuntu-queue/, it looks as though the bulk of our uploads are FTP right now
[01:30] <lifeless> yes, I would expect that
[01:30] <cjwatson> lp_archive@cocoplum:~$ grep --count upload-ftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
[01:30] <cjwatson> 68268
[01:30] <cjwatson> ^- unscientific check
[01:30] <cjwatson> lp_archive@cocoplum:~$ grep --count upload-sftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log
[01:30] <lifeless> the reason to suggest this is that a lot of the UI poorness around uploads is coupled to depending on good package metadata (including signatures) for error notifications
[01:30] <cjwatson> 4789
[01:31] <cjwatson> perhaps we should find out why most people aren't using sftp uploads first
[01:31] <lifeless> if we knew that 'user foo' did the upload, we could always notify use foo, regardless of the package metadata status
[01:31] <wgrant> SFTP provides no progress information.
[01:31] <wgrant> And client support in Ubuntu is recent.
[01:31] <cjwatson> our current dput.cf defaults to FTP
[01:31] <cjwatson> I don't think it's reasonable to disable it in LP until and unless that's changed, at the very least, including in stable releases
[01:31] <lifeless> I think we should simplify our upload processing code for SFTP
[01:32] <lifeless> and then get Ubuntu to change (or try changing) to SFTP
[01:32] <cjwatson> wgrant: in principle SFTP supports progress information
[01:32] <cjwatson> wgrant: what makes you say that?
[01:33] <wgrant> cjwatson: The current client does not.
[01:33] <cjwatson> YM dput?
[01:33] <wgrant> The vast majority of current uploads, both PPA and Ubuntu, are FTP
[01:33] <wgrant> Yes.
[01:34] <wgrant> I'm not sure the default dput.cf even has an SFTP PPA section.
[01:34] <wgrant> Because it requires configuration.
[01:34] <wgrant> (we rely on username matching, not just key)
[01:36] <cjwatson> oh, and Debian's dput doesn't have SFTP support yet
[01:36] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505173
[01:36] <lifeless> does that matter particularly?
[01:37] <cjwatson> it's another data point, and I'm sure it affects some percentage of users
[01:37] <wgrant> It would be pretty unpleasant to make it impossible to upload to PPAs except from Ubuntu.
[01:37] <wgrant> People do use Debian, you know :)
[01:38] <lifeless> wgrant: it wouldn't be impossible: lftp etc can do it, and folk can apply the patch
[01:38] <lifeless> https://bugs.launchpad.net/launchpad/+bug/499438 is what sparked these questions
[01:38] <_mup_> Bug #499438: Better handling of fatal upload errors <lp-soyuz> <soyuz-upload> <Launchpad itself:Triaged by julian-edwards> < https://launchpad.net/bugs/499438 >
[01:39] <lifeless> cjwatson: whats the right way forward to get Ubuntu to promote SFTP for uploads - I'm primarily concerned with new PPA users, the set of folk most likely to make packaging fubars anyhow
[01:39] <cjwatson> I doubt I'm capable of thinking of a problem that complex at 1:40
[01:39] <cjwatson> am
[01:39] <lifeless> fair enough
[01:40] <lifeless> I will probably raise it again
[01:40] <wgrant> lifeless: Initial config is the difficult bit.
[01:40] <cjwatson> right
[01:40] <wgrant> We can't provide a default config, so we have to tell people to edit their dput.cf
[01:40] <wgrant> Like we did 4 years ago :/
[01:40] <lifeless> or get credentials from lptools, which we use for a bunch of other things too
[01:40] <cjwatson> unless we're very careful, all we achieve is rearranging the deckchairs on the UI.
[01:41] <wgrant> lifeless: lptools?
[01:41] <cjwatson> lptools, which ~nobody has installed
[01:41] <StevenK> bzr launchpad-login ?
[01:41] <wgrant> Exactly.
[01:41] <wgrant> Nobody uses lptools.;
[01:41] <lifeless> cjwatson: thats true, OTOH deckchairs the user can see are easier to examine than ones they cannot :)
[01:41] <lifeless> didn't a bunch of ubuntu-dev-tools get shuffled over to lptools ?
[01:41] <lifeless> I was fairly sure they did, during the last cycle
[01:42] <cjwatson> ubuntu-dev-tools declares no package relationships on lptools
[01:42] <cjwatson> so if they did, it was shuffled out of sight
[01:42] <StevenK> lifeless: All I can see that is doing is having more people ask "Why can't I just upload using dput?"
[01:42] <lifeless> yeah, I can see
[01:42] <lifeless> could use ubuntu-dev-tools
[01:42] <wgrant> Other sites seem to rely on uniqueness of SSH keys.
[01:42] <lifeless> StevenK: a) experienced folk can, b) new folk follow docs on the wiki, and *then* also mess up
[01:43] <cjwatson> It's true that a few tools were moved, but they were the sorts of things only pretty LP-aware people used anyway
[01:43] <cjwatson> lp-get-branches, lp-grab-attachments, lp-project-upload, lp-list-bugs, lp-set-dup, lp-shell
[01:43] <lifeless> you didn't want to reason about this at 1:40am
[01:43] <lifeless> so don't :)
[01:43] <cjwatson> you asked me to come up with a solution :)
[01:43] <cjwatson> picking holes is easier ;)
[01:44] <lifeless> heh
[01:44] <wgrant> cjwatson: qastaging update finished 4 minutes ago, btw.
[01:44] <cjwatson> thanks.  upgrading mawson
[01:44] <lifeless> so, as long as we never need to go spelunking on germanium again to determine what went wrong, I will accept nearly any hole you care to poke
[01:44] <lifeless> I think pushing it back onto the users machine where they can locally diagnose and get up-front errors is a good thing
[01:45] <cjwatson> I wonder if there's any way to push errors over the FTP session
[01:45] <wgrant> There is.
[01:45] <wgrant> We do it already.
[01:45] <StevenK> Which we don't do for SFTP
[01:45] <wgrant> But lifeless knows that well, so I assume he a reason to ignore it.
[01:45] <wgrant> +has
[01:45] <lifeless> it has limits, and we will happily email the wrong person if the package is a plain copy from e.g. Debian
[01:46] <lifeless> one of the limits is that core twisted tries very hard to turn such events into OOPSes
[01:46] <lifeless> (oh no something went wrong, must alert the admin)
[01:46] <lifeless> thats probably fixable, but even then we still can't notify *anyone else* that the problem occured.
[01:47] <lifeless> e.g. via upload subscriptions
[01:47] <cjwatson> I agree in principle that SFTP is a good thing to use; the road to making it mandatory probably isn't short though.
[01:47] <cjwatson> I guess that's all I'm really saying
[01:47] <lifeless> making it the default for new users would go a long way
[01:47] <cjwatson> Yes
[01:47] <lifeless> we could just say 'try over sftp' to any experienced user with an undiagnosable problem
[01:47] <lifeless> e.g. deprecate but not disable ftp
[01:48] <cjwatson> Or if we can't figure out the user's LP login, fall back to FTP
[01:48] <wgrant> The experienced users aren't going to have trouble :)
[01:48] <cjwatson> You'd still win if we reduced the incidence of spelunking significantly
[01:48] <cjwatson> Just not as much
[01:48] <lifeless> mmm, I'd like something more aggressive than 'if we can't figure it out'
[01:48] <lifeless> e.g. opt-in to ftp
[01:48] <cjwatson> "What's your LP login?  Type 'lifeless' to use FTP"
[01:49] <lifeless> (remember too that we have folk dealing with private packages etc, so the default really wants to be non plaintext
[01:49] <lifeless> cjwatson: :)
[01:49] <lifeless> cjwatson: put that in for april 1st please
[01:49] <cjwatson> I have a better April 1st way ahead of that, which I've been failing to implement for five years :)
[01:50] <cjwatson> Actually, seriously, interactivity wouldn't be awful
[01:50] <lifeless> poor andi
[01:50] <lifeless> still confused by LP's UI.
[01:50] <wgrant> Again?
[01:50] <cjwatson> just have /usr/share/dput/sftp.py ask you and save the answer somewhere
[01:50] <lifeless> 3 imports one project
[01:50] <lifeless> cjwatson: +1
[01:50] <cjwatson> enhancement: figure it out automatically without asking.  but that's nice-to-have.
[01:51] <cjwatson> (I'm assuming sftp.py gets a terminal.)
[01:51] <cjwatson> And then have sftp.py fall back internally to FTP on abject failure.
[01:51] <cjwatson> (With loud warnings.)
[01:51] <StevenK> mwhudson was talking about anonymous-ssh, so we could utilise that too ...
[01:51] <lifeless> StevenK: not useful here
[01:51] <cjwatson> Let me not attempt to figure out the confidentiality properties of anonymous SSH
[01:52] <lifeless> StevenK: the point is knowing the user so we can notify sensibly
[01:52] <StevenK> cjwatson: Or fall back to trying $USER ?
[01:52] <lifeless> StevenK: fixes a raft of corner cases that we have today, anonymous-ssh wouldn't do that
[01:52] <cjwatson> StevenK: *handwave* that kind of thing
[01:52] <cjwatson> I wonder what the performance difference is for large uploads over SFTP vs. FTP
[01:53] <StevenK> lifeless: SFTP for uploads still doesn't solve notifications for syncs ...
[01:53] <lifeless> cjwatson: SFTP should be faster (tcp window already open)
[01:53] <cjwatson> Syncs will all be API soon enough, so you'll at least have a username
[01:53] <cjwatson> lifeless: haha my bugmail disagreed last I checked
[01:53] <lifeless> indeed, and *I'm not talking about syncs* :P
[01:54] <lifeless> failing to fix problem B doesn't make a solution to problem A better or worse
[01:54] <lifeless> having a single solution to A and B is nice, of course.
[01:54] <cjwatson> (the HPN people talk about FTP as a comparator for their none-cipher work)
[01:55] <lifeless> but you need to demonstrate a link between them for it to be worth considering - whats the link between syncs, where we know all the package data is intact, and uploads, where its all arbitrary
[01:55] <cjwatson> comparand.  blah.  I keep getting that wrong.
[01:55] <lifeless> cjwatson: interesting
[01:55] <cjwatson> Ur, help.  What does http://paste.ubuntu.com/792323/ mean when upgrading dogfood?
[01:55] <lifeless> you keep both pieces?
[01:56] <lifeless> the dogfood config has old and deleted config keys
[01:56] <StevenK> Haha
[01:56] <wgrant> Ah, yes, let me fix that.
[01:56] <StevenK> Yeah, wgrant broke it
[01:57] <wgrant> I don't think it's the DF config that's broken. It's just that the prod configs are out of date.
[01:58] <wgrant> cjwatson: Should be fixed.
[02:01] <cjwatson> wgrant: Thanks; should I carry on with the build or did you do that?
[02:02] <wgrant> cjwatson: I didn't touch it.
[02:02] <wgrant> Come on, do you think it can build that quickly? :)
[02:02] <cjwatson> Heh
[02:04] <mwhudson> inferring username from ssh key is technically easy i guess
[02:04] <mwhudson> and that UNIQUE constraint on sshkey would have been interesting a few years back :-)
[02:04] <wgrant> Now that there's more than just a few keys, yeah...
[02:05] <cjwatson> I thought that's why we added the UNIQUE constraint
[02:05] <wgrant> There isn't one, AFAIK.
[02:05] <wgrant> Indeed not.
[02:06] <cjwatson> Adding one might not be a terrible idea.
[02:07] <wgrant> There is one key with 19 links, another with 20...
[02:07] <wgrant> 650ish with 2 links, 40 with more than 2
[02:10] <cjwatson> :-(
[02:10] <cjwatson> That doesn't block lifeless' project though; we have the username to work with, not just the key
[02:10] <wgrant> Yeah
[02:13] <micahg> lifeless: also, about owners and notifications, some people want to be owners to just administer and not have rights
[02:14] <lifeless> micahg: yes, thats why we have separate roles, though wgrant is campaiging that this doesn't make sense
[02:14] <wgrant> lifeless: No.
[02:15] <wgrant> lifeless: I'm campaigning that the owner special case doesn't make sense.
[02:15] <wgrant> I am campaigning that admin+membership should be separated.
[02:15] <wgrant> Currently you have a list of members, and a list of admins who are members, and a single not-quite-admin-but-not-member.
[02:16] <wgrant> When a list of members and a list of admins who may also be members would work fine.
[02:16] <lifeless> with the recent change to admins promoting admins, hmm
[02:16] <lifeless> perhaps
[02:18] <micahg> that would solve the DMB use case as well
[02:18] <wgrant> Yup.
[02:20] <wgrant> Morning jtv.
[02:20] <jtv> hi there wgrant, happy 2012
[02:21] <wgrant> Likewise.
[02:21] <jtv> thank you
[02:27] <wgrant> lifeless: So, how do you propose to find transitive dependencies without a resolver? :)
[02:29] <lifeless> wgrant: I thought you meant something different apparently
[02:36] <lifeless> jtv:  https://bugs.launchpad.net/launchpad/+bug/506497 - is that more done now?
[02:36] <_mup_> Bug #506497: import-queue-gardener gives file path a higher priority than a manually assigned template <import-queue> <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506497 >
[02:36] <lifeless> jtv: also would like your input on https://bugs.launchpad.net/launchpad/+bug/506516
[02:36] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
[02:37] <jtv> lifeless: probably not done, but I'm not even sure those tools still work.
[02:37] <lifeless> jtv: should I invalid it? or incomplete?
[02:39] <jtv> lifeless: incomplete.
[02:41] <micahg> lifeless: what would you think of marking bug 529957 invalid since we build translation packages out of the Firefox/Thunderbird sources now?
[02:41] <_mup_> Bug #529957: XPIPO file uploads should be disabled <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/529957 >
[02:42] <lifeless> micahg: have we ditched the XPIPO support?
[02:42] <lifeless> micahg: should we drop it?
[02:43] <lifeless> micahg: (also does that mean thunderbird is not translatable in Ubuntu using LP?)
[02:43] <micahg> lifeless: I should check with chrisccoulson first, but I think so, at least once the Firefox migration in lucid/maverick is complete which should be some time this month
[02:43] <micahg> lifeless: thunderbird actually never was IIRC
[02:43] <lifeless> so I don't think we should invalidate the bug while we have the code it talks about around
[02:43] <lifeless> but we could change it to be 'this code can be deleted'
[02:45] <micahg> well, I guess one day if we ever get a way to push translations back upstream, we could import from the source uploads and push changes upstream, but I guess in that scenario, we don't need the xpipo code either
[02:54]  * StevenK stabs the screwed up security model SPRBs use.
[03:06] <lifeless> jtv: so, thoughts on bug https://bugs.launchpad.net/launchpad/+bug/509109 and https://bugs.launchpad.net/launchpad/+bug/506516 ?
[03:06] <_mup_> Bug #509109: Deadlock in message-sharing-merge while migrating brasero <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/509109 >
[03:06] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing <lp-translations> <message-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/506516 >
[03:07] <jtv> “If they're really a problem, they'll come back.”
[03:07] <lifeless> jtv: they were both migration stuff; thats done, right ?
[03:08] <jtv> Yes, though the code may still be in use.
[03:08] <lifeless> ah
[03:08] <lifeless> the question is, should the maintenance squad sit down and work on them ?
[03:10] <jtv> Not based on these reports, no.  I'd just close them.
[03:11] <jtv> Too much has changed since those bugs were reported.  If they're really a problem, they'll come back.
[03:12] <lifeless> thanks, done.
[03:13] <lifeless> hmm, something is seriously odd with multi-project -importance bug sort order
[03:18]  * StevenK stabs diff generation and/or longpoll
[03:20] <lifeless> I wonder that noone has hacked https://bugs.launchpad.net/launchpad-buildd/+bug/516208 into the thing already
[03:20] <_mup_> Bug #516208: disable Automake's silent rules <feature> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/516208 >
[03:26] <cjwatson> Right, mawson is all ... whoever-cares' again.
[03:27] <StevenK> cjwatson: Did you QA mvo's rev, or is that his to do?
[03:28] <StevenK> Launchpad encountered an error during the following operation: generating the diff for a merge proposal.  The source branch has no revisions.
[03:28] <StevenK> Blink
[03:28] <cjwatson> StevenK: I did his
[03:28] <cjwatson> So it's just jelmer's recipe format thing left
[03:28] <StevenK> Indeed. Thanks.
[03:47] <StevenK> jtv: O hai. I'd like a review, but the branch scanner has de-pramed its toys while scanning my branch. The diff is at http://pastebin.ubuntu.com/792375/
[03:47] <jtv> StevenK: working on a long one right now, but you'll be next.
[03:47] <wgrant> StevenK: Make it rescan?
[03:48] <StevenK> wgrant: By pushing agai
[03:48] <StevenK> n?
[03:48] <wgrant> Yes.
[03:48] <wgrant> You may have to push -r-2 then push again, I forget.
[03:48] <StevenK> I thought we worked out that -r-2 doesn't work?
[03:48] <wgrant> It can't not.
[03:49] <StevenK> % bzr push -r-2
[03:49] <StevenK> Using saved push location: lp:~stevenk/launchpad/hide-forbidden-sprbs
[03:49] <StevenK> No new revisions to push.
[03:49] <wgrant> --overwrite
[03:49] <StevenK> And then bzr push quickly?
[03:50] <wgrant> No need to be quick.
[03:50] <wgrant> But if you want.
[03:51] <StevenK> The branch scanner should log branch.unique_name
[03:51] <wgrant> Yes.
[03:55] <StevenK> Bleh, job logging is complete crap
[03:55] <StevenK> You can't get at the logger in the actual job's run() method.
[03:58] <StevenK> wgrant: Looks like the scanner choked on it again
[03:58] <wgrant> Yay
[04:00] <lifeless> StevenK: its not on an attribute? Also why would you need to, thats not the logging API
[04:03] <StevenK> -        return '%s (ID %d)' % (class_name, ijob_id)
[04:03] <StevenK> +        return '%s (ID %d) %s' % (class_name, ijob_id, repr(job))
[04:03] <StevenK> I think that will help
[04:08] <lifeless> StevenK: wgrant: is  https://bugs.launchpad.net/launchpad/+bug/525749 part of disclosure, do you think ?
[04:08] <_mup_> Bug #525749: A Branch's visibility setting page contain the word 'visibility' <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/525749 >
[04:10] <wgrant> lifeless: Probably, yes.
[04:10] <wgrant> Although the summary seems to be inverted.
[04:10] <lifeless> indeed
[04:12] <lifeless> will you fix?
[04:13] <lifeless> wgrant: is https://bugs.launchpad.net/launchpad/+bug/527550 still ?
[04:13] <_mup_> Bug #527550: CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527550 >
[04:13] <wgrant> That hasn't been touched recently.
[04:13] <wgrant> So yes.
[04:14] <StevenK> lifeless: So to answer your question, it is not on a attribute. And it would be very useful for say, IDSJ.
[04:26] <lifeless> StevenK: but why? logger = logging.getLogger('lp.jobs.foo')
[04:26] <lifeless> done
[04:26] <lifeless> wgrant: and  https://bugs.launchpad.net/launchpad/+bug/527551?
[04:26] <_mup_> Bug #527551: Intra-archive copying of a source with a failed build may leave that source uncopyable <lp-soyuz> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/527551 >
[04:29] <wgrant> lifeless: Still there.
[04:30] <lifeless> wgrant: and https://bugs.launchpad.net/launchpad/+bug/528459 ?
[04:30] <_mup_> Bug #528459: PPA does not delete old packages after new build <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/528459 >
[04:30] <wgrant> lifeless: Likewise.
[04:30] <wgrant> NBS
[04:30] <StevenK> lifeless: Because I prefer it was in the same log as the job runner uses
[04:31] <lifeless> StevenK: and? thats orthogonal
[04:31] <lifeless> StevenK: logger objects are not intended to be passed around willynilly
[04:45] <lifeless> StevenK: fixtures.FakeLogger may help you
[04:46] <StevenK> jtv: Still dealing with the large review?
[04:46] <jtv> Yes
[04:46] <jtv> But the first container of coffee has arrived, which should speed things up.
[04:47] <jtv> We're slightly hung over (in the non-imbibed sense) from an all-night drive during the holidays.
[04:47] <jtv> (“The holidays” for us being January 2 & 3)
[04:51] <micahg> the lpia PPA queue does not seem to be dispatching to the buildd
[04:53] <wgrant> webops: please stab gold and restart buildd-manager
[04:53]  * wgrant throws some builders at lpia.
[04:53] <spm> this is terrible. I can nearly do this from memory.
[04:54] <micahg> wgrant: I would just give it one, no one should be using lpia anyways
[04:56] <lifeless> wgrant: so this bug - https://bugs.launchpad.net/launchpad-buildd/+bug/533583
[04:56] <_mup_> Bug #533583: build fails where no error is present <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/533583 >
[04:57] <lifeless> what is the defect/problem ?
[04:57] <wgrant> micahg: Since there seem to be about 30 Mozilla builds on the virt builders at the moment, sounds like a good plan.
[04:58] <micahg> it's that time of day :)
[04:58] <wgrant> lifeless: sistpoty disagrees with Ubuntu policy.
[04:58] <wgrant> Needs to be argued with lamont.
[04:59] <micahg> ISTR another bug to make that not fatal
[05:00]  * micahg thinks it's a lack of scrolling to the bottom :)
[05:04]  * lifeless tosses oil on the fire
[05:05] <micahg> lifeless: you didn't have to toss wgrant in as well :)
[05:05] <lifeless> he is the oil ?
[05:06] <micahg> nah, I think he was holding it :)
[05:16] <lifeless> didn't poolie do this? https://bugs.launchpad.net/launchpad/+bug/547036
[05:16] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
[05:17] <StevenK> jtv: Just how big is this branch? :-P
[05:17] <spm> wgrant: btw, that ppa et al reset is done and done
[05:17] <wgrant> spm: Thanks.
[05:51] <StevenK> wgrant: Since jtv appears to be AWOL, would you mind reviewing the diff at http://pastebin.ubuntu.com/792375/
[05:53] <lifeless> wgrant: StevenK: opinions on  bug 547036 ?
[05:53] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree <canonical-losa-lp> <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/547036 >
[05:54] <wgrant> lifeless: poolie fixed it months ago?
[05:54] <wgrant> StevenK: He might be back now :)
[05:54] <lifeless> wgrant: thats what I thought, was seeking confirmation
[05:57] <lifeless> StevenK: see bug https://bugs.launchpad.net/launchpad/+bug/551414
[05:57] <_mup_> Bug #551414: log messages in jobs are discarded <jobs> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/551414 >
[06:00] <StevenK> jtv1: Still fighting with the large branch? How large is it?
[06:00] <jtv1> StevenK: it's not the branch, it's the interruptions
[06:02] <lifeless> boo!
[06:12]  * StevenK nails wgrant to IRC.
[06:14]  * wgrant kicks Optus in the face :)
[06:15] <nigelb> I love that those of us in the 3rd world have better internets.
[06:15]  * nigelb waves to jtv1 
[06:15] <jtv1> Hi nigelb
[06:15] <jtv1> Happy new year etc!  No time to chat further right now, sorry :)
[06:15] <nigelb> heh
[06:22] <StevenK> nigelb: What do you call an Indian cricketer with a century next to their name?
[06:23] <StevenK> nigelb: A bowler.
[06:24] <lifeless> jtv1: what is 'pottery' ?
[06:25] <wgrant> We do not speak its name.
[06:25] <jtv1> lifeless: it's the code for generating POTemplates from branches.  Runs in the build farm.
[06:25] <lifeless> thanks
[06:25] <jtv1> wgrant: yes we do.  I just did.  Robert just did.
[06:28] <wgrant> Bah
[06:33] <lifeless> LaunchpadTimeoutError: Statement: 'UPDATE Project SET max_bug_heat=(SELECT COALESCE(MAX(heat), 0) FROM
[06:33] <wgrant> Yes :)
[06:33] <lifeless> staaaaaaaaab
[06:33] <wgrant> I've been saying that for well over 18 months now.
[06:48] <lifeless> is there a better way?
[06:48] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805https://bugs.launchpad.net/launchpad/+bug/582805
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[06:48] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[07:05] <lifeless> 1123 high bugs, and counting
[07:08] <wgrant> 330 critical bugs
[07:09] <wgrant> what's your point?
[07:09] <micahg> lifeless: are you counting up or down?
[07:09] <wgrant> 330 critical bugs and 4 people, even.
[07:10] <lifeless> micahg: our bug handling policy says we have three groups of bugs
[07:10] <lifeless> the great unwashed
[07:10] <lifeless> 6 months of todo (high)
[07:10] <lifeless> as much zomg as there is (critical)
[07:10] <micahg> lifeless: I'm familiar :), just wondering which way you're counting on the 6 month pot :)
[07:11] <wgrant> lifeless: Huh
[07:11] <wgrant> How is high 6 months?
[07:11] <wgrant> Given that we have 4 people...
[07:11] <wgrant> That's like 10 bugs.
[07:11] <lifeless> micahg: and that every quarter we'll review the high to keep it trim; its a year overdue. The first one is a doozy
[07:11] <lifeless> wgrant: yes, I'll be doing a couple of passes I suspect
[07:11] <micahg> lifeless: ISTR you doing this recently
[07:11] <lifeless> micahg: that was eliminating mediums
[07:11] <micahg> ah
[07:11] <lifeless> micahg: which were stuck in limbo, some were crits, some high, many/most low
[07:12] <micahg> wgrant: only 4 people on highs now?
[07:13] <stub> For the next few months at least.
[07:20] <wgrant> Evening stub.
[07:20] <wgrant> stub: personless accounts: why do we still have them?
[07:20] <stub> morning
[07:21] <stub> Possibly placeholder people generated when we import stuff like translations etc.
[07:21] <stub> Not sure what does an ensurePerson or whatever the call is any more.
[07:21] <wgrant> personless accounts, not accountless persons.
[07:22] <stub> Yer... backwards.
[07:22] <wgrant> We have 3 million personless accounts.
[07:22] <wgrant> From SSO
[07:22] <stub> Didn't I clean them out already?
[07:22] <wgrant> No.
[07:22] <wgrant> We cleaned out the people from shipit.
[07:22] <wgrant> But not the accounts from SSO, or the accounts that were left over from deleted ShipIt people.
[07:23] <stub> k. more cleanup needed then. They just waste space I think.
[07:23]  * stub looks for other Account references
[07:23] <wgrant> openididentifier, emailaddress and person should be all
[07:24] <wgrant> I have a branch to delete EmailAddress.account, which depends on all those emailaddresses and accounts being gone :)
[07:24] <stub> Ok.
[07:24] <stub> So we need to trash emailaddresses and openididentifiers not linked to a person and accounts not linked to a person.
[07:25] <wgrant> Yep.
[07:25] <wgrant> Ah, accountpassword too
[07:25] <wgrant> Not that it's used any more except by tests.
[07:28] <jtv> StevenK: gasp!  Finally getting to yours now.
[07:30] <jtv> StevenK: I don't suppose check_permission might do any de-pramming of its own when presented with a None?
[07:31] <StevenK> jtv: Oh, in initial_values?
[07:31] <jtv> I think so — name not included in diff context.
[07:31] <jtv> Line 32 of your diff.
[07:32] <jtv> (By the way, updating copyrights is easy: just run utilities/update-copyright just like you do utilities/format-new-and-modified-imports.
[07:33] <StevenK> Which is what I did
[07:33] <StevenK> :-)
[07:33] <wgrant> Also, if people don't run format-new-and-modified-imports in all their branches now I will be very upset :)
[07:33] <wgrant> Since they're all in good order now.
[07:33] <jtv> So will I, but there is one problem: lp.codehosting.
[07:33] <wgrant> I fixed most of those.
[07:33] <wgrant> There's only like 3 places that need it.
[07:33] <jtv> I thank you.
[07:33] <wgrant> and they all have FIRST comments now
[07:34] <wgrant> Which format-imports handles nicely.
[07:34] <wgrant> I also made it handle _pythonpath properly.
[07:34] <jtv> Oh, there's a convention for that?  Great.
[07:34] <wgrant> And then ran it over the whole tree.
[07:34] <jtv> All wonderful.  I suppose _pythonpath still elicit lint warnings?
[07:34] <wgrant> An import preceded by a comment starting "# FIRST" will be put after the stdlib imports, but before the third-party ones.
[07:34] <wgrant> Yes.
[07:34] <wgrant> Not sure how to suppress those globally.
[07:35] <jtv> This will also make my megalint branches a bit less mega.  :)
[07:35] <wgrant> This one touched about 1200 files.
[07:36] <StevenK> jtv: Does http://pastebin.ubuntu.com/792471/ make you less nervous?
[07:36] <jtv> StevenK: wasn't saying nervous.  You should see the review I just finished.
[07:36] <StevenK> jtv: That should make certain check_permission() doesn't get a None.
[07:37] <jtv> It does make me feel slightly safer, as well as appreciated.  :)  Thanks.
[07:37] <StevenK> I'm actually more comfortable with how I've written it now.
[07:39] <jtv> That's good too.
[07:39] <jtv> You've got my vote, with one additional note.
[07:40] <StevenK> jtv: If we say something other than "This recipe has not been built yet" we may leak the existance of the private PPA
[07:41] <StevenK> Pretending the build doesn't exist if they can't see it is safest.
[07:41] <jtv> And the recipe needs to remain visible?
[07:42] <jtv> What about "this recipe has not been built yet (or if it has, you are not permitted to see the builds)"?
[07:42] <StevenK> We do not support private recipes or recipes making use of private branches.
[07:42] <wgrant> We'd have to add that disclaimer to practically every list in Launchpad.
[07:43] <jtv> I see.  Nasty problem.
[07:43] <lifeless> yes the recipe has to stay visible
[07:43] <jtv> Then again, I suppose it's a bit of a tree falling with no-one to hear.
[07:43] <lifeless> because it may be owned by e.g. you
[07:44] <StevenK> jtv: It's a rabbit hole. wgrant, sinzui, wallyworld, jcsakett and I have been arguing about problems like that for months.
[07:44] <StevenK> lifeless: At the moment, it doesn't. :-)
[07:45] <StevenK> But sinzui agreed it's a disclosure bug.
[07:45] <jtv> I suppose the only relevant information to an unprivileged user would be "yes, this recipe can build" and they'll find out eventually if that's not the case.
[07:46]  * StevenK checks the scanner choked on the branch again.
[07:49] <StevenK> Pity. It does.
[07:49] <lifeless> StevenK: doesn't your branch make the recipe stay visible ?
[07:50] <StevenK> lifeless: Yes. I was making a joke that it doesn't on production.
[07:50] <lifeless> ah, heh
[08:00] <stub> How much work did you guys land over the break? New Year branch pulling just keeps going and going...
[08:02] <StevenK> stub: wgrant and sinzui's fault. They effectively emptied lib/canonical
[08:04] <wgrant> stub: We moved a couple of hundred thousands lines of lib/canonical remnants, and properly formatted the imports in every file.
[08:04] <stub> I wonder if you could compile a diff to a regexp search and replace?
[08:04] <wgrant> Heh
[08:05] <lifeless> yes, you can
[08:05] <wgrant> stub: Also, I reverted the EmailAddress.{person,account} consistency patch, as it was going to take 3-4 minutes to apply.
[08:05] <lifeless> wgrant: do you think https://bugs.launchpad.net/launchpad/+bug/566339 is fixed, or not ?
[08:05] <_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
[08:06] <stub> wgrant: Really? What was it doing besides adding the triggers?
[08:06] <wgrant> stub: Not triggers, but check constraints.
[08:06] <stub> oh... ic. hmm...
[08:06] <wgrant> Apart from the questionable sensibility of having cross-table functions in check constraints, before pg 9.1 they can't be added without a full scan.
[08:07] <wgrant> So, instead of turning them into triggers I decided to fix the inconsistencies by dropping EmailAddress.account instead.
[08:07] <stub> Yes, that would have been my preferred approach but gmb thought this was a quicker fix and wanted the quicker fix.
[08:08] <StevenK> wgrant: You managed to drop it?
[08:08] <wgrant> The actual code changes were reasonably shallow. But the tests, oh god the tests.
[08:08] <wgrant> All fixed now, anyway.
[08:08] <stub> Main goal being to locate the code generating the inconsistent data.
[08:08] <wgrant> In a final ec2 run before being split into 4.
[08:08] <StevenK> wgrant: Four now?
[08:08] <wgrant> StevenK: Yes.
[08:08] <wgrant> Mailing list refactorings are being split up separately.
[08:08] <StevenK> Ah
[08:09] <wgrant> Because the queries and tests were awful.
[08:09] <StevenK> s/were/are/ ?
[08:09] <wgrant> stub: I never tracked down exactly what it was, but I believe it's in the code around reconciling openididentifiers, persons and accounts on login when there are conflicts and the account needs reactivating.
[08:10] <wgrant> But account has basically had all its functionality ripped out in this branch, so it doesn't matter.
[08:10] <stub> Need to convince bzr that removing a directory containing nothing but garbage is fine
[08:10] <wgrant> stub: bzr clean-tree
[08:10] <wgrant> Will ask you if you want to remove unknown files/directories
[08:10] <wgrant> It's how I get around these conflicts, and tends to work pretty well.
[08:11] <stub> yer. I know why the guard is there, but so far it has only been false positives.
[08:11] <wgrant> Yeah
[08:11] <wgrant> pyc ftl.
[08:12] <stub> bzr knows about files to ignore, we could teach it about garbage in a similar fashion.
[08:12] <stub> I guess it doesn't matter that much
[08:12] <lifeless> bzr resolve --take-other should clean them up
[08:14] <stub> Just complaining that it is my responsibility to fix things up that aren't really broken, but bzr isn't intelligent enough to know if this case is potential data loss or noise.
[08:14] <StevenK> wgrant: r14625 is ready for you to QA.
[08:14] <lifeless> wgrant: so, can has answer to last two q's?
[08:14] <StevenK> jelmer: Can haz QA for r14620?
[08:15] <wgrant> lifeless: What was the one that wasn't bug #566339?
[08:15] <_mup_> Bug #566339: Cannot accept package which would notify private email addresses <boobytrap> <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/566339 >
[08:15] <lifeless> https://bugs.launchpad.net/launchpad/+bug/582805
[08:15] <wgrant> I don't believe that one is fixed.
[08:15] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well <lp-translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/582805 >
[08:15] <wgrant> StevenK refactored that code, but didn't change it much.
[08:16] <StevenK> Let's just delete it instead.
[08:16] <wgrant> lifeless: Commented and closed.
[08:19] <lifeless> thanks
[08:20] <wgrant> stub: So, do you want me to write the SQL to clean up the accounts, or can you do it?
[08:20] <stub> wgrant: It needs to be a garbo job, and I was going to do it when my branches have synced.
[08:20] <stub> Unless you want to... just a couple of BulkPruner tasks I think.
[08:20] <wgrant> Mm, I think the references are few enough that you could do it without garbo.
[08:20] <wgrant> But I guess it's the same as PersonPruner, really.
[08:22] <stub> We don't want to block creating new accounts while the SQL runs...
[08:23] <lifeless> pruners are easy
[08:24] <stub> bah... launchpaddatabaseupdatelog.end_time isn't being populated :-P
[08:24] <wgrant> stub: It's also crashing with dupe ids.
[08:24] <wgrant> On staging restores.
[08:25] <wgrant> Which is a little bit odd.
[08:26] <adeuring> good morning
[08:28] <stub> wgrant: Because it gets populated when we build the database schema, then we attempt to repopulate it by restoring the similar data from production.
[08:28] <wgrant> Ah!
[08:28] <stub> hmmm...
[08:28] <stub> ?
[08:29] <stub> oh... full updates should work, but code updates can fail like that.
[08:29] <stub> no..
[08:29] <stub> hmm...
[08:29] <stub> need to look over the scripts.
[08:29] <wgrant> Code updates work, AFAICS.
[08:29] <wgrant> Hm
[08:29] <wgrant> Although they've been failing early.
[08:29] <wgrant> Because of the bad patch.
[08:29] <wgrant> So maybe not.
[08:31] <lifeless> stub: remember we're dropping the updatelog
[08:31] <lifeless> stub: (and trusted.sql etc) - moving to just patch applications
[08:32] <stub> oh right, so I'll ignore the missing field for now and maybe trash it if it is the best way to fix staging.
[08:32] <wgrant> stub: Hopefully _new is salvagable.
[08:32] <wgrant> But I'm not sure.
[09:04] <stub> wgrant: Any particular reason you decided to drop EmailAddress.account rather than Person.account? You can argue either way.
[09:05] <danhg> morning
[09:05] <wgrant> stub: EmailAddress.{account,person} could still be inconsistent, as there can be multiple email addresses.
[09:05] <stub> I guess we might end up with Person records with no emailaddresses once we start adding other contact mechanisms
[09:05] <stub> Good point.
[09:06] <wgrant> And Account is hopefully not long for this world.
[09:10] <lifeless> wheee
[09:10] <lifeless> https://bugs.launchpad.net/launchpad/+bug/599377
[09:10] <_mup_> Bug #599377: FilebugShowSimilarBugsView.show_duplicate_list treats contextUsesMalone as a property but it's a method <dhrb> <dupefinder> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/599377 >
[09:10] <stub> AssertionError: Can't create a Person for an account which has no email.
[09:12] <wgrant> stub: Where'd you run into that?
[09:12] <wgrant> Tests?
[09:12] <wgrant> I assume that's from Account.createPerson?
[09:13] <stub> wgrant: Yup. test_garbo
[09:13] <stub> Think it is on trunk
[09:13] <stub> test_RevisionAuthorEmailLinker is one of two
[09:13] <wgrant> What have you changed to trigger that?
[09:15] <stub> Two new daily jobs. Hmm... might be my change actually. A lot of the tests just run 'all daily jobs', and I might be destroying the data in a way the test does not expect.
[09:15] <wgrant> Heh, yes.
[09:15] <wgrant> That sounds likely.
[09:15] <stub> ok... leave this until after lunch then before wife gets antsy
[09:16] <wgrant> IIRC test_RevisionAuthorEmailLinker relies on an unlinked Account surviving a garbo run.
[09:16] <wgrant> For one of its cases.
[09:16] <wgrant> But that can probably go, since it's no longer a valid data state.
[10:41] <stub> Has lp hung or my censorwall screwing up?
[10:41] <stub> oh... there it is
[10:42] <wgrant> stub: There weren't parens in the original, so I didn't add them. Although I wonder if that's just how it rendered it, as it seems to change whitespace.
[10:42] <wgrant> I shall fix it, anyway.
[10:42] <stub> wgrant: They get stripped by PG, which always worries me
[10:43] <wgrant> Oh, that is rather awful.
[10:43] <stub> It gets it right, but I know *I* will mess things up without them.
[10:43] <wgrant> I noted their absence and considered fixing them. But then decided to make minimal changes.
[10:43] <wgrant> Didn't think it would strip them...
[10:44] <stub> it is reconsituting the expression that was compiled I think, sans comments etc.
[10:44] <stub> not sure
[10:45] <wgrant> Yeah, I was thinking it couldn't do that, but of course this is a view not a function.
[10:45] <wgrant> Thanks lifeless.
[10:48] <wgrant> frankban: I'd remove the request for 11239, as it is redundant and likely to confuse.
[10:49] <wgrant> stub: As for the merged check, the more likely reason for its omission is the preferredemail check.
[10:49] <wgrant> Since a merged account will never have an email address, let alone a preferred one.
[10:50] <frankban> wgrant: let me guess, applying 11275 also means applying my patch, am I right?
[10:50] <wgrant> frankban: Yep.
[10:50] <frankban> wgrant: ok thanks
[10:50] <stub> True. Probably me prematurely optimizing.
[10:51] <wgrant> frankban: That revision will be checked out, and all of the patches in that tree applied if they aren't already applied.
[10:51] <wgrant> frankban: So all changes from current production to that revision will be applied.
[10:53] <frankban> wgrant: very clear, request removed
[10:53] <wgrant> frankban: Looks good, thanks.
[11:08] <Laney> Remind me about teams: are administrators members?
[11:09] <wgrant> Laney: At present yes.
[11:09] <wgrant> Laney: Owners are not.
[11:09] <Laney> OK, and what can the owner do that administrators cannot and vice-versa?
[11:10] <wgrant> Today, owners can do everything admins can, plus change the owner, promote members to admins, and change their own expiry date if they are a member.
[11:10] <Laney> uh, thought I was asking this in #lp, sorry
[11:10] <wgrant> But this will change tomorrow.
[11:10] <wgrant> As admins are gaining the ability to promote others to admins, and to change their own expiry date.
[11:11] <wgrant> So the only things special about the owner are that they aren't necessarily a member, and that they can change the owner.
[11:11] <wgrant> s/are that/will be that/
[11:12] <Laney> and that they don't get all of the mail that admins do (#908144 prompted my questions).
[11:12] <_mup_> Bug #908144: No way to customise receipt (or not) of team membership expiry/join emails <email> <notifications> <Launchpad itself:Triaged> < https://launchpad.net/bugs/908144 >
[11:12] <wgrant> Ah, yeah, that too.
[11:12] <wgrant> But that's not meant to be a privilege :P
[11:14] <Laney> I was trying to figure out if having non-member administrators would be a better fit than subscribing to administrator mails
[11:14] <Laney> thanks for the info
[11:15] <wgrant> I would like to remove owners, and instead have non-member administrators.
[11:15] <wgrant> It is somewhat controversial, however.
[11:30] <stub> owner is needed as a defence against rogue administrators. We don't want to have to arbitrate in feuds.
[11:30] <stub> wgrant: https://code.launchpad.net/~stub/launchpad/garbo-bulk-pruner/+merge/87461
[11:36] <wgrant> stub: Do openididentifier and accountpassword cascade?
[11:36] <wgrant> Ah, yes.
[11:37] <wgrant> Handy.
[11:38] <stub> yes, although looptuner tuning would be more predictable if those rows were purged in separate jobs.
[11:38] <wgrant> Mmm.
[11:38] <wgrant> Only slightly.
[11:38] <wgrant> It should be pretty much 1-1-1
[11:38] <stub> yer. don't think anyone would notice.
[11:41] <StevenK> stub: I'm nitpicking, but you should update the copyright years. :-)
[11:42] <wgrant> stub: What does SELECT COUNT(*) FROM emailaddress JOIN person ON person.id = emailaddress.person WHERE emailaddress.account IS DISTINCT FROM person.account; say on prod?
[11:42] <wgrant> s/IS DISTINCT FROM/!=/ was 0 yesterday, but this is probably closer to what we actually care about.
[11:46] <stub> wgrant: 0
[11:47] <wgrant> Surprising!
[11:47]  * wgrant approves
[11:47] <wgrant> Thanks.
[11:48] <stub> What is the script that does the copyright stuff automagically?
[11:48] <wgrant> utilities/update-copyright
[11:54] <stub> wgrant: Long term, I think it would be good to have both Account and Person. I don't like bots and things claiming to be people. We collapsed the concepts unfortunately (along with teams for even more fun).
[11:55] <wgrant> stub: Possibly.
[11:55] <wgrant> It's hard to say what we should do.
[11:55] <wgrant> Person is really Principal.
[11:55] <wgrant> Or Role.
[11:59] <stub> Yes, and if we had called it something like that at the time things would be nicer now.
[11:59] <wgrant> Anyway, we can easily shuffle these things around later on once we don't have a conflict-happy model :)
[13:48] <benji> hmm, someone is looking for JS injection points: https://answers.launchpad.net/launchpad/+question/183686
[13:52] <rick_h__> benji: heh, yep
[13:53] <rick_h__> man, junk ppa and everything
[14:28] <abentley> rockstar: About bug 911090: I know that Launchpad should be robust against 16 MB code review comments, but I also think tarmac should not be making 16 MB code review comments, because they make code review hard to read.
[14:28] <_mup_> Bug #911090: merge proposal is broken with consistent timeouts <timeout> <Launchpad itself:Triaged by abentley> <Tarmac:New> < https://launchpad.net/bugs/911090 >
[14:33] <cr3> odd, launchpad.net/projects seems to be forbidden now :(
[14:35] <jelmer> cr3: probably something private on that page
[14:36] <cr3> jelmer: is that expected behavior or should I report a bug against launchpad itself?
[14:37] <stub> That would be a bug.
[14:37] <jelmer> cr3: that's a bug
[14:37] <jelmer> presumably those private items that you're not allowed to view should just be hidden rather than making the entire page inaccessible
[14:37] <stub> Projects lists 'latest teams', and should be hiding private teams you shouldn't be able to see rather than making the page fail
[14:40] <cr3> jelmer, stub: reported bug #911794
[14:40] <_mup_> Bug #911794: /projects page now returns forbidden <Launchpad itself:New> < https://launchpad.net/bugs/911794 >
[14:41] <rick_h__> benji: https://bugs.launchpad.net/launchpad/+bug/911632
[14:42] <benji> rick_h__: I guess he found one.
[14:43] <rick_h__> yea, checking it out.
[15:08] <abentley> frankban: Please target your reviews to "canonical-launchpad-reviewers" (which is the default-- you can just leave it blank in the web form) rather than "launchpad"
[15:08] <frankban> abentley: ok, thank you
[15:09] <abentley> frankban: Thanks.
[15:51] <deryck> abentley, is there a bug, either upstream or in lp, about pystache and scoping issues?
[15:52] <abentley> deryck: I don't think so.
[15:53] <deryck> abentley, do you mind filing an lp bug at least?  Should be a high bug, but we can work on it on maintenance, to avoid the tech debt in our code.
[15:55] <flacoste> deryck: from a maintenance point of view, bug 911520 seems really terrible :-/ we should probably disable oops pruning until it's fixed
[15:55] <_mup_> Bug #911520: Pruning fails to find any references, deleting all OOPSes older than a week <python-oops-tools:Triaged> < https://launchpad.net/bugs/911520 >
[15:55] <abentley> deryck: However, I did report it to the author of pystache, who agreed it was a bug.
[15:55] <deryck> abentley, ah, ok.  Do you mind filing the lp bug for us, too?
[15:56] <deryck> flacoste, ack, I'll add the bug to the backlog and have oops pruning disabled.
[15:56] <deryck> or the next lane rather.
[15:56] <flacoste> deryck: thx
[15:58] <flacoste> deryck, mrevell: when are we releasing bug-columns?
[15:58] <abentley> deryck: As soon as I make sure it's still present...
[15:59] <deryck> abentley, ah, ok.  Thanks!
[16:00] <mrevell> flacoste, danhg is preparing the announcement.
[16:00] <mrevell> deryck, do you have time for a call?
[16:00] <flacoste> mrevell: great!
[16:02] <deryck> mrevell, I do shortly.  give me 10-15 minutes to finish the stuff I'm on.  it's a bit interrupty :)  hard to just drop.
[16:02] <mrevell> thanks deryck
[16:07] <flacoste> gary_poster: we did complete the work to make apache serves the wadl right?
[16:07] <gary_poster> flacoste, yes
[16:12] <abentley> rick_h__: I'm filing a new bug, and when I start to type in "Further information:", the box gets longer immediately.  Is this fallout from your work?
[16:12] <rick_h__> abentley: probably
[16:13] <abentley> rick_h__: This is on Firefox 8.0
[16:14] <rick_h__> abentley: ok
[16:18] <abentley> deryck: bug 911840
[16:18] <_mup_> Bug #911840: Launchpad works around pystache scoping bug <bug-columns> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/911840 >
[16:19] <deryck> abentley, awesome, thanks!
[16:24] <deryck> mrevell, we can chat now if you like.
[16:24] <deryck> mrevell, Skype?
[16:32] <deryck> rick_h__, and I understand our card titled: "Refactor bug listing ordering history code out of the template file" ….
[16:32] <deryck> rick_h__, this would help prevent any other oops with history handling, if this was moved out to a separate js file, yes?
[16:33] <rick_h__> deryck: right, it can't be tested like the rest of the JS code because of logic in the .pt files
[16:33] <deryck> rick_h__, can you file a high bug about that and pass me the bug number then please?
[16:33] <rick_h__> deryck: so factoring it out into a init or something that's called from the .pt would allow some better testing in JS tests
[16:33] <rick_h__> deryck: sure thing
[16:39] <rick_h__> deryck: 911857
[16:40] <rick_h__> abentley: thanks, I confirm seeing that FF issue. Created a bug for it and will check it out.
[16:40] <abentley> rick_h__: cool.
[16:42] <deryck> rick_h__, thanks
[16:48] <jcsackett> sinzui: have some time to mumble?
[16:51] <sinzui> yes
[16:59] <rick_h__> abentley: have a sec for a ?
[17:00] <abentley> rick_h__: sure.
[17:00] <rick_h__> so have this bug: https://bugs.launchpad.net/launchpad/+bug/911632 with this mp in progress https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507
[17:00] <rick_h__> abentley: and looking at how to test this?
[17:01] <rick_h__> abentley: it looks like I could try to change the dev data's name in the story, but seems a bit much for it
[17:01] <rick_h__> abentley: so curious if I should try to create a new user with the known xss? Just say this is such a small fix, no new test?
[17:04] <abentley> rick_h__:  I would test it by creating a person with a bogus name, rendering the relevant view (using getViewBrowser) and asserting that the resulting HTML did not have the unescaped version.
[17:05] <rick_h__> abentley: ok cool, will check that out
[17:05] <abentley> rick_h__: I would not touch the doctest.  You are writing a unit test, not documentation.
[17:06] <rick_h__> abentley: yea, you're right. I was just searching for existing tests to latch onto and hit that
[17:06] <rick_h__> abentley: thanks!
[17:06] <abentley> rick_h__: np
[17:08] <abentley> rick_h__: It would be interesting to change factory.makePerson to generate people with bogus names, but I don't think even that would catch all cases.
[17:08] <rick_h__> abentley: yea, you have to be checking for the bad output specifically
[17:08] <rick_h__> abentley: until it renders there's nothing to say <script> is a bad name
[17:10] <abentley> rick_h__: If the bad characters were a consistent string, we could perhaps tweak some common code to puke if it was present.
[17:51] <sinzui> flacoste, I would like your opinion of bug 910876. Choosing to remove code to revert to the 2009 rules makes fixing other bugs easy.
[17:51] <_mup_> Bug #910876: "Remove assignee" no longer shown in bugtask assignee AJAX popup unless logged in user is the assignee <bugs> <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/910876 >
[17:54] <sinzui> maybe anyone can unassign a user, but the current rules apply to assigned teams
[18:02] <nigelb> StevenK: HAHA good one
[18:32] <flacoste> sinzui: replied, i basically agree with your first comment
[18:33] <sinzui> thank you
[18:33] <lifeless> morning
[19:06] <cjwatson> argh @gina
[19:06] <cjwatson> it imports dsc_binaries in an invalid format
[19:07] <rick_h__> abentley: can you peek at https://code.launchpad.net/~rharding/launchpad/xss_911632/+merge/87507 when you get some time please?
[19:07] <abentley> rick_h__: sure.
[19:07] <rick_h__> ty
[19:08] <abentley> rick_h__: why are you using getUserBrowser rather than getViewBrowser?  getViewBrowser already does the canonical_url bit.
[19:08] <rick_h__> abentley: when I tried getViewBrowser it failed to generate the url as "xxx broke the chain"
[19:08] <rick_h__> I went off the example from the test above it which was using getUserBrowser
[19:09] <rick_h__> abentley: but now that you say that it makes sense, since I was sending it the canonical url bit
[19:09] <abentley> rick_h__: "xxx broke the chain" is emitted by canonical_url.
[19:09] <rick_h__> abentley: right, makes sense. Basically I copied the test above it.
[19:10] <rick_h__> abentley: looking back at the getViewBrowser
[19:10] <abentley> rick_h__: Perhaps you did not specify rootsite?
[19:10] <rick_h__> abentley: right, I called it wrong. I called it like getUserBrowser
[19:10] <abentley> rick_h__: Ah.
[19:11] <rick_h__> abentley: crossing the streams between copying existing test and looking at getViewBrowser
[19:11] <abentley> rick_h__: I see.
[19:11] <abentley> rick_h__: r=me.
[19:11] <rick_h__> abentley: ty
[19:12] <abentley> rick_h__: However, I don't think the bug is meant to apply only to this issue.
[19:13] <rick_h__> abentley: well, this guy hammered all over the site and this was the instance he found it.
[19:13] <rick_h__> abentley: I've tried to think of how best to *auto* test this, but the cause was that someone at some point told zpt to specifically "not" escape this item
[19:14] <rick_h__> abentley: I could grep through all of the templates looking for structure usage and verify the content is safe
[19:14] <abentley> rick_h__: Okay.  I think you're right.  "persistent" made me think he was going for a broader issue.
[19:14] <rick_h__> abentley: but wasn't sure if I should take the time to go through all that or not tbh.
[19:16] <abentley> rick_h__: Did your second test "self.assertTrue(escapedname in browser.contents)" fail before you changed the template?
[19:16] <rick_h__> abentley: yes, I put back the structure to verify
[19:17] <abentley> rick_h__: I have a hunch it would pass because the user name appears elsewhere on the page.
[19:17] <rick_h__> abentley: the change was in place because I found the issue before finding a good place for the test, but did walk back
[19:17] <rick_h__> abentley: ah, see what you mean. However the first test fails
[19:17] <rick_h__> abentley: that's why I check for both, to make sure there is no non-escape <script> and that there is in fact an escaped one
[19:17] <abentley> rick_h__: I think the second test would not.  Can you check, and if so remove it?
[19:17] <rick_h__> abentley: you're right that the second test doesn't do much since it's in there 3 places
[19:17] <rick_h__> abentley: gotcha, will do
[19:18] <rick_h__> abentley: cool, and got getViewBrowser() to pass and work right
[19:18] <abentley> rick_h__: Great.
[19:19] <abentley> rick_h__: alternatively, you could do a more exact match on the error text.
[19:20] <rick_h__> abentley: right, gotcha
[19:22] <abentley> rick_h__: Does your branch also fix it if the error message is loaded via AJAX?
[19:22] <rick_h__> abentley: I'll double check. I believe so since it's a fix of the template used to generate the table view
[19:24] <cjwatson> Is all the gina code actually in the LP tree?  I can't find any references to ImporterHandler other than its definition.
[19:26] <cjwatson> But it seems like the main operating class ...
[19:27] <cjwatson> see also bug 830904
[19:27] <_mup_> Bug #830904: Is run-newgina.sh dead code? <Launchpad itself:Triaged> < https://launchpad.net/bugs/830904 >
[19:30] <cjwatson> Never mind, I'm talking nonsense
[19:36] <lifeless> wgrant: to answer your question '300'
[19:36] <lifeless> flacoste: did you find a timeslot for us ? :)
[19:37] <flacoste> lifeless: how about in 20 minutes?
[19:39] <lifeless> flacoste: thats the parallel testing call
[19:39] <lifeless> ah no, its not
[19:40] <lifeless> thats me going into hospital for my once a month allergy shot
[19:42] <flacoste> lifeless: when are you getting back?
[19:42] <lifeless> flacoste: its 40m in + 40m back + 30m observation + 15m friction, more or less
[19:43] <flacoste> lifeless: ping me when you get back, i'll probably still be around
[19:43] <lifeless> 1030 appointment, so back ~ 1200, which is 2300UTC
[19:43] <lifeless> flacoste: will do
[19:44] <flacoste> hmm, i got my calculation wrong then
[19:44] <flacoste> i thought that was 22UTC
[19:45] <flacoste> lifeless: if you are back before 23 UTC then ping me, otherwise, we'll have to postpone to tomorrow
[19:45] <flacoste> lifeless: before the parallel testing call, just ping me when you are online
[19:46] <lifeless> flacoste: I will ping you; if you are around, \o/ if you are not tomorrow is go
[19:47] <flacoste> lifeless: great!
[19:52] <lifeless> sinzui: do we have a general 'lp is hard to read bug' ?
[19:53] <lifeless> sinzui: I'd like to dupe https://bugs.launchpad.net/loggerhead/+bug/601392 on it
[19:53] <_mup_> Bug #601392: Loggerhead should have a better text-background contrast with Chromium <css> <ui> <loggerhead:Triaged> < https://launchpad.net/bugs/601392 >
[19:53]  * sinzui looks for mpt's last font bug
[19:54] <flacoste> mpt isn't the one who filed it iirc
[19:54] <flacoste> we won't fix it though
[19:55] <flacoste> might have been poolie
[19:57] <sinzui> lifeless, I thought mpt had reported a bug about fonts that was general to the issue. He wrote the Lp is harder to read than other hosting sites
[19:58] <sinzui> This looks like a WAI issue. Looks like someone removed the the WAI tag I had added
[20:00] <abentley> rick_h__: BTW, we also have assertIn and assertNotIn.
[20:01] <rick_h__> abentley: ooh, thanks. Bookmarked the full list.
[20:02] <lifeless> sinzui: I thought he did too
[20:03] <lifeless> rick_h__: and assertThat(foo, Contains(bar))
[20:04] <rick_h__> lifeless: cool, I saw some work with the containsHTML from the soup stuff, but I wasn't creating full tags
[20:04] <sinzui> lifeless, I ws thinking of bug 883258
[20:04] <_mup_> Bug #883258: Bug descriptions/comments much harder to read on Launchpad than other hosting services <css> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/883258 >
[20:05] <lifeless> sinzui: thanks, do you think this is a dupe, or that the loggerhead thing is different ?
[20:05] <lifeless> sinzui: if its a dupe, I will add a loggerhead task to 883258
[20:08] <sinzui> lifeless, No. I think is a separate bug. It is both a css issue and a WAI comparability issue.
[20:09] <sinzui> compatibility
[20:09] <lifeless> WAI ?
[20:21] <sinzui> lifeless, sorry, I was in another conversation: WAI was established in 1997 to tell web authors to stop messing with users: http://www.w3.org/TR/WCAG/
[20:22] <lifeless> sinzui: I've gardened the bug a little; if you wanted to add analysis to it that would be the bomb
[20:22] <sinzui> lifeless,  I tagged a few things WAI last year when Canonical said it was taking accessibility seriously
[21:59] <jcsackett> sinzui: i'll be a little late to standup; vet just called.
[22:00] <sinzui> okay
[22:02] <wgrant> lifeless: 300?
[22:02] <wgrant> cjwatson: Yes, all of gina is in the tree. Have you grepped scripts/?
[22:04] <deryck> Later on, all.
[22:43] <cjwatson> wgrant: Yeah, when I found scripts/gina.py I said "Never mind, I'm talking nonsense" :-)
[23:07] <lifeless> flacoste: ping
[23:08] <lifeless> wgrant: '6 months worth of bugs'
[23:08] <lifeless> wgrant: our rate was 200 commits/month with all squads; *6/4
[23:08] <wgrant> lifeless: Ah!
[23:39] <wgrant> lifeless: !!
[23:39] <wgrant> YAY
[23:39] <wgrant> kill, crush, destroy
[23:40] <lifeless> heh, happy new years
[23:44] <StevenK> Hm?
[23:44] <lifeless> I just proposed disabling heat aging and max-heat tracking on bug contexts
[23:45] <lifeless> which means changing heat display to a number not a fraction
[23:46] <wgrant> Which makes Launchpad fast :)
[23:51] <lifeless> well, it will remove some causes of slowness
[23:52] <wgrant> Lies.
[23:53] <lifeless> hmm?
[23:54] <wgrant> Destroying bug heat will solve all the world's problems :)
[23:54] <lifeless> Optimism from you? I'm shocked!