[12:13] <kiko> bradb, ping?
[12:13] <bradb> kiko: hi
[12:14] <kiko> bradb, any clue why me, a launchpad admin, can't edit task 268?
[12:14] <bradb> kiko: Malone doesn't know what admins are, yet.
[12:14] <kiko> isn't that a trivial fix?
[12:15] <bradb> it's about an hour or two's work, I think
[12:15] <bradb> tests will break and/or need to be added, possibly
[12:15] <kiko> hmmm
[12:16] <bradb> I can do it soon, but since I've already lost a full day to conflict resolution on the URLs branch, that's all that I worked on today. I should be able to land it later in the day tomorrow.
[12:17] <kiko> okay, gret
[12:17] <kiko> that currently hampers me from properly triaging older bugs
[12:21] <bradb> I've also still got the From/Reply-To patch in the queue, right behind the URLs fix. I've also got the form error message derobotization fix in the queue behind both of those.
[12:21] <kiko> heh
[12:21] <kiko> did Keybuk look at your patch?
[12:22] <bradb> yes, small header addition (+ tests, of course) needed for RFC compliance
[12:22] <kiko> ah, wonderful. he's a star
[12:32] <Keybuk> the second one on the left, and on til' morning
[12:56] <Nafallo> salgado: care to mark up the bug as NOTABUG and stuff? :-)
[12:58] <salgado> Nafallo, I haven't done so because we still can allow team admins to change their own membership's expiry date if the date is prior to the existing expiry date
[12:58] <salgado> although I'm not sure if that would be useful
[12:59] <Nafallo> hmm, with a check to see if there is more admins in that team? :-)
[01:00] <salgado> sorry, why would we need to check if there's more admins?
[01:01] <Nafallo> if you are the last admin you shouldn't be able to expire yourself?
[01:01] <salgado> I don't think that's a problem
[01:01] <salgado> the owner retain his rights over the team even if he's not a member
[01:02] <Nafallo> yea, that's true. and I gave away the ownership before I tried to change the expiry date ;-)
[01:03] <salgado> heh
[01:03] <Nafallo> but it's better that way anyway. I'm admin for the LoCo and the other admin is a translator herself :-)
[01:03] <Nafallo> she would be the right owner of the team :-)
[01:04] <salgado> and there's also the launchpad admins for the help, if needed
[01:04] <salgado> anyway. gotta go. see you guys
[01:04] <Nafallo> yea :-). this channel rocks :-).
[01:04] <Nafallo> well, THAT was a quick quit :-P
[03:03] <Kinnison> spiv: ping?
[03:03] <spiv> Kinnison: pong
[03:03] <spiv> I'm just heading out the door to visit lifeless
[03:03] <kiko-zzz> wtf is my merge
[03:04] <Kinnison> spiv: when you get a moment can you make sure you update me on the state of the publishing review?
[03:04] <Kinnison> spiv: I sent you a mail about it last week and haven't heard anything
[03:04] <Kinnison> it's now 02:04 and I'm off to bed
[03:04] <Kinnison> ciao
[03:04] <spiv> Ok, I'll look for that.
[03:14] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Tests and a fix for URLs trailed with semi-colons; a bit trickier than one might expect. (patch-2436: christian.reis@canonical.com)
[05:38] <jhemgel> hi
[05:39] <jhemgel> to those who chating here
[05:43] <dilys> Merge to rocketfuel@canonical.com/launchpad--production--1.33: Cherry pick patch-2434 into production 1.33 (patch-4: rocketfuel@canonical.com, guilherme.salgado@canonical.com)
[06:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Add production db patch into rocketfuel (patch-2437: stuart.bishop@canonical.com)
[07:03] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: add request timeout code to database adapter, r=SteveA (patch-2438: james.henstridge@canonical.com)
[07:27] <mpool> hi?
[07:28] <mpool> in malone, when i'm looking at a bug
[07:28] <mpool> e.g.
[07:28] <mpool> https://launchpad.net/malone/bugs/2350
[07:28] <mpool> it is not very obvious how i can navigate to other bugs in that product
[07:28] <mpool> shouldn't there be a way?
[07:31] <bob2> I reported that the other day
[07:31] <BjornT> mpool: yes, that's a problem. it will be fixed soon. for now, you can click on 'upstream bzr', and then you'll see a portlet to the right with "View bug reports for Bazaar-NG"
[07:32] <mpool> thanks BjornT 
[07:32] <mpool> it's looking really good btw
[07:38] <jblack> Just in case nobody knows, it looks like launchpad is down.
[07:39] <stub> Yup - I'm upgrading
[07:40] <Burgundavia> jblack, I had an idea about patch management and pqm
[07:40] <jblack> Burgundavia: Whats on your mind? 
[07:41] <Burgundavia> jblack, basically my thought was on the workflow of users who we don't want to just be able to commit when we switch to baz
[07:41] <Burgundavia> s/we/the doc team
[07:42] <jblack> That shouldn't be a problem. Just don't give them pqm access.
[07:42] <Burgundavia> but we need a nice way of submitting and accepting patchers
[07:42] <Burgundavia> patches
[07:42] <Burgundavia> the mailing list works, but hey, lets go beyond just works
[07:42] <jblack> Ok. I'm with you so far. 
[07:43] <jblack> In Baz-NG, there's a wiki page. Other projects tend towards keeping merge requests as open bugs. 
[07:43] <Burgundavia> basically the ubuntudoc script that we talked about would push their patch upto a place where they can viewed in a queue, sort of liek the mailman accept/reject mail inteface (but nicer)
[07:44] <Burgundavia> have you seen what the MOTU's are doing with REVU?
[07:45] <jblack> No, I haven't seen that yet.
[07:45] <jblack> Sounds like a good idea, actually. Just needs somebody to write it.
[07:45] <Burgundavia> it would be a killer feature for those switching away from svn/cvs
[07:45] <jblack> There's a bzr webserver plugin too, which should cut out some of the slack.
[07:45] <Burgundavia> removes some of the scary distributed stuff
[07:49] <stub> spiv: I just upgraded launchpad and realized we will need to upgrade the librarian too (?)
[07:49] <jblack> burgundavia: Would you be interested in writing a spec for it? 
[07:49] <bob2> hahahaha
[07:49] <Burgundavia> jblack, yes I can do that
[07:50] <Burgundavia> jbailey, PatchWebQueue ?
[07:50] <jblack> Cool. There's a page at http://bazaar.canonical.com/BzrRequests that has pretty good examples of what to do
[07:50] <stub> Launchpad is back up
[07:51] <spiv> stub: Hmm, will we?
[07:51] <spiv> stub: There are schema changes affecting it..?
[07:51] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  tweak config schema due to ZConfig issues on emperor (patch-2439: stuart.bishop@canonical.com)
[07:52] <Burgundavia> jbailey, the the bzr wiki, it uses lp login?
[07:56] <stub> spiv: The logging-exceptions-to-librarian code is out, which needs the fixes I made
[07:56] <spiv> Aah.
[07:56] <stub> spiv: (assuming that hasn't already gone out)
[07:56] <spiv> Ok, I'll do that.
[07:57] <spiv> I don't think it has.
[07:57] <stub> Ta. I'm not sure how you are rolling it out and can't be arsed setting up the keys for my way again ;)
[07:58] <spiv> I'm rolling it out with far too much manual effort :/
[08:00] <jblack> burgundavia: You mean this jbailey? 
[08:00] <Burgundavia> jblack, grr, yes
[08:00] <jblack> I believe it has its own credentials. 
[08:00] <jblack> But I'm not sure on that
[08:00] <spiv> Yeah, I think that's right.
[08:01] <spiv> Compare the login page to the Ubuntu wiki.
[08:01] <Burgundavia> it looks liek it
[08:01] <Burgundavia> grr
[08:08] <Burgundavia> jblack, http://bazaar.canonical.com/BzrRequestPatchWebQueue
[08:33] <SteveA> hi
[08:37] <SteveA> stub, spiv, jamesh: i want to do some work on the error handling in launchpad this morning
[08:38] <SteveA> stub: kiko said you'd put something there that stores traceback data in the librarian
[08:41] <spiv> stub: the new librarian is up.
[08:48] <jamesh> SteveA: okay.  Anything in particular?
[08:50] <SteveA> any ideas on what best to do?
[08:50] <SteveA> i was thinking of making tracebacks go into a directory structure on the filesystem
[08:50] <SteveA> and having a configurable notification by email
[08:51] <SteveA> i don't like the idea of putting them in the librarian
[08:51] <jamesh> SteveA: btw, the request timeout branch passed PQM and is in rocketfuel now
[08:51] <SteveA> because that involves other systems, and a database transaction, inside an error handler
[08:51] <SteveA> thanks jamesh.  i
[08:51] <SteveA> 'll add the publisher parts.
[08:56] <SteveA> stub: what's happening with cherrypicking for shipit?
[08:57] <jamesh> SteveA: so this would involve a custom IErrorReportingService?
[08:58] <spiv> SteveA: FWIW, there's no database transaction inside the error handler, it uses librarian server-side transactions.
[08:58] <SteveA> jamesh: actually no.  i would get rid of the error reporting service, and put this directly in the publisher, to be factored out as an event handler later.
[08:59] <SteveA> the publisher's error handling code is too complex.
[09:01] <SteveA> spiv: i see. even so, i'm not wild about depending on a system that has many of the same system dependencies for error reporting.
[09:02] <spiv> I agree that error handling should be simple.  Just letting you know :)
[09:22] <stub> SteveA: For scripts, exceptions now get stored in the librarian and a link outputted instead of the full traceback
[09:22] <jamesh> SteveA: so the plan would be to add the appropriate notify() call to handleException in canonical/publication.py, and have some new code handle things from there?
[09:23] <jamesh> SteveA: would we want to keep the web frontend for viewing exceptions?
[09:23] <stub> SteveA: For error handling in Launchpad, I was thinking of looking into how the Z3 logging is put together. If it is using the standard Python logging modules we can configure it to do what we want. eg. buffer exceptions in ram and email them out every 30 minutes could be done with components from the standard library.
[09:24] <stub> Sticking tracebacks in the librarian is good because we get garbage collection for free
[09:24] <stub> And a UI for downloading them for free
[09:26] <stub> Have a look at lib/canonical/launchpad/scripts/logger.py - the librarian storage is done just using a Formatter we register with the Python logging system
[09:30] <jamesh> I'm not actually sure what's so complicated about the IErrorReportingService -- it looks like it would be quite easy to do a different implementation that stored the exceptions to disk with the existing interface
[09:30] <jamesh> and would drop right in
[09:31] <SteveA> for one thing, the entire concept of a "service" is going away when we upgrade zope
[09:32] <jamesh> ah.
[09:33] <SteveA> we can still use the same interface
[09:34] <jamesh> I was thinking it would be good to use the same interface in case there were other cases where it was used to log exceptions
[09:35] <SteveA> there aren't.  it's just a plug-in to the publication component.
[09:35] <SteveA> and the publication component plugs into the publisher
[09:35] <SteveA> but it's all more complex than it should be
[09:35] <stub> If we log exceptions to email, there is no need to provide a second interface through the publisher.
[09:35] <stub> pipermail becomes our UI
[09:35] <SteveA> you mean "user interface" ?
[09:36] <stub> Yes.
[09:36] <jamesh> stub: what I'd like would be if the Launchpad error page included a token people could include in their bug reports
[09:36] <SteveA> i'd like that too
[09:36] <jamesh> so we could look up the error afterwards
[09:36] <jamesh> that sort of thing is a lot easier with a web interface
[09:36] <SteveA> i think that's documented in a spec somewhere...
[09:36] <stub> Sure. We have the content id and alias id we stored in the librarian
[09:36] <jamesh> (this doesn't preclude sending tracebacks by email too)
[09:39] <SteveA> we can stick the content id and alias id into Diceware
[09:39] <SteveA> and make some words for the user to remember
[09:39] <SteveA> like "your error code is: dayglo fishcake"
[09:40] <stub> (actually, we only need the contentid to look up the exception url)
[09:40] <stub> erm... aliasid
[09:41] <jamesh> are exceptions considered private?
[09:42] <jamesh> if so, then is sticking them in the librarian a good idea?
[09:42] <stub> Yes. Users cannot access them if they know just the aliasid or the contentid - they also need the secret
[09:42] <stub> (which is the filename in our case)
[09:47] <sivang> morning all!
[09:48] <SteveA> hi
[09:49] <SteveA> so, what do we have so far?
[09:50] <SteveA> when there's an error, the error reporting service or some equivalent puts together a blob of traceback and diagnostic data and throws it at the librarian.
[09:50] <SteveA> it also throws a randomly generated filename at the librarian.  the librarian returns with its aliasid.
[09:50] <SteveA> the aliasid is presented to the user as the "error code" or some such
[09:51] <SteveA> agreed so far?
[09:52] <stub> Sounds fine. Existing code handles that except for getting the aliasid back to the caller (which I don't think fits into the standard Python logging stoof, so we might need to bypass that)
[09:53] <SteveA> i didn't mention logging above
[09:53] <SteveA> okay, there's another requirement
[09:53] <stub> We should also take this opertunity to email the exception to a list somewhere, or store the url in a file and a cronjob emails them regularly
[09:53] <SteveA> we get lots of 404 errors. sometimes these are interesting.  often they are not.
[09:53] <SteveA> we're interested in the "Referer" header
[09:54] <SteveA> we want these to be categorized as separate from the other errors
[09:54] <stub> Yer... 404 will need special handling. Possibly a daily report.
[09:54] <SteveA> is there any reason not to use the same "stick it in the librarian" handling?
[09:54] <SteveA> or is that just unnecessary
[09:54] <jamesh> we currently get the referer from the environment passed to the request
[09:55] <stub> Oh - stick in the librarian, sure. But the report *we* see needs to be readable.
[09:55] <SteveA> right, getting the referer is no problem
[09:55] <SteveA> so, for every error we want to generate three things:
[09:55] <SteveA>  - blob for the librarian
[09:55] <SteveA>  - human readable email text
[09:55] <SteveA>  - email subject line
[09:56] <SteveA> can mailman topic gather the 404s together?
[09:56] <stub> If we just store a csv file or something of code, url then a cronjob can format that anyway it wants and provide a daily report.
[09:56] <stub> No - mailman cannot do that. We need to handle this ourselves.
[09:57] <SteveA> i'd be happy sticking 404s in the actual databae
[09:57] <SteveA> as they aren't really a random crashing error
[09:57] <stub> We could stick all the exceptions in the database if you want, but it makes things more compliated because of the transaction handling involved.
[09:57] <jamesh> it looks like a bunch of the recent 404's are from googlebot
[09:58] <SteveA> so, user agent is important too
[09:58] <SteveA> i don't want to put crashes into the database.
[09:58] <SteveA> 404s i don't mind.
[09:58] <jamesh> looking for things that used to exist but don't now
[09:58] <SteveA> we don't need "error codes" for 404s
[09:59] <SteveA> nor for forbidden
[10:00] <stub> I think storing all the exceptions in a file (or one file per 'type') and a cronjob or two will be the simplest implementation.
[10:00] <SteveA> so, no librarian?
[10:00] <stub> Yes, librarian. Change 'storing all the exceptions' to 'storing the urls to the exceptions'
[10:00] <SteveA> or do you mean store the "diagnostic blob" in the librarian
[10:01] <SteveA> and store the metadata in files
[10:02] <robitaille> is that normal that I cannot access the +edithackergotchi  of my own LP account?
[10:03] <SteveA> i don't know -- the hackergotchi stuff hasn't been specced, so i don't know what it is meant to do.
[10:04] <jamesh> robitaille: sounds like a bug
[10:04] <SteveA> jamesh: would you like to take on fixing it?
[10:05] <jamesh> SteveA: yeah.  Just switching my tree to check it
[10:05] <SteveA> cheers
[10:05] <SteveA> looks like it's lacking a system doc or page test
[10:09] <stub> Exceptions are stuffed in the Librarian. The id is returned to the user.
[10:09] <stub> The exception is classified, and interesting information about it stored in a simply formatted file (referrer_id, exception url, logged in username, whatever). One file per classification please.
[10:09] <stub> cronjobs run assembling reports from the files. Interesting types might be run every 60 seconds, 404 report run daily.
[10:09] <stub> todo: if a bug is linked to an exception, we should ensure that exception does not expire from the library. 
[10:14] <SteveA> how do you mean "bug is linked to an exception" ?
[10:14] <SteveA> you mean if we have a link to the librarian, including secret, in the body of a malone bug?
[10:14] <stub> No - the exception token we discussed before.
[10:14] <SteveA> i see
[10:15] <SteveA> how does a launchpad developer see the token + secret?  it is emailed out?
[10:15] <stub> If it is just included as text in the bug comment, then the default expiry for the traceback stored in the librarian will be unaffected so it will be removed after time (although what that timeout is has not been defined yet).
[10:17] <stub> If there is a real link between the bug and the libraryfilealias, the bug ui would display the url to admins. But that is very launchpad specific behavior to encode in Malone. So this is where my ideas are breaking down.
[10:17] <jamesh> hmm
[10:17] <jamesh> +edithackergotchi requires launchpad.Admin ...
[10:17] <SteveA> jamesh: yes, saw that during menus work
[10:18] <SteveA> jamesh: that's what i meant by "there is no spec, so i have no clue what it should do"
[10:18] <stub> It is possibly protected because Mark has more stuff he wants to do on it. Perhaps the image size constraints are not done.
[10:18] <jamesh> stub: there are image size checks (both dimensions and file size)
[10:18] <carlos> morning
[10:19] <stub> yo
[10:20] <jamesh> looks like the issues with the interface and database classes are still unresolved in what Mark checked in
[10:22] <SteveA> what are the issues?
[10:24] <jamesh> the added field definitions reflect the data entry schemas rather than what the database classes implement
[10:25] <SteveA> we should always have a test that a database instance verifies against the interfaces it provides
[10:25] <SteveA> if it does not verify, that's a bug
[10:25] <jamesh> e.g. IPerson.hackergotchi is of type Bytes, and has a validator that checks that the data is a valid image
[10:25] <jamesh> while the database class's Person.hackergotchi is a foreign key into the LibraryFileAlias table
[10:27] <SteveA> sounds like it should be a LibrarianFile field rather than a Bytes field
[10:27] <jamesh> yeah
[10:27] <SteveA> and we make LibrarianFile mean "Bytes, and it's a foreign key in launchpad"
[10:27] <jamesh> the data entry form should be using a browser-specific schema
[10:28] <SteveA> i don't think that's necessary
[10:28] <SteveA> if we make a suitable field available
[10:28] <jamesh> well, there were a few other issues like that
[10:29] <SteveA> if they're just like that, then we just need some more specific or richer fields to use to describe the database classes.
[10:29] <stub> Because Mark used the database/interface.py interface for generating forms rather than creating a schema specific to the form he wanted, possibly.
[10:29] <jamesh> the IBugCve using Int field types when the database class uses ForeignKeys
[10:29] <jamesh> stub: that's the issue at hand
[10:30] <jamesh> that interface is used to generate the +linkbug form, which has a bug number entry field
[10:33] <SteveA> i think we just need a Field that describes this situation
[10:59] <SteveA> stub: is there already a spec on improved error reporting, or do i need to create one?
[11:03] <stub> SteveA: Nothing yet. I've just been thinking about it a bit because of the work I did to make the script logging a bit saner
[11:03] <SteveA> stub: i'll stick the outcomes of this morning's conversation on a wiki page
[11:04] <SteveA> stub: what's happening with shipit ?
[11:05] <stub> I'm not involved in the shipit stuff except for the occasional email that flys past my mailbox. I don't know what is happening.
[11:05] <SteveA> there's a fix to the "country" issue you found
[11:05] <SteveA> salgado made the fix
[11:05] <SteveA> you're cherrypicking it into production
[11:05] <stub> ok.
[11:05] <SteveA> then i'm getting elmo/karl to do the vhosting magic
[11:06] <SteveA> so, i need to know when it is picked and running again
[11:06] <stub> I think I did... hang on.
[11:07] <stub> Yes - it is already rolled out. I've replied to that email which I hadn't done yet.
[11:08] <stub> My order now says 'Australia'
[11:09] <SteveA> cool
[11:09] <SteveA> i'll get with the admins
[11:34] <Luna-Tick> Hello all :)
[11:35] <Luna-Tick> Whenever I come in here there doesn't seem to be anyone who responds...
[11:35] <bob2> indeed
[11:35] <Luna-Tick> Why hello bob
[11:36] <Luna-Tick> Well, bob, I guess that I will tell you my ideas....
[11:36] <Luna-Tick> and the others can read it if they come back
[11:36] <Luna-Tick> Two quick things:
[11:36] <Luna-Tick> 1) it seems really odd that Launchpad is this incredibly comprehensive end-to-end solution, but enhancements to it are in a wiki
[11:37] <Luna-Tick> on that point; enhancement requests are really quite poorly handled at this stage - I can't figure out if I am meant to file a normal bug for them or what...
[11:37] <Kinnison> There are various camps on that point
[11:37] <Luna-Tick> Oh?
[11:37] <bob2> there were long long discussions about that
[11:37] <Kinnison> E.g. the "It's a bug if the feature isn't implemented" camp
[11:38] <bob2> (amen!)
[11:38] <Luna-Tick> Right.... 
[11:38] <Kinnison> And the "It's a spec needing implementing" camp
[11:38] <Kinnison> And the "It's a support request which needs to be resolved" camp
[11:38] <Luna-Tick> It is quite confusing for people who are looking for it
[11:38] <bob2> yes
[11:38] <Kinnison> I don't believe we have a best-practice method yet
[11:38] <Kinnison> So yes, quite confusing
[11:38] <Luna-Tick> Even if there was an 'enhancement' category in the priority like bugzilla
[11:38] <bob2> Luna-Tick: people argued against that
[11:38] <Luna-Tick> ah
[11:39] <Luna-Tick> Well, that is fair, I never liked that
[11:39] <Luna-Tick> They seem quite different... all the boxes are wrong etc. square peg, round hole
[11:40] <Luna-Tick> When there is such a powerful system, it seems a bit of a missing thing... but if you have all talked about it, that is fair
[11:40] <Luna-Tick> It would be nice, however, if there were enhancements which could turn into bounties by someone putting money on them etc.
[11:40] <Luna-Tick> and on that note, it would be great to be able to combine bounties.
[11:41] <Luna-Tick> So that I could add my measly $10 to a bounty
[11:41] <Luna-Tick> or I could come up with a great idea and someone who wasn't a starving student could put money on it
[11:42] <Luna-Tick> For smaller bounties, Ubuntu could take paypal or credit cards etc (passing on the fee) and keep the amounts in trust (earning interest) until time elapsed or the bounty was done
[11:42] <Luna-Tick> But I am very glad to see that they have a bounty thing at all - a real step in the right direction.
[11:42] <Luna-Tick> Anyway, the reason that I came on here is because I was thinking about your Karma system and how it related to duplicate bugs
[11:43] <Luna-Tick> and it occurred to me that in practice, people choose the best of the bugs and dupe the worst, even if the 'duped' one was filed first
[11:43] <SteveA> stub: https://wiki.launchpad.canonical.com/ErrorReportManagement
[11:45] <Luna-Tick> So what I was going to suggest was that the system only take Karma away if your bug was duped against a bug which was filed before yours
[11:45] <Luna-Tick> Steve: how is that stub relevant?
[11:45] <SteveA> Luna-Tick: i don't understand your question.
[11:45] <Luna-Tick> Oh... it wasn't connected to what I was saying>
[11:47] <SteveA> yep.
[11:47] <Luna-Tick> Okay. Well, I have had my little rant at the world. Hopefully someone agreed, disagreed or at least vaguely pretended to care.
[11:47] <SteveA> "stub" is stuart on irc.
[11:47] <SteveA> i'm telling him about a spec i just braindumped.
[11:47] <Luna-Tick> Ah! I thought you meant that the wiki page was a stup
[11:48] <Luna-Tick> stub
[11:48] <Luna-Tick> Sorry
[11:48] <SteveA> no worries
[11:49] <Luna-Tick> Okay... Well... I guess that everyone is too busy working on Ubuntu for chit-chat
[11:49] <Luna-Tick> But thanks for your time
[11:49] <Luna-Tick> Ciao
[12:05] <SteveA> stub: what were we going to do about canonical.encoding.guess ?
[12:06] <Kinnison> hey spiv
[12:07] <spiv> Hey.
[12:11] <stub> SteveA: raise an exception if it doesn't break tests (or the callsites are trivial fixes)
[12:11] <SteveA> the only warning is being raised from its own test
[12:11] <SteveA> so, no tests broken
[12:17] <carlos> see you later
[12:53] <Kinnison> stub: It seems that if a section of gina's config has source_only set then gina -a stops after that section
[12:54] <stub> Sounds like a bug
[12:55] <stub> I've just submitted a bug report
[01:05] <Kinnison> cool
[01:05] <Kinnison> filing bugs with PGP/MIME seems a bit fraught
[01:17] <stub> If you mean the 'This is an OpenPGP/MIME signed message (RFC 2440 and 3156)' garbage, I committed a fix for that earlier today
[01:21] <Kinnison> coolio
[01:22] <ddaa> lifeless: help!
[01:23] <ddaa> psvn is killing my puppies!
[01:24] <ddaa> lifeless: so, psvn.Client.ls return a list of dicts, with a 'name' key, whose value is: "string - name of the file", is that a base name, a relative name, relative to what?
[01:31] <ddaa> okay... found it... it's a url...
[01:31] <ddaa> I guess it's an absolute path for some stupid value of absolute...
[01:32] <lifeless> ddaa: its crack, sometimes you get rel paths, sometimes abs url, and it isn't consistent trhough out the api
[01:33] <ddaa> I'm trying to change filterOutsidepath to work in absolute paths
[01:33] <ddaa> so it can be used for filtering listing from other branches
[01:33] <ddaa> (BTW, I realised that my implement of recursive merging is wrong, because I'd bet you can A /foo and D /foo/bar in the same changeset)
[01:34] <ddaa> so I was trying to add a "svnpath" method to Change and Source
[01:34] <ddaa> but it looks like the plumbing is not there...
[01:34] <ddaa> maybe I should use url() instead, then
[01:35] <ddaa> lifeless: any suggestion?
[01:37] <lifeless> ddaa: there is examples of such already
[01:38] <lifeless> ddaa: but I couldn't get svn to give me stable references
[01:38] <lifeless> ddaa: so each one is essentially special cased.
[01:38] <lifeless> -> I hate svns library.
[01:39] <lifeless> look in Change, it has the basic plumbing that the others build on
[01:39] <ddaa> that's what I was looking at
[01:39] <ddaa> I had little trouble to write Change.svnpath
[01:39] <ddaa> but Source does not have the necessary information there
[01:40] <ddaa> (in Change, it's just return self.log['path'] )
[01:40] <ddaa> nevermind, I'll just work with url()
[02:00] <ddaa> lifeless: BTW, did you find natural occurences of SVN logs not being in the right order?
[02:01] <ddaa> my feeling is that svn code is lacking in abstraction
[02:01] <ddaa> at bit like CVS code (unsurprisingly)
[02:01] <ddaa> so I expect the log to be prepared to be processed by dumb client logic
[02:01] <ddaa> a bit in the way a cvs client is mostly an interpreter for CVS server messages
[02:02] <mpt> Goooooooooooooooooooooooooooooood morning Launchpadders
[02:03] <niemeyer> Good morning! :-)
[02:10] <sivang> morning mpt
[02:10] <sivang> mpt: maybe you can say "Launchpad Lovers" ;)
[02:11] <mpt> "Launchpad Lovers" is so yesterday
[02:11] <niemeyer> Nice piece of code: http://www.thedailywtf.com/forums/43223/ShowPost.aspx
[02:11] <niemeyer> :)
[02:12] <mpt> (2005-09-19 09:09:56) <mpt> Good morning Launchpad lovers
[02:14] <sivang> mpt: lol
[02:17] <sivang> niemeyer: I can't believe something like that is used in real production environments ;)
[02:18] <sivang> niemeyer: what if the catch expection mechanism has some kind of bug? is someone ready to find it out on a proudction site ? ;-)
[02:24] <ddaa> interestingly, a similar pattern is recommended in Python for quick dictionnary lookups where the key may not be present.
[02:25] <ddaa> But it's probably only because Python performance sucks so badly.
[02:31] <sivang> ddaa: well, but there you really don't know if the key is present, in the mentioned code, it's a incermental iteration with a loop variable :)
[02:32] <ddaa> sivang: well, sure seems like it's not the Right Way to do it, but it does not make me feel WTF.
[02:33] <sivang> ddaa: hehe
[02:33] <ddaa> Maybe I've been working on version control for too long.
[02:33] <ddaa> There are some pretty massive WTF in this area.
[02:34] <ddaa> e.g. WTF? Using _hashes_ are _ids_?
[02:34] <ddaa> or WTF? committing to branch B makes a checkout of A out of date?
[02:35] <ddaa> or WTF? You can checkout a tree from your own archive and be unable to commit to it?
[02:35] <niemeyer> sivang: Frightening isn't it? 8)
[02:36] <ddaa> or WTF? You cannot parse a log sequence a log entry copy-pasted another log entry?
[02:36] <ddaa> etc. etc. etc.
[02:37] <sivang> OMG
[02:37] <ddaa> respectively: Monotone/git/mercurial, subversion, tla, cvs
[02:44] <mpt> SteveA: ping
[02:44] <bob2> svn appears to not update the tree after you commit
[02:45] <ddaa> bob2: why would it? it's already updated since you made the changes before committing?
[03:05] <salgado> elmo, around?
[03:16] <SteveA> mpt: pong
[03:18] <mpt> SteveA: Did you land mpt@canonical.com/launchpad--spec-tracker--0509? I didn't, but it's showing up on jamesh's page as merged
[03:18] <SteveA> i didn't land it
[03:18] <SteveA> i merged it into my own branch
[03:19] <SteveA> oh
[03:19] <SteveA> spec-tracker
[03:19] <SteveA> yeah, i merged it
[03:19] <mpt> ok, thanks
[03:19] <SteveA> i merged it into my own branch, and merged that into RF
[03:19] <SteveA> i read 'spec-tracker' as 'menus' for some reason
[03:23] <mpt> SteveA: Ok for me to keep adding menus today, and putting them up on PendingReviews if you land the existing ones first?
[03:23] <SteveA> i'll review any menus you add
[03:23] <SteveA> so, you can keep doing them, and put them in my queue on PendingReviews
[03:23] <SteveA> did you see the change i made to main_template.pt ?
[03:23] <SteveA> to put the portlets under the menus?
[03:24] <SteveA> i want to make sure you're happy with the UI on my branch / your branch with mine merged
[03:24] <SteveA> then i'll get my branch merged
[03:24] <SteveA> and reviewed by someone else
[03:25] <ddaa> Eeeeew!
[03:25] <ddaa> newname = os.path.join(destdir, os.path.dirname(filename),
[03:25] <ddaa>                                ",,new.%s.%s" % (random.random(), os.path.basename(filename)))
[03:27] <ddaa> like there is no such thing as mkstemp...
[03:28] <mpt> SteveA: That results in the context menu appearing under the application menu
[03:28] <SteveA> only when we have not yet converted things to use menus
[03:28] <mpt> e.g. http://localhost:8086/distros/ubuntu/+tickets and http://localhost:8086/distros/ubuntu/+bounties
[03:28] <ddaa> (domain specific knowledge tells that it's actually safe, besides appearances)
[03:29] <SteveA> mpt: basically, i don't think it matters if we land all the important menus before thursday
[03:29] <mpt> ok
[03:39] <Kinnison> elmo: ping?
[03:51] <mpt> SteveA: Will you be able to make menu items markup-savvy before Thursday?
[03:54] <SteveA> i'll look into it
[03:54] <SteveA> should be doable
[03:54] <mpt> SteveA: I have a question about permissions now
[03:55] <mpt> for "Change Admin", distrorelease-portlet-actions.pt has tal:condition="context/required:launchpad.Edit"
[03:55] <mpt> why is that .Edit and not .Admin?
[03:55] <SteveA> what permission does the page the link leads to require?
[03:56] <mpt> I can't tell
[03:56] <mpt> it's not in the zcml
[03:56] <mpt> nor in the .pt
[03:57] <SteveA> so, in zcml, is the page declared as public?
[03:58] <SteveA> anyway, i'd say leave it the same, but leave a comment in the menus code querying it
[03:59] <mpt> SteveA: Yes, they both have permission="launchpad.Edit"
[03:59] <SteveA> then, that's why it is launchpad.Edit in the menu
[03:59] <mpt> but it obviously works correctly, because even logged in as myself I can't access the page on production
[03:59] <mpt> Well, I understand why the TAL permission matches the ZCML permission :-)
[04:00] <mpt> but I thought "Edit" meant just "you're logged in as anyone"
[04:03] <SteveA> no
[04:03] <SteveA> launchpad.Edit means "whatever we want 'edit' to mean in this context"
[04:04] <kiko> right
[04:04] <SteveA> launchpad.AnyPerson means "logged in as a Person"
[04:04] <SteveA> although, that'll be changed a bit when i get around to finishing some more security work
[04:04] <Kinnison> elmo: ping?
[04:05] <elmo> Kinnison: yeah?
[04:05] <Kinnison> elmo: I'm having troubles debootstrapping from a CAP published archive
[04:05] <Kinnison> elmo: debootstrap complains that cpp, g++ and gcc can't be found
[04:06] <salgado> elmo, PQM! can you kill it? :)
[04:06] <Kinnison> is there anything special in jackass' apt config for all this?
[04:06] <elmo> err, debian debootstrap or ubuntu debootstrap?
[04:06] <Kinnison> ubuntu
[04:06] <elmo> debian debootstrap uses Build-Essential: yes overrides which ubuntu doesn't have/do
[04:06] <elmo> in that case, no
[04:06] <Kinnison> 0.3.1.4ubuntu1
[04:07] <elmo> salgado: done
[04:07] <salgado> elmo, thanks!
[04:07] <Kinnison> elmo: bizarre. I'll look. We have cpp-4.0 and similar
[04:09] <SteveA> mpt: where do you want to use markup in menus?  just in the link.text, or anywhere else too?
[04:11] <Kinnison> elmo: must be a gina import issue
[04:11] <mpt> SteveA: Yes, just the link text ... There isn't anywhere else for markup to go
[04:11] <Kinnison> elmo: We have gcc-defaults (source) imported
[04:11] <mpt> title= attributes can't contain markup
[04:11] <Kinnison> elmo: but none of its binaries
[04:12] <elmo> ah
[04:12] <elmo> gcc's a good candidate for gina being confused, as it's the most prominent example of binaries-with-a-different-version-than-the-source
[04:12] <Kinnison> aye
[04:12] <SteveA> mpt: okay, i'll do something to make markup work with link text.
[04:13] <Kinnison> Package: gcc
[04:13] <Kinnison> Version: 4:3.3.5-1
[04:13] <Kinnison> Source: gcc-defaults (1.19)
[04:13] <Kinnison> yeesh
[04:13] <mpt> thanks SteveA
[04:13] <Kinnison> very different indeed
[04:21] <Kinnison> elmo: yeah, this looks like a "vastly different version -> gina confused" error
[04:22] <elmo> Kinnison: btw, not being funny, but have you tried plain old diff of CAP vs. OldSKOOL Packages + Sources yet?
[04:23] <Kinnison> Not yet 'cos I wasn't sure it'd work right. does apt-ftparchive give a stable ordering?
[04:23] <Kinnison> I guess a grep of Package: | sort => diff would give a good start
[04:23] <elmo> no, we do that by enforcing stable ordering in jenna
[04:24] <elmo> (apparently sorting was too expensive for apt-ftparchive to implement ... ?!)
[04:24] <Kinnison> Oh right
[04:24] <Kinnison> so I should sort the overrides list by package name first?
[04:24] <elmo> I would, yeah
[04:25] <Kinnison> Okay, I'll drop that in at some point
[04:27] <bradb> mpt: :(
[04:27] <bradb> mpt: the sab gave specific orders not to touch that table from now on before 1.0 either
[04:28] <SteveA> mpt: does your text editor show trailing whitespace?
[04:29] <ddaa> emacs: M-x set-variable ENTER show-trailing-whitespace ENTER t ENTER
[04:31] <ddaa> causality?
[04:31] <mpt> SteveA: no
[04:31] <SteveA> mpt: what editor do you use?
[04:31] <mpt> gedit
[04:32] <mpt> Why do you ask?
[04:32] <SteveA> a programmers' editor should show trailing whitespace, so you don't check it in ;-)
[04:32] <mpt> oh
[04:34] <SteveA> also, an editor should show you when you go over 80 chars on a line
[04:35] <mpt> Yes, my window's 80 characters wide, so that's easy
[04:37] <SteveA> well, i just shortened a long line you checked in
[04:37] <SteveA> i'm doing a pre-review of our menus landing
[04:38] <mpt> I just finished adding distrorelease menus
[04:38] <Kinnison> mpt: ooh, for soyuz?
[04:38] <mpt> now I'm doing pagetests
[04:38] <mpt> Kinnison: If /distros/ubunty/hoary is "for soyuz", then sure :-)
[04:39] <mpt> ubuntu, even
[04:39] <Kinnison> mpt: shiny. Although be aware that /distros is being reworked by sabdfl
[04:39] <mpt> Ubuntu -- the endlessly misspelled OS.
[04:39] <mpt> Kinnison: Lemme guess, we're going to have /distro/foo/bar?
[04:39] <Kinnison> Not a clue
[04:39] <Kinnison> All I know is that at the end of last week he promised me a shiny new UI for soyuz
[04:40] <Kinnison> and then he went on holiday
[04:40] <kiko> salgado, you're live
[04:40] <mpt> This is Launchpad, it can't be shiny
[04:40] <salgado> kiko, just saw that. :)
[04:40] <SteveA> mpt: when you add a closing bracket of some kind on a new line, do it one level of indentation in from where you've been doing it
[04:40] <SteveA> so, 
[04:40] <SteveA> import ... (
[04:40] <SteveA>    foo, bar, baz
[04:40] <SteveA>     )
[04:40] <SteveA> well, that was a space too far
[04:40] <SteveA> but you get the idea
[04:41] <Kinnison> I thought we used 4space indent
[04:41] <mpt> SteveA: Why?
[04:41] <Kinnison> mpt: style guide
[04:42] <mpt> Ok, I'll do that in Python, but I won't do it in HTML/TAL, it would just make debugging unnecessarily difficult
[04:42] <Kinnison> spiv: am I okay to merge publishing--2 ?
[04:42] <spiv> Kinnison: Yep.
[04:42] <Kinnison> spiv: thanks dude
[04:43] <spiv> I haven't looked at the changes you said you made because they weren't mirrored, but they weren't huge and they were what I asked for, so I'm comfortable trusting you :)
[04:44] <SteveA> mpt: it makes collapsing the code work properly in such editors, and also is a consistent style
[04:45] <SteveA> mpt: also... don't use html markup in the text of links now.  instead, add an XXX comment with the desired markup, and use a markup-free alternative.
[04:45] <SteveA> that way, things will work, and it is easy to grep the source for things that need to be changed when we have markup
[04:46] <SteveA> the adding of markup will use a different API than you're using to add regular text 
[04:46] <SteveA> so, it needs to be obvious where we have to change things.
[04:47] <mpt> ok
[04:48] <kiko> hey ddaa 
[04:48] <kiko> say you have time to talk to me
[04:50] <mpt> FAILED (errors=173)
[04:50] <ddaa> kiko: in a few minutes please
[04:51] <kiko> ddaa, wunderbar
[04:51] <SteveA> mpt: update hct and sourcerer and all that
[04:52] <salgado> kiko, something seems to be wrong in the redirects. try logging in
[04:52] <SteveA> salgado: wrong where?
[04:53] <kiko> is PQM jammed? elmo?
[04:53] <kiko> I see 6 scripts there...
[04:53] <salgado> SteveA, here I'm getting redirected to the old wiki's front page after logging in
[04:53] <Kinnison> I see 5
[04:53] <Kinnison> kiko: There *was* one from stu, from about 8 hours ago, but it's gone now
[04:53] <salgado> kiko, it was
[04:54] <SteveA> salgado:  you need to give more context, like maybe some specific urls
[04:54] <SteveA> salgado: logging in to what?
[04:54] <kiko> shipit
[04:54] <salgado> SteveA, shipit
[04:54] <kiko> ah
[04:54] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Don't store MIME email epilogue and preambles (patch-2440: stuart.bishop@canonical.com)
[04:54] <elmo> kiko: I killed it a couple of hours ago?
[04:54] <SteveA> salgado: works for me
[04:54] <SteveA> salgado: probably a temporary DNS issue
[04:55] <salgado> I hope so
[04:55] <kiko> elmo, maybe I'm seeing double -- I'll complain if it happens again
[04:55] <salgado> SteveA, yes, it works now
[04:55] <kiko> salgado, it's beautiful
[04:56] <SteveA> elmo: what will happen about the certificate on shipit?
[04:56] <salgado> and it has a lot of requests already
[04:56] <elmo> SteveA: I can buy one, if it's important
[04:56] <SteveA> seems slightly important to me.  i wonder what silbs thinks?
[04:57] <kiko> it's very important IMO
[04:57] <elmo> well, it'll mean using an IP for it, which is annoying
[04:57] <kiko> yes, that's unavoidable
[04:59] <ddaa> kiko: howzitgoin'?
[04:59] <kiko> ddaa, spiffy but I need some bazzin
[05:00] <kiko> should we use #bazaar or..?
[05:00] <ddaa> would make sense
[05:03] <SteveA> any reviewers around to do a simple code review?
[05:04] <kiko> yes
[05:06] <SteveA> dude!
[05:06] <SteveA> i'll send you a diff
[05:08] <SteveA> kiko: diff mailed
[05:08] <kiko> thanks
[05:24] <kiko> SteveA, you said it was simple?
[05:24] <SteveA> it is
[05:24] <SteveA> just long
[05:25] <kiko> no such thing!
[05:35] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Ensure specialized log handlers work for the root logger too (patch-2441: stuart.bishop@canonical.com)
[05:51] <Seveas> How come I can't edit my own hackergotchi on lp?
[05:55] <Seveas> Hmm, and wouldn't it be a bug of launchpad lists the teams someone is member of and then 'says' "$person is not an active member of any launcpad teams
[05:56] <kiko> Seveas, no answer for the first, it's a bug for the second, and salgado will fix it AND ADD A TEST 
[05:57] <Seveas> ok, just trying to help by reporting :)
[05:57] <salgado> kiko, the second is on its way to pqm. it was caused because someone reverted my changes
[05:58] <salgado> when solving conflicts
[05:58] <SteveA> baz smash?
[05:59] <kiko> salgado, tests added to ensure it's unsmashed for good?
[06:00] <salgado> I can't easily add a test to check if something *is not* in the returning page
[06:00] <salgado> in other words, this is tricky to test
[06:00] <kiko> can't you test the view instead?
[06:00] <SteveA> sure you can
[06:01] <SteveA> the output of html() can be put into a variable
[06:01] <SteveA> and you use 'text' in variable
[06:01] <kiko> or 'text' not in variable
[06:01] <SteveA> indeed
[06:01] <SteveA> and then you can still use >>> variable
[06:01] <SteveA> to do normal pagetest style matching later
[06:02] <mpt> foo not in bar
[06:02] <mpt> even I knew that!
[06:02] <jbailey> bradb: Around?
[06:02] <bradb> jbailey: yeah
[06:02] <salgado> I'd prefer people were more careful when solving conflicts
[06:03] <jbailey> bradb: I know I asked you before, but I don't remember the answer.  Does Malone offer an xml-rpc interface for reporting bugs?  At some point I have to point Ubuntu bug reporting tools to Malone, and I'm curious the Right Way of doing it.
[06:03] <salgado> instead of having to write tests like this for everything
[06:03] <bradb> jbailey: no xml-rpc yet, and possibly not for a while
[06:03] <kiko> salgado, unfortunately, that we can't fix with code 
[06:04] <jbailey> bradb: I think it's not a big deal for Breezy, but I suspect it will be critical for Dapper.
[06:04] <salgado> and I don't think we can fix this either. I can add a test for an explicit tal:condition that was removed when solving conflicts, but what about the others?
[06:04] <jbailey> bradb: (And sadly will need to be an interface that can live for 5 years)
[06:04] <jbailey> bradb: Is there anything I can do to help plan for that?
[06:05] <bradb> jbailey: we can probably BOF it at UBZ
[06:06] <bradb> jbailey: An API that will last for five years though? Heh.
[06:06] <jbailey> bradb: Yeah, sucky, but it has to be.
[06:06] <jbailey> That's the lifetime of that release.
[06:06] <bradb> Some effort may need to be focussed on how to deal with changes in the API, because this early on, it will happen.
[06:07] <jbailey> And honestly, I'd be surprised if it wasn't extended to sometime longer than that for specialised applications.
[06:07] <jbailey> Long lived releases in telcom often are 10years.
[06:07] <bradb> Sure, I can see the reasoning. I think planning in advance for the fact that the API will change though would be a good idea.
[06:08] <Kinnison> a five year api isn't hard to support so long as it doesn't contain security holes
[06:08] <jbailey> bradb: Yup.
[06:08] <jbailey> Even if it's just a "Her'es the version for the first throw-away API"
[06:08] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/malone/bugs/2425. (patch-2442: guilherme.salgado@canonical.com)
[06:08] <Kinnison> the buildds negotiate their api at runtime
[06:11] <jbailey> Kinnison: Right, but you can generally expect that a buildd isn't older than a certain point.
[06:12] <Kinnison> jbailey: indeed
[06:13] <Kinnison> Either make every api call take a version, or allow for a negotiation of capabilities during the beginning of the connection or something
[06:13] <Kinnison> gcc-defaults' binary packages imported
[06:15] <mpt> Kinnison: You mean something like the remote app asking Malone, "What fields does Malone want this month, and which of them are compulsory"?
[06:16] <Kinnison> mpt: aye
[06:16] <SteveA> for xmlrpc, just make the path to the service include an API version number
[06:16] <Kinnison> mpt: If the remote app can build its UI with a few XML-RPC calls to malone then we change it over time
[06:16] <Kinnison> mpt: E.g. what fields, what are compulsory, a description of the fields, etc can all be got over XML-RPC
[06:16] <SteveA> sounds rather complex
[06:17] <Kinnison> resilient though
[06:17] <SteveA> simpler to have a fixed API at a particular version
[06:17] <SteveA> and to be able to change versions
[06:17] <Kinnison> but if malone grows a new compulsory field it makes that API obsolete/unusable
[06:17] <SteveA> malone cannot grow a new compulsory field in that case
[06:18] <Kinnison> hmm
[06:18] <SteveA> or, if it does, and it is that important, then the client apps will have to say "get an updated version of me"
[06:18] <jbailey> A dedicated URL for it makes the most sense.
[06:18] <jbailey> Especially if you know from the outset that it's not going to be right, and in fact could be dramatically flawed.
[06:19] <jbailey> And define one of the response codes to be "I'm sorry.  We no longer support Dapper" for when dapper expires. =)
[06:20] <jbailey> After 5 years, all the calls can be stubbed to that. =)
[06:20] <mpt> At the moment I think it'll be more likely Malone loses compulsory fields than gains them :-)
[06:24] <Kinnison> anyone ever seen debootstrap say something like:
[06:25] <Kinnison> E: Couldn't find these debs: 190227458
[06:34] <bradb> the word of the day is: optional
[06:35] <kiko-fud> bradb, you fought for that :-P though since they are not bound, just knock off the not null :-P
[06:35] <bradb> kiko-fud: dude, what I fought for is nothing like what attachments UI/implementation is :)
[06:37] <kiko-fud> we lost that battle, don't you remember?
[06:37] <bradb> I think it would make more sense for a comment to be required if the attachment widget was part of the standard comment form
[06:38] <bradb> kiko-fud: i'm reminded of that every day :)
[06:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Ensure specialized log handlers work for the root logger too (patch-2443)
[06:48] <SteveA> kiko-fud, mpt, salgado-lunch: i replied to kiko's code review
[07:05] <ddaa> holy crap :(
[07:05] <ddaa> spent the whole day fixing my code to actually do what SVN means
[07:06] <ddaa> only to realise that it just makes my work harder in the end, since SVN since to provide no mean to diff two different paths!
[07:06] <ddaa> *sigh*
[07:09] <Kinnison> can entries be removed from pqm's queue without being special?
[07:09] <ddaa> most probably, no
[07:10] <Kinnison> poo
[07:12] <SteveA> Kinnison: you can temporarily move your archive mirror ;-)
[07:15] <Kinnison> no ta
[07:21] <Kinnison> ciao all
[07:23] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  externalsystem.py to properly handle Bugzilla < 2.17.1 (bz:bug_status used to be bz:status) (patch-2444: christian.reis@canonical.com)
[07:23] <bradb> BjornT: I responded to the URL changes review.
[07:24] <BjornT> bradb: cool, i'll take a look at it soon
[07:48] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: DI support and Release file support. r=spiv (patch-2445: daniel.silverstone@canonical.com)
[08:00] <jordi> hi
[08:00] <jordi> I'll be ready for the meeting in ten minutes
[08:00] <jordi> I've had a network problem and haven't been able to leave before
[08:01] <jordi> see you rsn
[08:01] <jordi> (for those intereste, we're supossed to discuss launchpad/rosetta advocacy)
[08:11] <SteveA> kiko-fud: i'm not going to be getting email for a while -- some problem at the isp who deals with my email.
[08:19] <kiko> jordi, ahoy
[08:19] <jordi> ok
[08:19] <jordi> I'm here.
[08:20] <jordi> so, I wonder if there's enough people to do the meeting today or if we should postpone.
[08:20] <jordi> jblack: ping
[08:20] <kiko> I'm here but have a busted finger
[08:20] <jordi> The key points of this are, I think, these:
[08:21] <jordi> Rosetta advocacy: 1) How to do it. 2) Who should we target first. 3) Are we ready to do it *now*?
[08:21] <jordi> kiko: if you think we need some other people to discss this, I'm happy to postpone or whatever.
[08:22] <jordi> What happened to your finger?
[08:22] <kiko> mountain bike crash
[08:22] <jordi> aw
[08:22] <kiko> carlos would be nice
[08:23] <kiko> is he not around?
[08:24] <jordi> he's marked away in jabber.
[08:25] <kiko> sucks
[08:25] <jordi> hmm. should we try some other time?
[08:26] <kiko> jordi, yeah, probably. when is carlos available? he should be around..
[08:27] <kiko> or hmm, maybe too late
[08:27] <kiko> SteveA, I'm okay with your comments, there was nothing blocking landing there.
[08:27] <kiko> mpt can fix up the text later
[08:27] <SteveA> kiko: cool, thanks
[08:27] <kiko> matsubara, bug 2112 is a dupe 
[08:28] <kiko> matsubara, I suspect bug 2200 is too
[08:28] <jordi> kiko, SteveA: tell me when's a good moment for this meeting.
[08:28] <matsubara> i've seen. Neuman reported it at #1244
[08:28] <SteveA> what meeting is this?
[08:28] <jordi> any evening next week is suitable I think.
[08:28] <jordi> SteveA: rosetta/lp advocacy.
[08:28] <SteveA> oh
[08:28] <kiko> matsubara, that bug is older, but yeah, he added a comment
[08:29] <kiko> salgado, do you have time to talk a bit in 30m?
[08:29] <SteveA> tomorrow is good for me if it isn't so late.  i have a meeting at 1700 UTC tomorrow.
[08:29] <kiko> same here, I'm flexible
[08:30] <kiko> I think carlos should be around for it
[08:30] <salgado> kiko, yes, sure
[08:30] <jordi> I think I have something big tomorrow evening.
[08:30] <jordi> oh, yes. I have a meeting at the govt. offices.
[08:30] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Small fix so people accessing /shipit/myrequest instead of going first to /shipit and logging in get a 'Forbidden' page instead of a 'System Error' one. (patch-2446: guilherme.salgado@canonical.com)
[08:31] <jordi> and I wanted to stay at office just in case something last minute pops up, we release our second LliureX version tomorrow.
[08:31] <jordi> thursday?
[08:32] <SteveA> i can do thursday although i already have two meetings on that day.
[08:34] <SteveA> so, yes, provided it isn't too late on thursday
[08:35] <jordi> what's late?
[08:36] <SteveA> 1700 UTC is getting late
[08:38] <jordi> depending on how long you think it'll get, it could be ok for me
[08:38] <jordi> oh, utc.
[08:38] <jordi> that's super for me
[08:38] <SteveA> so, if we finish by then, i'll be happy
[08:40] <jordi> ok.
[08:40] <jordi> let's set starting time 15:30, or 15:00 if you think 1.5h won't be enough
[08:43] <carlos> kiko, jordi I'm around
[08:43] <carlos> what's the subject of the meeting?
[08:44] <jordi> carlos: promoting rosetta
[08:44] <jordi> or, "jordi spams free software people"
[08:44] <carlos> ;-)
[08:44] <jordi> carlos: is thursday ok?
[08:44] <carlos> here or #cm?
[08:44] <carlos> oh, I thought it was now
[08:44] <carlos> jordi, what time
[08:44] <carlos> ?
[08:45] <jordi> 15:00 or 15:30 utc, depending on how long you guys think it'll take.
[08:45] <jordi> it's about "when to start doing it", "who to target" and "how to do it"
[08:45] <jordi> probably talkingh about the "worst annoyances for users in rosetta" too.
[08:46] <carlos> jordi, it's ok for me
[08:47] <jordi> ok
[08:47] <carlos> kiko, I fixed the problem with the extra space
[08:47] <carlos> kiko, with tests, I will prepare a new languagepack tonight
[08:48] <kiko> carlos, really? was it in the wrapping code?
[08:48] <carlos> kiko, yes
[08:48] <carlos> kiko, we add it by default
[08:48] <carlos> kiko, very weird
[08:49] <carlos> I rewrote the wrapping code
[08:50] <salgado> BjornT, ping?
[08:51] <kiko> carlos, that code sucked, too :)
[08:51] <carlos> kiko, that code is part of the po parser
[08:51] <carlos> kiko, all that code sucks a lot
[08:52] <kiko> carlos, so no more whitespace bustage? ;-) this is the fifth fix!
[08:53] <carlos> kiko, this problem was also a whitespace problem, but unrelated to the previous one
[08:54] <carlos> this time it was a bug in our code not in our db
[08:54] <kiko> doh!
[08:54] <kiko> yeah, I know, but it's still whitespace :)
[08:54] <kiko> (I'm happy it only happens on output though)
[08:54] <kiko> carlos, your branch is getting fatter eh? :-)
[08:54] <kiko> https://staging.ubuntu.com/products/pyopenssl/+packages
[08:54] <kiko> contains a broken link
[08:55] <carlos> kiko, yeah, that branch starts being huge
[08:57] <kiko> carlos, I'll review if we confirm we're good tomorrow
[08:57] <carlos> kiko, there are other minor issues that martin raised
[08:57] <kiko> salgado, is this a dupe? https://launchpad.net/malone/bugs/2425
[08:57] <kiko> 
[08:57] <carlos> but will try to have it fixed between today and tomorrow before you wake up
[08:58] <kiko> carlos, yeah -- has he managed to do the msgmerg?
[08:58] <carlos> no idea
[08:58] <salgado> kiko, only half of it
[09:00] <kiko> salgado, hoho
[09:00] <kiko> jordi, as for your gajim branch, I don't know how do deal with that. ddaa?
[09:01] <kiko> matsubara!
[09:01] <kiko> salgado, didn't you just fix https://launchpad.net/malone/bugs/2241
[09:02] <matsubara> i'm back
[09:03] <salgado> kiko, I fixed it yesterday, IIRC. now I fixed 2425 --make sure you don't get the "Log me in after ..." checkbox if you're already logged in
[09:03] <kiko> okay
[09:03] <salgado> kiko, oooops, misread the bug report
[09:03] <salgado> kiko, I fixed 2241 last week (thursday, IIRC)
[09:04] <salgado> OMG. I haven't fixed it
[09:04] <kiko> what did you just land into PQM then?
[09:04] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix https://launchpad.net/malone/bugs/2435 (patch-2447: guilherme.salgado@canonical.com)
[09:04] <salgado> go, dilys
[09:05] <kiko> salgado, can you please copy the bug summary when landing? it's terrible for me, writing the report
[09:05] <SteveA> mpt: if you merge from my branch, links can now contain markup.  you need to use a special thing for ones that do contain markup
[09:05] <SteveA> this is in pqm's queue
[09:06] <mpt> ok, thanks
[09:06] <kiko> salgado: Small fix so people accessing /shipit/myrequest instead of going
[09:06] <kiko> +first to /shipit and logging in get a 'Forbidden' page instead of a 'System
[09:06] <kiko> +Error' one.
[09:06] <kiko> isn't that bug 2241?
[09:07] <salgado> kiko, no, that's a bug I introduced yesterday, when fixing the one stub reported
[09:07] <mpt> hmm
[09:08] <mpt> SteveA: I want to customize the title of an AddForm based on the context ... Is there any way to do that short of making a mini-template that uses addform?
[09:08] <kiko> salgado, both bugs seem to be about the same thing..
[09:08] <kiko> mpt, nope.
[09:08] <mpt> okie dokie
[09:09] <salgado> kiko, in https://launchpad.net/malone/bugs/2241 mpt says that we should not return the 'Forbidden' page if you're not logged in
[09:10] <salgado> kiko, but right now you won't get the 'Forbidden' if you go to /myrequest. you'll get a 'System Error'
[09:10] <kiko> I see, I see
[09:10] <salgado> that's what I fixed
[09:13] <SteveA> mpt: the main-template used to have a slot for the content of <title> that i had explicitly inserted just for this case. 
[09:14] <SteveA> someone removed it.
[09:14] <SteveA> another way to achieve the effect is to use a function in pagetitles
[09:14] <SteveA> that uses view.pagetitle
[09:15] <SteveA> def launchpad_addform(context, view):
[09:15] <SteveA>     # Returning None results in the default Launchpad page title being used.
[09:15] <SteveA>     return getattr(view, 'page_title', None)
[09:15] <SteveA> 
[09:15] <SteveA> aha
[09:15] <SteveA> i see it is already there
[09:15] <SteveA> so, the way to do it is to set page_title on your view class.
[09:15] <SteveA> bradb: take note
[09:16] <kiko> beautiful
[09:17] <bradb> SteveA: ah, nice
[09:18] <bradb> I've found the need to create custom templates for each page almost all the time anyway
[09:19] <bradb> s/request/requesting/
[09:20] <bradb> probably trying to show a private bug. GRHASDFJ.
[09:20] <ddaa> kiko: importd does not have privs to delete a productseries
[09:20] <ddaa> neither do I
[09:20] <kiko> latestbugs is not privacy-safe?
[09:20] <kiko> ddaa, neither do I
[09:21] <ddaa> I tried this morning :)
[09:21] <bradb> kiko: just a guess so far, but that's my first hunch
[09:21] <ddaa> -> stub or lifeless
[09:21] <ddaa> I sort of recall this sort of things was supposed not to be done
[09:21] <ddaa> that product and series should be made "inactive" and not deleted
[09:21] <kiko> well, duh
[09:22] <kiko> how do you make it inactive?
[09:22] <ddaa> but TBH I find that wrong
[09:23] <ddaa> mh... actually productseries does not have this flag
[09:23] <ddaa> it must be only a product thing
[09:23] <ddaa> (*)w
[09:23] <ddaa> (that's a lightbulb)
[09:23] <ddaa> I can move the offending series to some junk product
[09:23] <kiko> you roxoringor
[09:24] <kiko> Can someone get rid of the "0.8" branch in the gajim product? It was
[09:24] <kiko> ddaa, that's the one
[09:24] <kiko> also 
[09:24] <kiko> there is a product with dupe releases
[09:24] <kiko> has that been fixed, ddaa?
[09:24] <ddaa> kiko: what do you mean, dupe?
[09:25] <kiko> two series, same release name in each series, boom
[09:25] <kiko> https://launchpad.net/malone/bugs/2390
[09:25] <ddaa> hu... dunno about releases
[09:26] <ddaa> I have to leave, I'll just move gaijim out of the way, if you want me to have a try at the other problem assign it to me, I'll assign it back to you if I'm unsuccessful
[09:26] <kiko> okay, neat
[09:30] <ddaa> bah
[09:30] <ddaa> $series/+review is borken
[09:30] <kiko> ddaa, can you file a bug so I can sic matsubara on it tomorrow?
[09:31] <ddaa> kiko: I'm really out of time for today
[09:31] <kiko> okay, tomorrow then
[09:34] <ddaa> moved gajim/0.8 to products/duplicates
[09:34] <kiko> roxor
[09:34] <ddaa> for kicks: try here https://launchpad.net/products/duplicates/+series/0.8/+review to post the form
[09:35] <ddaa> (no need to change the values)
[09:35] <ddaa> it claims invalid value for some reason
[09:35] <ddaa> that's the bug
[09:36] <kiko> matsubara, can you file a bug for ddaa?
[09:36] <ddaa> note, you have to be a launchpad admin before even trying to use +review
[09:38] <kiko> I know :)
[09:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Fix gina to use apt-pkg's idea of source version (patch-2448: daniel.silverstone@canonical.com)
[09:42] <carlos> I'm having some problems running a launchpad script on mawson 
[09:42] <carlos> https://chinstrap.ubuntu.com/~dsilvers/paste/fileCMgN9E.html
[09:43] <carlos> it's related to GPG
[09:43] <carlos> any help?
[09:43] <carlos> I just update all source code
[09:43] <kiko> carlos, you need to update your trees
[09:43] <kiko> make clean
[09:43] <kiko> make build
[09:43] <kiko> try again
[09:43] <carlos> oh
[09:43] <carlos> I missed that part
[09:43] <carlos> ok
[09:43] <carlos> let's try...
[09:44] <carlos> kiko, thanks
[10:22] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  fix http://www.google.co.nz/search?q=site:launchpad.net+%22log+in+or+register+with+launchpad%22&filter=0 (patch-2449: mpt@canonical.com)
[10:26] <kiko> salgado, should teams be able to register GPG keys?!
[10:26] <salgado> kiko, no
[10:27] <kiko> https://launchpad.net/people/shipit-admins/
[10:27] <salgado> kiko, I fixed that in one of my [trivial]  changes today
[10:27] <kiko> ah, cool
[10:28] <salgado> in case you're talking about the "GPG Keys: None registered" text
[10:28] <kiko> yes
[10:28] <kiko> salgado, I'm curious. I asked to join the shipit-admins team, but nothing happened. Is there some weird case involving administrators?
[10:29] <bradb> kiko: do we add LP BOF ideas here: https://wiki.ubuntu.com/UbuntuBelowZero/BOFs or do we have a separate page for that?
[10:29] <kiko> I haven't really thought about that, bradb 
[10:30] <kiko> so do whichever feels best and we'll deal with it later
[10:30] <salgado> kiko, all administrators of shipit-admins should receive an email saying you want to join
[10:30] <mpt> I suggest the Ubuntu wiki page, bradb
[10:30] <mpt> because they'll be scheduled together
[10:30] <kiko> salgado, is there no feedback of what I did at all?
[10:31] <salgado> kiko, oh, sorry
[10:31] <salgado> you can't join that team
[10:31] <salgado> nobody can
[10:31] <salgado> dammit. I had tests for this
[10:32] <kiko> salgado, bug 2450.
[10:32] <salgado> you should get a message saying you can't join and explaining why
[10:32] <kiko> salgado, not a big deal, but a bug even so
[10:36] <bradb> Right, I'll put it on the page at the link above for now then.
[10:40] <carlos> see you!
[10:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  tidy up bug reporting form headers (fix bug 1919) (patch-2450)
[11:03] <sivang> can I now use only malone to open bugs in main in ubuntu?
[11:04] <kiko> sivang, unfortunately not yet
[11:09] <sivang> kiko: ah I see, but on launchpad is ok?
[11:11] <kiko> of course
[11:11] <kiko> launchpad's official tracker is malone
[11:11] <kiko> speaking of which..
[11:16] <sivang> yes?
[11:18] <sivang> kiko: I uploaded a key, and signed it, and signed the CoC, how do I enable my ubuntu.com email?
[11:18] <sivang> (already approved as Ubuntite)
[11:51] <Nafallo> kiko_diskless: what are you doing? :-)
[11:52] <kiko_diskless> using the diskless system to find baz some disk space
[11:52] <Nafallo> :-P
[11:53] <Nafallo> kiko_diskless: you got some messages from nkour on kiko ;-)
[11:53] <kiko_diskless> what did nkour want with poor me?
[11:53] <Nafallo>  <nkour> https://launchpad.net/products/gajim/+series/main/+pots/gajim HEAD must die
[11:54] <Nafallo>  <nkour> we have 2 places, and Basque transl first started in  https://launchpad.net/distros/ubuntu/breezy/+sources/gajim/+pots/gajim then restsarted in HEAD
 since you're can do it, please make HEAD die and before move all the po from HEAD to 0.8 and ask to OVERWRITE
 that will be less headache for everyone and for you
[11:54] <Nafallo> :-P
[11:54] <kiko_diskless> I am not sure how to do this, but..
[11:56] <Nafallo> we should have something that keeps everything in sync sometime in the future I hope? ;-)
[11:56] <kiko_diskless> blame carlos!
[11:56] <Nafallo> hehe
[11:56] <Nafallo> he's not here ;-)
[11:57] <Nafallo> can you forward it? I'm really not that much in to the code to answer this guys questions :-)
[11:57] <kiko_diskless> I'll try
[11:58] <Nafallo> thanx :-)