[02:04] <^3OKATA^> ima le nekoj od MAKEDONIJA!!!
[02:09] <jsgotangco> err?
[02:09] <^3OKATA^> ?
[04:10] <mpt> jamesh, ping
[04:10] <jamesh> mpt: pong
[04:12] <mpt> jamesh, what would be the python equivalent of "context/required:launchpad.Edit"?
[04:12] <mpt> "python: ..."
[04:12] <mpt> (because I need to test something else simultaneously)
[04:12] <mpt> there don't seem to be any other examples of doing that in the codebase yet
[04:13] <jamesh> from canonical.launchpad.helpers import check_permission
[04:13] <jamesh> check_permission('launchpad.Edit', context)
[04:13] <jamesh> however, it may be easier to go a different route using tal:define
[04:13] <mpt> hmm, that's not going to work inside a tal:condition, because there's no line breaks
[04:13] <jamesh> something like this:
[04:14] <mpt> or I could just use nested tal:blocks
[04:14] <jamesh> <xxx tal:define="can_edit context/required:launchpad.Edit" tal:condition="python:can_edit or $OTHERCONDITION">...</xxx>
[04:14] <mdz_> kiko-zzz: zzz indeed
[04:14] <mpt> ah, nifty
[04:14] <mpt> thanks jamesh
[04:15] <stub> You expect to get that past review?
[04:16] <stub> <xxx tal:condition="context/required:launchpad.Edit"><xxx tal:condition="other">...</xxx></xxx> is an AND
[04:17] <stub> <xxx tal:condition="context/required:launchpad.Edit|other">...</xxx> is an OR. No Python needed.
[04:17] <mpt> yes, that's what I meant by "nested tal:blocks"
[04:17] <mpt> it's messier
[04:17] <mpt> is it faster?
[04:18] <stub> Probably slower. But avoids using Python in the TAL which is pretty much a red flag for I-need-to-be-refactored.
[04:18] <mpt> So what's the better solution?
[04:18] <mpt> a function in the browser class?
[04:19] <stub> Yes.
[04:19] <mpt> oh!
[04:19] <mpt> I just found another bug in this file that makes this moot
[04:19] <stub> :-)
[04:19] <mpt> I do need the nested blocks anyway
[04:19] <mpt> they won't be so directly nested
[04:22] <stub> Any sprints on this week or next? I'm wondering if these spec tracker patches need to be rolled out.
[04:24] <stub> jamesh: Do you think it worth stopping error reports being generated on Saturday and Sunday, and make Mondays report cover three days?
[04:25] <jamesh> stub: might be worth it.  Should see what matsubara would prefer
[04:25] <ruffneck> shuttle is launched today
[04:35] <mpt> stub, all products now have at least one product series, correct?
[04:35] <stub> mebbe ;)
[04:36] <mpt> I think one's created automatically when the product is, and that was retroactively done to existing products with no series
[04:37] <mpt> in which case I'm looking at dead code
[04:38] <mpt> that I wrote myself
[04:38] <stub> We have 254 products without productseries at the moment, so if the code was updated the data wasn't fully. Or we have bugs allowing product creation without the product series.
[04:38] <stub> IIRC, this would be a bug.
[04:39] <stub> As I think it was decided that every product would have >= 1 product series.
[04:39] <mpt> I guess I'll leave this "if there are no series" code in here for now then
[04:40] <mpt> stub, you reporting a bug on that, or shall I?
[04:40] <acesuares> hi all
[04:40] <stub> mpt: I'll let you if you are volunteering ;)
[04:42] <mpt> ok
[04:43] <mpt> bug 51799
[04:43] <Ubugtu> Malone bug 51799 in launchpad "There are still products without series" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51799
[04:46] <jamesh> stub: the product series creation is done in browser/product.py, so it would be quite possible for other code to create products without a product series
[04:46] <stub> Bleh
[05:02] <mpt> bah
[05:02] <mpt> What's name12's password?
[05:04] <mpt> I know Foo Bar's, and Mark's, and Carlos's, and no-priv's, but not name12's, which is the one I need
[05:08] <jamesh> mpt: test
[05:09] <mpt> doesn't work, jamesh
[05:10] <mpt> unless the e-mail address is something other than name12@canonical.com?
[05:12] <jamesh> test@canonical.com
[05:12] <mpt> oh!
[05:12] <mpt> name12 is *that* guy!
[05:12] <mpt> thanks jamesh
[05:12] <mpt> no wonder I couldn't find "name12@" in the sampledata
[05:12] <jamesh> we could really use some better short names in the sample data
[05:27] <stub> Yer. But the fallout in the test suite will be monstrous so nobody has bothered ;)
[05:32] <mpt> Who is user_browser, really?
[05:32] <mpt> Is it name12?
[05:33] <jamesh> yeah
[05:33] <mpt> dangit :-)
[05:33] <mpt> name12 is the owner of /products/bazaar
[06:38] <jamesh> spiv: you marked my jamesh/launchpad/bug-45987 branch as merge-conditional, but didn't see any review.  Does that mean that there isn't anything you want me to fix?
[07:06] <spiv> jamesh: it means I updated the wrong branch on the wiki page, I meant to update carlos' one.
[07:07] <jamesh> okay
[07:17] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 20 mins.
[07:17] <jamesh> will be good to see how the branch puller and scanner modifications improve things
[07:30] <stub> soyuz publishing runs are taking > 30 mins again :-(
[07:37] <stub> jamesh: Do you still need access to the production database from macquarie?
[07:39] <jamesh> stub: Not right now.  I do have a script to do zope3 spec metadata import that may get run in the future, but I guess I could ask you to run it
[07:39] <jamesh> the bugzilla import is complete
[08:00] <stub> SteveA: Still getting that exception we saw last week on Production
[08:01] <stub> And we can't roll back this time since we pushed out database changes
[08:05] <sivang> morning
[08:07] <sivang> ah, launchpad is taking a massage again, well I hope it's enjoying itself :-)
[08:10] <cprov> stub: are you rolling an prod copy to drescher as well ?
[08:10] <stub> cprov: done
[08:11] <cprov> stub: 3737 ?
[08:12] <stub> cprov: yes
[08:12] <stub> HEAD
[08:12] <cprov> stub: good, thank you 
[08:15] <cprov> stub: could you please check lp-errors ML drescher is facing locale issues :(
[08:16] <stub> Looks like we need 'export LANG=C' in a few choice places. Can you have a look?
[08:16] <cprov> stub: actually was me and my damm pt_BR
[08:17] <cprov> stub: I can export it in the bashrc of LP relevant users, thanks
[08:18] <cprov> stub: additionally looks like LANG isn't enough, we need LC_ALL=C
[08:19] <stub> The servers tend to be setup for locale of en_GB, but none of the locale files are installed so things blow up if you make he wrong Python calls without overriding the locale :-(
[08:19] <stub> Or something like that.
[08:21] <cprov> stub: makes sense, will set LC_ALL it won't hurt
[08:21] <carlos> morning
[08:25] <cprov> carlos: good morning
[08:25] <Calvin> hello, how long is the website planning to be down?
[08:26] <sivang> morning Calvin 
[08:26] <Calvin> it's almost good night where I live
[08:26] <sivang> wops ;) morning carlos 
[08:26] <sivang> Calvin: sorry, wrong nice completion
[08:26] <sivang> s/nice/nick
[08:26] <Calvin> is ok
[08:27] <Calvin> I order a free cd (I hope its free) but I entered a wrong address...
[08:27] <Calvin> but the website is "Launchpad is offline at the moment for maintenance. It should be back, better than ever, soon. Thanks for your patience. 
[08:27] <Calvin> "
[08:28] <Calvin> so I thought I'd stop by and see how things are going
[08:28] <Calvin> it's back up!
[08:29] <Calvin> nevermind... I think I got it all sorted out now
[08:29] <carlos> stub: Hi, did you add the DB restriction you removed to do the migration data for Rosetta?
[08:29] <stub> carlos: Not yet.
[08:30] <carlos> ok, just asking to be sure that you don't forget it ;-)
[08:30] <stub> carlos: Still need to rerun the data migration
[08:30] <carlos> ok
[08:30] <carlos> thanks
[08:30] <stub> Launchpad is back up
[08:33] <Calvin> yep...
[08:35] <robey> launchpad question: how do i add another maintainer to a product?
[08:36] <stub> Create a team and set the maintainer to the team.
[08:40] <robey> stub: thanks... one more dumb question: how do i set the maintainer?
[08:40] <robey> if i click "edit maintainer" on my product, it says i don't have permission to be there
[08:41] <stub> That would be a bug :-(
[08:42] <robey> oh no!
[08:42] <robey> is it because i'm listed as the "registrant" and not "maintainer"?
[08:43] <robey> is there anything i can do to fix it?
[08:43] <stub> Give me the product name and the team name and I can sort it. Please file a bug too.
[08:44] <robey> pycrypto for both
[08:44] <stub> I'm not sure about what permission differences there should be between registrant and maintainer, but what you are trying to do sounds like it should be possible. So I call bug.
[08:45] <stub> Actually... looks like registrant and maintainer are the same anyway.
[08:45] <spiv> If the registrant can't update the registration, that's definitely a bug, I think.
[08:45] <stub> Fixed.
[08:45] <stub> (this case, not Launchpad :) )
[08:47] <robey> thanks!  reported as https://launchpad.net/products/launchpad/+bug/51802
[08:47] <Ubugtu> Malone bug 51802 in launchpad "can't change the maintainer of pycrypto" [Untriaged,Unconfirmed]  
[08:49] <stub> Ta ;)
[08:50] <carlos> spiv: I'm not so sure... If I register a product that is not mine and we transfer the ownership to the actual maintainer, I should not have the same rights that the maintainer...
[08:50] <spiv> carlos: Well, transferring ownership would mean you give up those rights, sure.
[08:51] <carlos> and in that situation, registrant and maintainer will be different
[08:51] <spiv> carlos: But clearly if you register a product, and make a mistake in that registration, you ought to be able to edit everything about it.
[08:51] <spiv> carlos: Also, I think "registrant" and "maintainer" are the same thing atm...
[08:52] <spiv> Although I think we're at least consistently calling it registrant now.
[08:52] <carlos> hmm, in that case, robey should appear too as the maintainer, right?
[08:53] <spiv> carlos: Well, there's no such thing as a product maintainer in launchpad that I know of, just registrants.
[08:53] <spiv> Except that the +reassign link is called "Change Maintainer"
[08:54] <spiv> Try a 'grep -Irni maintainer lib/canonical/launchpad/*/product*' :)
[08:55] <carlos> spiv: yeah, the database just stores an 'owner'
[08:55] <spiv> carlos: source package releases have maintainers in lp, but not upstream products.
[08:57] <robey> is launchpad in bzr? :)
[08:57] <carlos> spiv: right
[08:58] <spiv> robey: the source?  yep.
[08:58] <carlos> stub: btw, with today's production update, Rosetta's karma should be more or less fixed, I guess that it would mean that karma numbers will be reduced a bit (just warning about people complaining because karma goes down ;-)
[08:58] <robey> sweet :)
[08:59] <robey> i have a bug open on the bad font sizes that hasn't seen any action... if i get time in the next month or so, i may try to cook up a patch
[09:00] <mdke> robey: it's in bzr, but not available publically
[09:00] <robey> mdke: really?  why?
[09:01] <carlos> robey: https://launchpad.net/faq
[09:01] <carlos> robey: look for "Is Launchpad open source? Will it be?"
[09:02] <mdke> carlos: I'm not sure that faq has the reason ;)
[09:06] <carlos> mdke: well, that's what we have. If you think it's not enough, talk with Steve/kiko/mark....
[09:06] <robey> oh, so it's the traditional "we think our code is too ugly" excuse :)
[09:06] <carlos> robey: no
[09:06] <robey> i recommend re-thinking that philosophy, given your target audience
[09:06] <robey> anyway, back i go to lurking
[09:07] <mdke> carlos: no, I didn't say it isn't enough...
[09:08] <carlos> mdke: I mean, that is not enough to say that it's the reason we don't have it as free/open source
[09:08] <mdke> carlos: i guess it is quite a frequently asked question, it might be worth adding an explanation. I've seen it several times in the forum and in this channel
[09:10] <carlos> mdke: then talk with Steve/kiko/mark, obviously, you don't think that faq covers exactly the kind of answer for that question ;-)
[09:10] <carlos> stub: hmmm, so we still have problems with the new virtual hosting code?
[09:10] <mdke> carlos: ok
[09:10] <mdke> carlos: i'll file a bug
[09:11] <carlos> ok, thanks
[09:11] <sivang> mdke: Mark has put up some FAQ looking item somewhere, I can't find it
[09:11] <stub> carlos: yup
[09:11] <sivang> mdke: (re: Launchpad source etc)
[09:51] <lifeless> carlos: ping
[09:56] <mpt_> carlos, do you know what robey was referring to when mentioning font sizes?
[09:56] <mpt_> (I was offline before and after)
[10:08] <carlos> lifeless: pong
[10:09] <carlos> mpt_: no, sorry
[10:11] <lifeless> carlos: you have a branch marked wip in the review queue
[10:11] <lifeless> I do not know what that means
[10:12] <lifeless> can you either move it to the wip area, or mark it needs-review
[10:12] <carlos> hmmm, I think I did a mistake...
[10:12] <carlos> it should be needs-review
[10:12] <carlos> I will fix it no
[10:12] <carlos> now
[10:12] <carlos> lifeless: thanks for the warning
[10:12] <mpt_> lifeless, the "copy and paste this text in the general queue" text has work-in-progress as its status
[10:13] <mpt_> I was going to change it back to needs-review, but thought I should discuss it with you first
[10:13] <carlos> done
[10:13] <mpt_> because I don't yet understand the point of work-in-progress on PendingReviews
[10:13] <carlos> mpt_: well, the usual workflow is work-in-progress -> needs-review -> approved
[10:14] <mpt_> I see that, but I don't know why
[10:14] <lifeless> mpt_: it should say 'copy and paste this text into work in progress when you create the branch, or copy and paste to the general queue and change the text to needs-review'
[10:14] <carlos> mpt_: I guess it's to get a diff of your branch and its status while you work on it
[10:14] <lifeless> mpt_: because having branches being worked on visible helps collaboration, lets managers help out with progress more easily, lets ad-hoc review be done
[10:14] <mpt_> carlos, there are bzr commands for that :-)
[10:15] <mpt_> lifeless, ok
[10:15] <carlos> mpt_: I know, but it's time consuming and others wouldn't know the name of your branch
[10:16] <lifeless> i.e. if someone says 'can you tell me if I am going in he right direction, its easy to answer with the ready-to-use diff;)
[10:16] <mpt_> fair enough
[10:17] <lifeless> it also helps individuals remember what branches they have in progress
[10:27] <mpt_> SELECT secret FROM secret
[10:27] <mpt_> what on earth is that about
[10:30] <carlos> cprov-ZzZ: good night dude
[10:31] <carlos> mpt_: If we tell you it, it will not be a secret anymore...
[10:31] <carlos> :-P
[10:31] <cprov-ZzZ> carlos: thank you, won't be long enough ;)
[10:31] <mpt_> all I'm doing is fiddling with pagetests
[10:47] <carlos> Any reviewer that has some time to have a preimplementation VOIP call ?
[10:51] <spiv> carlos: I can in a minute or two if you like.
[10:51] <carlos> ok, thanks
[10:51] <carlos> spiv: please, ping me when you are ready
[10:57] <spiv> carlos: ping
[10:57] <spiv> carlos: I'm spivvo on skype
[10:57] <carlos> pong
[10:58] <carlos> I just added you
[10:59] <spiv> I don't see you yet, but try calling me anyway.
[10:59] <carlos> it fails
[10:59] <carlos> I'm carlospm_1
[10:59] <carlos> try to add me, please
[11:00] <stub> mpt_: We need a key shared between the appservers so we can encrypt and authenticate session information. That query is retrieving that key.
[11:00] <spiv> carlos: Ok, I'll try that.
[11:01] <spiv> Hmm, failed with "Reason unknown"
[11:01] <carlos> same thing here
[11:02] <carlos> let me restart skype...
[11:02] <spiv> I'll try that too.
[11:03] <carlos> I see you now
[11:03] <carlos> calling
[11:04] <spiv> carlos: I can't hear you.
[11:04] <carlos> hmm
[11:04] <carlos> I hear you
[11:04] <carlos> hmmm
[11:05] <spiv> try the echo test?
[11:15] <mpt_> stub, turned out to be trying to run a pagetest while LP was still running
[11:15] <mpt_> which broke the DB so badly I had to restart
[11:15] <mpt_> (though no doubt there is a psql command that would have been quicker than restarting)
[11:21] <stub> pg_ctlcluster 8.1 main stop; pg_ctlcluster 8.1 main start
[11:22] <mpt_> thankyou :-)
[12:09] <Yannig> Hello everybody :)
[12:10] <Yannig> I hope you will be able to help me, I just cannot sign Launchpad code of conduct :(
[12:10] <Yannig> yannick@kokoyaya:~/Desktop$ gpg --clearsign pouet.txt
[12:10] <Yannig> gpg: no default secret key: secret key not available
[12:10] <Yannig> gpg: pouet.txt: clearsign failed: secret key not available
[12:10] <Yannig> I've never used gpg and I don't know anything more than what is written on https://launchpad.net/codeofconduct/1.0.1/+sign :(
[12:12] <sivang> Yannig: it seems that you did not create or don't have your GPG key where gpg can find it?
[12:15] <Yannig> Indeed, I have never created such a key :$
[12:17] <mpt_> carlos, ping
[12:17] <carlos> mpt_: pong
[12:18] <mpt_> carlos, where would I get a PO template for alsa-utils so I can test uploading it?
[12:18] <carlos> mpt_: export it from launchpad ;-)
[12:18] <mpt_> aha
[12:18] <mpt_> hmmm, actually, I suppose uploading is already tested somewhere
[12:19] <mpt_> is it?
[12:19] <carlos> yeah, uploads should be tested
[12:19] <mpt_> it's not in standalone/ that I can see
[12:19] <mpt_> or in rosetta/
[12:19] <carlos> either web interface and as a doc test
[12:20] <carlos> mpt_: xx-translation-import-queue.txt
[12:20] <carlos> has some tests for uploads
[12:20] <mpt_> ah, excellent
[12:20] <mpt_> thanks
[12:21] <carlos> you are welcome
[12:32] <matthewrevell> Hello
[12:33] <matthewrevell> On the Ubuntu Marketing mailing list, we've discussed how to track our work.
[12:33] <matthewrevell> Launchpad says that only admins can create projects.
[12:33] <matthewrevell> Who do we contact to put our case forward for the creation of an Ubuntu Marketing project?
[12:34] <carlos> matthewrevell: you can either mail launchpad-users mailing list requesting it
[12:34] <carlos> or try directly with stub, kiko, SteveA or lifeless
[12:34] <carlos> but I think the mailing list option is better
[12:35] <matthewrevell> carlos: Thanks, I'll join then mail the ML.
[12:35] <carlos> ok
[12:35] <mpt_> matthewrevell, if you use Launchpad at all, you might find that it's better to set up a team
[12:35] <mpt_> rather than a project
[12:36] <mpt_> With a team you can list members and hold polls
[12:36] <mpt_> With a project you have a bugtracker and a "translation group"
[12:37] <mpt_> Neither of which would be relevant to marketing, really
[12:37] <matthewrevell> mpt_: Hi Mpt, we have a team, but we were looking to do version tracking with bzr, which I understood required a project.
[12:37] <mpt_> matthewrevell, no, that requires a product
[12:37] <matthewrevell> mpt_: Talking of translation, we're looking to translate materials with the loco teams.
[12:38] <mpt_> A product, you can set up without administrator intervention
[12:38] <matthewrevell> mpt_: Ah, doesn't a product require a project, though? Or do you recommend we hook into an existing project?
[12:38] <mpt_> It doesn't
[12:39] <mpt_> You can group products into projects, but the large majority of products aren't in a project
[12:39] <matthewrevell> Ah right.
[12:39] <mpt_> (yes, this is confusing)
[12:39] <matthewrevell> :-)
[12:39] <matthewrevell> I'll create a product and see how we get on with that, then.
[12:40] <mpt_> well, I was just going to say
[12:40] <mpt_> A product would work best for a specific thing you wanted to have translations + bug reports about
[12:40] <mpt_> e.g. a specific marketing document
[12:40] <mpt_> then when you have several, you can use a project to group them
[12:41] <matthewrevell> Right, that makes sense. Thanks.
[12:41] <carlos> hmmm, in fact... matthewrevell your project is Ubuntu ;-)
[12:41] <mpt_> the version tracking wouldn't work so well if you were tracking multiple documents as the same product :-)
[12:41] <carlos> see you later
[12:42] <matthewrevell> mpt_: Yeah, that could be difficult.
[12:43] <matthewrevell> mdke has offered us svn space on the doc team server. I suppose it's just a case of trying to work out which tools suit us best.
[12:44] <mpt_> yeah
[12:44] <matthewrevell> Thanks guys.
[12:45] <mpt_> On the one hand, bzr launchpad rah rah, but on the other hand, there's probably a fair bit of, uh, "synergy" between the work of the docteam and marketing team
[12:45] <matthewrevell> mpt_: Yeah, that's true.
[12:46] <lifeless> bzr >>> svn
[12:46] <mpt_> "Easy" solution: convince the docteam to switch to bzr :-)
[12:47] <lifeless> the consistent story I hear is 
[12:47] <lifeless> 'after dapper releases'
[12:47] <lifeless> so, IMO, they should switch now
[12:47] <Yannig> But in fact, I have no idea how to create such a key for gpg :(
[12:48] <matthewrevell> mpt_: :)
[12:50] <matthewrevell> mpt_: It sounds as tho' a general purpose repository, rather than an individual product for each document we work on, may be more flexible. Unless I'm missing something.
[12:50] <lifeless> I think something is confused here
[12:51] <lifeless> perhaps you giys could restate the constraints and goals for me, and I can offer suggestions
[12:52] <mdke> you need a fair amount more definition about the projects first I think
[12:52] <matthewrevell> lifeless: We're planning to write material such as press releases, articles, etc as a marketng team.
[12:52] <lifeless> ok
[12:52] <matthewrevell> lifeless: There's a discussion on the list as to how we organise that material, and track changes, etc.
[12:53] <lifeless> ok
[12:53] <matthewrevell> I wanted to investigate the best way to do that.
[12:53] <lifeless> got a URL for me?
[12:53] <matthewrevell> As mdke says, things are a touch up in the air.
[12:54] <lifeless> It should be a trivial problem
[12:54] <lifeless> unless you have several thousand documents.
[12:54] <matthewrevell> lifeless: No URL, I'm afraid, yet.
[12:55] <lifeless> matthewrevell: for the mailing list ?
[12:55] <matthewrevell> Oh, sorry.
[12:55] <lifeless> speifically, for the discussion that has the context
[12:55] <matthewrevell> https://lists.ubuntu.com/archives/ubuntu-marketing/2006-July/000474.html
[12:58] <lifeless> I've seen nothing in that conversation to justify having more than one product and one bzr tree (with many branches)
[12:58] <lifeless> maybe I am missing something
[12:58] <mdke> different projects might warrant doing so, I suppose
[12:58] <lifeless> hi jenda
[12:58] <jenda> hello
[12:58] <lifeless> we are just talking about the mt
[12:59] <matthewrevell> lifeless: I think it more likely that I'm missing something.
[12:59] <matthewrevell> :)
[01:00] <matthewrevell> lifeless: I'm just trying to get to grips with Launchpad's terminology and how we can best use it.
[01:00] <lifeless> matthewrevell: well the thing is, we can have a bzr branch up for you and running in about 10 minutes
[01:00] <lifeless> and you can grow from there in any way you want
[01:01] <lifeless> (and be nearly totally self managing too)
[01:01] <jenda> could someone pastebin me a log, please? ;)
[01:01] <mpt_> oh!
[01:01] <mpt_> Why did I think separate documents would need separate products?
[01:02] <lifeless> mpt_: I have no idea
[01:02] <mpt_> I suppose it would be slightly less confusing that way, but a fair bit more work
[01:02] <lifeless> mpt_: I think a single product, single bzr tree, is by far the easiest and least confusing way to manage the documents
[01:03] <matthewrevell> lifeless: Thanks, that makes sense. My gut feeling is that we should use the Launchpad tools, because we don't have a legacy system to port away from.
[01:03] <lifeless> matthewrevell/mpt can you do the log for jenda please, as I'm juggling much right now
[01:04] <mpt_> sure
[01:04] <matthewrevell> Jenda, watch out for a pm window
[01:04] <Yannig> I do have a gpg key now, I follow the instructions by when I validate, I'm told "Please fix the problems below and try again.
[01:04] <Yannig> No public key" :(
[01:04] <malcc> Yannig: You've uploaded your public key to launchpad?
[01:05] <lifeless> Yannig: or to a keyserver 
[01:05] <jenda> matthewrevell: no!!! Please pastebin :)
[01:07] <Yannig> I just created my key on my computer
[01:08] <mpt_> BjornT, ping
[01:09] <matthewrevell> Guys, I've got to head off. Thank you for your input, it's been very helpful
[01:09] <mpt_> pastebin's timing out on me, jenda, did you get it already?
[01:10] <malcc> Yannig: If you go to https://launchpad.net/people/<your id>/+editpgpkeys it explains how to give your public key information to launchpad
[01:10] <spiv> mpt_: http://rafb.net/paste/ seems to be up.
[01:10] <jenda> mpt_: no problem with pastebin here, but there's nothing in it.
[01:10] <mpt_> "there's nothing in it"?
[01:11] <mpt_> jenda, http://rafb.net/paste/results/DTL2Mf44.html
[01:11] <jenda> mpt_: I was in the wrong bin ;)
[01:12] <mpt_> thanks spiv
[01:14] <Yannig> malcc> Thanks but I cannot find my key id with gpg --list-keys my@e-mail
[01:15] <Yannig> I don't understand in which line it is (pub, uid, sub, etc.)
[01:15] <Yannig> Sorry for being so long to understand :(
[01:15] <lifeless> Yannig: do gpg --edit-key you@email
[01:16] <lifeless> then look for 
[01:16] <lifeless> pub  XXXXD/????????  created:...
[01:16] <lifeless> the ??????? bit is your keyid 
[01:17] <Yannig> Thanks a lot lifeless :)
[01:17] <Yannig> I tried with the whole XXXXD/???????? :(
[01:17] <Yannig> yannick@kokoyaya:~$ gpg --send-key 2BCDE704
[01:17] <Yannig> gpg: sending key 2BCDE704 to hkp server subkeys.pgp.net
[01:17] <Yannig> yannick@kokoyaya:~$
[01:17] <Yannig> I guess it's fine now :)
[01:18] <BjornT> mpt_: pong
[01:22] <Yannig> Thanks a lot for your patience :)
[01:22] <Yannig> See you
[01:23] <mpt_> BjornT, is there an example anywhere of using the new pagetest system to verify that a page returns a 403 Forbidden error? There doesn't seem to be such an example in README.txt, or in Google
[01:23] <jenda> lifeless: so... having read that log. If what I need is to keep track of a tree of files, let's say different mockups of the future Spreadubuntu site, each with a dir and subdirs, probably - and possibly other dirs of SU stuff, have URLs I can link people to to look at the material - can bzr+launchpad do all that in a single product / bzr tree?
[01:23] <mpt_> BjornT, I have
[01:23] <lifeless> what is SU ?
[01:23] <mpt_> >>> browser.open('blah')
[01:23] <jenda> SPreadubnutu
[01:23] <mpt_> Traceback...
[01:23] <lifeless> oh right
[01:23] <mpt_> ...403: Forbidden
[01:24] <lifeless> so, right now (as in right this minute), yes, but people will need bzr to look at the material themselves.
[01:24] <mpt_> but the test fails with a Forbidden error :-)
[01:24] <lifeless> spiv: is working on integrating the bzr online web viewer with launchpad so that you can look at the material without bzr
[01:25] <lifeless> you can run that yourself, if you have a server, while still using the launchpad bzr hosting
[01:25] <spiv> mpt_: We set the handleErrors (or somesuch) attribute on the Browser objects already in the page test namespace.
[01:25] <spiv> mpt_: so it gives the traceback direct from Zope, rather than an HTTP error.
[01:25] <spiv> mpt_: I think if you unset that, it will do what you wawnt.
[01:25] <spiv> want, rather.
[01:26] <jenda> lifeless: OK
[01:26] <mpt_> spiv, so where my browser is called "unprivileged"
[01:26] <spiv> mpt_: yeah, try "browser.handleErrors = True"
[01:26] <mpt_> ok
[01:26] <jenda> lifeless: That tips my favor in the direction of svn a bit.
[01:27] <spiv> mpt_: It'll change the behaviour, not sure if it'll be better or not ;)
[01:27] <malcc> spiv, mpt_: You can make it work without this, as in soyuz/99-build-record.txt.   >>> browser.open("http://localhost:9000/+builds/bob/+admin")
[01:27] <malcc>   Traceback (most recent call last):
[01:27] <malcc>   ...
[01:27] <malcc>   HTTPError: HTTP Error 403: Forbidden
[01:28] <lifeless> jenda: well, it will be your choice in the end, but do consider that there is no svn integration with launchpad
[01:28] <mpt_> malcc, that's just what I had, except "...403: Forbidden" at the end
[01:28] <jenda> lifeless: I'm aware. Very unfortunate. We might end up using both in the end. I'll try describe the issue on the ML and I might be back.
[01:29] <lifeless> I'm not on the ML, so please give me a URL to read them on
[01:29] <spiv> malcc: Ah, ok, that seems sane enough as is.
[01:29] <mpt_> spiv, that fails in exactly the same way
[01:29] <lifeless> spiv: any news on teh bzr webviewer integration
[01:29] <spiv> lifeless: not yet, I have a note on my todo list to talk to Steve about it next time I'm in a call with him.
[01:30] <mpt_> it's the famous bradb!
[01:30] <lifeless> spiv: please do so, I think it is really an important thing for us to do
[01:30] <malcc> My bad; that example was using a new browser, so handleErrors was never set to false in the first place, I only checked it wasn't explicitly set true
[01:31] <bradb> mpt_: :P
[01:33] <mpt_> I found your Weblog the other day, bradb
[01:33] <bradb> mpt_: I have two.
[01:33] <mpt_> yes, and the other one
[01:33] <mpt_> Almost as neglected as mine :-)
[01:33] <bradb> indeed
[01:34] <bradb> I've been meaning to do a post about my front door.
[01:34] <bradb> (which few people /know I have/)
[01:34] <mpt_> crapitude!
[01:35] <mpt_> The test passes with "HTTPError: HTTP Error 403: Forbidden" passes, but fails with "...403: Forbidden"
[01:35] <spiv> mpt_: that's craptitude indeed.
[01:36] <malcc> mpt_: I think there's some doctest magic about exact match forms for catching exceptions
[01:37] <spiv> mpt_: What about "HTTPError:... 403: Forbidden"?
[01:38] <mpt_> spiv, passes
[01:38] <spiv> mpt_: odd.  probably a good enough compromise, though...
[01:38] <mpt_> and so does "H... 403: Forbidden"
[01:59] <fabbione> i think i found an interesting bug in the publisher
[01:59] <fabbione> https://launchpad.net/distros/ubuntu/edgy/+source/openais
[01:59] <fabbione> this source was uploaded and it was NEW
[01:59] <fabbione> but i did explicitly ask for it to be REJECTED
[01:59] <fabbione> in theory there should be no track of it
[02:09] <cprov> fabbione: I'm checking what happened 
[02:10] <fabbione> cprov: i am sure that the source has been rejected
[02:10] <fabbione> i did ask forrejection
[02:10] <cprov> fabbione: it is REJECTED
[02:10] <fabbione> cprov: and how does that differ from what i said?
[02:10] <kwwii> moin
[02:10] <fabbione> cprov: i want to understand why LP is tracking it
[02:11] <fabbione> cprov: tracking a source that doesn't exist is not nice
[02:11] <cprov> fabbione: https://launchpad.net/distros/ubuntu/edgy/+source/openais, it's not 
[02:11] <fabbione> cprov: https://launchpad.net/people/fabbione/+packages <- tells me i am openais maintainer
[02:11] <fabbione> from there i found the other url
[02:11] <cprov> fabbione: big orange box saying:      There is no current release of this source package      in The Edgy Eft.     You can still report bugs, make translations, and so on,     but they might not be used until the package is published.
[02:12] <fabbione> cprov: that package might never exists. It's pointless to create so much stuff around it if it will never hit the archive
[02:13] <kwwii> I received an "oops" when trying to rename an already approved Spec in launchpad...anyone know if that is normal?
[02:14] <mpt> kwwii, an "oops" is never acceptable, please report a bug
[02:14] <cprov> fabbione: I can't see your point, since we had an upload with agiven name, it will show up in several places as a placeholder.
[02:15] <fabbione> cprov: i might upload by mistake company-private-package that nobody must know about. I ask for rejection in souyz and i don't see why it should appear in LP everywhere
[02:15] <fabbione> so i see very little point in creating all the placeholders for a package that might never hit the archive
[02:15] <fabbione> (not in LP at least)
[02:16] <spiv> I don't know much about this end of things, but I agree with fabbione.  There's not really anything useful to be gained by adding placeholders that I can see.
[02:16] <cprov> fabbione: so in you example the information would be embargoed anyway
[02:17] <fabbione> cprov: but they are not
[02:17] <fabbione> and openais is the proof
[02:17] <spiv> If we really want a package to show up as a placeholder, upload a placeholder package -- e.g. landscape-client.
[02:17] <fabbione> so one way or another there is something happening that shouldn't
[02:17] <Kinnison> It's simply permitting the traversal because there is a SourcePackageName object of the right value
[02:18] <cprov> spiv: come on, I'd expect better oppinion from you, you know we do not "create" placeholders they are side effect of the current traversal architecture
[02:18] <spiv> cprov: Well, there's a record of it in the LP db somewhere.
[02:18] <spiv> cprov: Or it wouldn't be traversable :)
[02:18] <fabbione> and that record shouldn't be there since it was rejected
[02:18] <fabbione> NEW source -> rejected -> /dev/null
[02:19] <cprov> spiv: offcourse, there is also an SPR for openais, it was uploaded and them rejected
[02:19] <spiv> It doesn't really make sense to me that we allow bugs and translations and things for this sort of mistake.
[02:19] <elmo> eh
[02:19] <cprov> fabbione: maybe we can reach it with the SPR GC, but it won't be atomic anyway
[02:19] <elmo> not all REJECTions are final like this
[02:19] <fabbione> cprov: i don't know what SPR GC is but it sounds scary
[02:19] <elmo> sourcepackagerecord garbage collection
[02:20] <spiv> cprov: Incidentally, the link to openais's 0.77-0ubuntu1 on https://launchpad.net/people/fabbione/+packages is a 404
[02:20] <fabbione> elmo: i am making a corner case really.. openais will be uploaded sometimes
[02:20] <cprov> fabbione: this is a local defect of +packages page
[02:20] <cprov> spiv: sorry ^^
[02:20] <Kinnison> Guys, http://launchpad.net/distros/debian/+source/launchpad-integration should give you some indication that it's just a "this name exists, so we try and let it be traversable"
[02:20] <spiv> cprov: ah, ok.
[02:20] <cprov> don't blame the entire architecture for that
[02:22] <spiv> Kinnison: (not that I hold very strong opinions here) the traversability isn't really what bugs me, it's that there's an apparently invalid entity appearing in e.g. /people/fabbione/+packages reports and as a valid package name for bugs and things.
[02:22] <Kinnison> spiv: the mere fact that there's a SPN means it can be used to report bugs
[02:23] <Kinnison> The +packages artifact is that the selects are wrong
[02:23] <spiv> Kinnison: right, and I'm wondering if therefore that SPN existing is itself a bug.
[02:23] <fabbione> ok so one more question
[02:23] <cprov> Kinnison: indeed
[02:23] <kwwii> mpt: ok, thanks :-)
[02:23] <fabbione> let say you don't show me that openais is in my package list
[02:23] <Kinnison> spiv: No
[02:23] <fabbione> and people start filing bugs on it
[02:23] <Kinnison> spiv: It exists because there is an SPR in there pointing at it
[02:23] <fabbione> what's the use case if the package will never ever hit archive?
[02:23] <Kinnison> spiv: there is an SPR in there because we record the history of the upload existing and being rejected
[02:24] <Kinnison> fabbione: That's an argument for only allowing bugs to be filed if the SPN is published in the archive
[02:24] <Kinnison> fabbione: Not for removing the SPN of rejected packages
[02:24] <fabbione> Kinnison: make that also translations and so on
[02:24] <fabbione> Kinnison: well as i said before.. who would you then handle a case where package for company foo should not have been displayed in LP?
[02:25] <fabbione> Kinnison: i don't think i have a UI (as package maintainer) to ask LP to hide the upload i am going to do in about 5 minutes
[02:25] <fabbione> or the upload i did 5 minutes ago
[02:25] <cprov> fabbione: this is another issue and it's covered by the SecurityInSoyuz
[02:25] <mpt> spiv, perhaps one day two or more distributions will have packages with the same name that are completely unrelated
[02:26] <spiv> It seems to me this is another instance of the general problem that launchpad makes it hard (or impossible) to delete things that were added by accident.
[02:26] <mpt> bingo
[02:27] <spiv> It perhaps be nice if Launchpad didn't even add it all in this particular case (although from the sidelines that's not clear to me), but it wouldn't matter if we could just delete stuff.
[02:28] <fabbione> spiv: not add it in the first place > delete after
[02:28] <Kinnison> It's categorically NOT POSSIBLE
[02:28] <fabbione> you can still track somewhere else that the uplaod was done and rejected
[02:28] <Kinnison> it got added because it was accepted into NEW
[02:28] <Kinnison> that's IN THE DB
[02:28] <spiv> fabbione: Well, I'm hearing arguments from Kinnison that there are good reasons why that shouldn't happen.  I'm not familiar enough to judge that atm.
[02:28] <Kinnison> so, for that matter, is REJECTED
[02:29] <Kinnison> the only way we could remove the SPN is by GCing the queue, then the SPRs and then the SPNs
[02:29] <Kinnison> And we have been using "un-used" SPNs as anchor points for bugs anyway
[02:29] <Kinnison> like pseudo-packages
[02:29] <spiv> But it's safe to say Kinnison knows much more about this than I do :)
[02:29] <fabbione> GC/SPR/SPN has no meaning to me
[02:29] <Kinnison> Garbage Collect, Source Package Release, Source Package Name
[02:30] <spiv> I think the non-jargon way to say what Kinnison is saying is "something happened, therefore it is recorded in Launchpad that it happened".
[02:30] <fabbione> yes and i said.. it's ok to be logged
[02:30] <mpt> Launchpad == Hotel California
[02:30] <Kinnison> spiv: exactly
[02:30] <fabbione> doesn't need to show everywhere
[02:30] <sivang> mpt: heheh
[02:31] <Kinnison> fabbione: That breaks a fundamental design assumption made a long time ago though, so we need to consider how to deal with it
[02:31] <fabbione> Kinnison: but my question is, do you understand my usecase? or is it unclear?
[02:31] <spiv> https://launchpad.canonical.com/TotalExposure
[02:31] <fabbione> because if we can't agree on the usecase, then there is very little point to discuss it
[02:32] <fabbione> spiv: -ENOPASSWD
[02:33] <mpt> spiv, https://launchpad.net/products/launchpad/+spec/fair-exposure
[02:33] <spiv> fabbione: same as the Canonical one I presume, I'm only half-serious about that link anyway :)
[02:33] <fabbione> spiv: hehe ok :)
[02:33] <spiv> mpt: haha
[02:33] <mpt> fabbione, same as chinstrap
[02:34] <Kinnison> fabbione: I can appreciate your viewpoint. And personally I think we shouldn't offer the +source/foo traversal if foo is not published in the distro/distrorelease but that's a decision to be made by the UI people, not me :-(
[02:34] <fabbione> Kinnison: ok, so who should I bitch about it?
[02:36] <spiv> Kinnison: Hmm, maybe SourcePackageNameVocabulary should filter out that sort of thing?
[02:36] <Kinnison> fabbione: Well, to begin with, we need to better understand why we don't already perform this limitation, so I'd start by talking with bradb and/or bjornt about the use-cases for source-package-names which don't have associated packages being used for bug reporting etc.
[02:36] <Kinnison> spiv: I know nothing of the UI details :-)
[02:36] <lifeless> Kinnison: ITP
[02:37] <fabbione> Kinnison: ok thanks
[02:37] <spiv> Kinnison: That's the thing wot says what things of a certain kind of thing there are ;)
[02:37] <fabbione> thanks everybody
[02:37] <Kinnison> lifeless: Hmm
[02:37] <lifeless> Kinnison: is a random thought ;)
[02:38] <bradb> Kinnison: I'm missing context on this conversation, but at bug reporting time, Malone asks Soyuz for package names.
[02:39] <bradb> so, if the user specifies package "foo", Malone asks Soyuz what it knows about "foo", i.e., a BP and SP, if applicable
[02:39] <Kinnison> Does malone give that routine a context? (distro, distrorelease, whatever)
[02:42] <bradb> yep
[02:42] <bradb> IDistribution.getPackageNames
[02:43] <Kinnison> Okay, so we're forcing it to use publishing records, cool
[02:43] <Kinnison> So we just need to fix that idiotic traversal from +sourc/e
[02:44] <spiv> Kinnison: The traversal isn't really an issue.
[02:44] <spiv> Kinnison: It would never have been noticed if it wasn't linked to.
[02:44] <spiv> Kinnison: If you fix everywhere link +packages that are linking to it, then no-one will ever know, or care, that you can traverse it.
[02:45] <spiv> s/link +packages/like +packages/
[02:46] <Kinnison> Not good
[02:46] <Kinnison> Fix the traversal so that any accidental link 404s
[02:46] <Kinnison> then fix all the 404s to not be there
[02:46] <spiv> Kinnison: Sure, fixing the traversal is still a good idea :)
[02:48] <cprov> Kinnison: the ISourcePackage traversal isn't really fixable, it is meant to do exactly what it does (DR + SPN)
[02:55] <Kinnison> hmm
[03:10] <salgado> SteveA, around?
[03:14] <salgado> or anybody familiar with the new virtual host stuff?
[03:18] <BjornT> salgado: what's up
[03:20] <ploum> BjornT: I reported two bugs related to what you told me : bug #51835 and bug #51836
[03:20] <Ubugtu> Malone bug 51835 in launchpad "Content of a bug is missing in +text mode" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51835
[03:20] <Ubugtu> Malone bug 51836 in launchpad "Search is not working in +bugs-text mode." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51836
[03:37] <BjornT> ploum: ok. i'm not sure that they will be fixed within your project's timeframe, though. the +text stuff was added for (and works for) a specific use case, and we have quite a lot of other things to do atm.
[03:37] <ploum> ok, thanks for the answer
[04:48] <lifeless> spiv: around ?
[05:34] <Keybuk> malcc: ping?
[05:35] <malcc> Keybuk: Pong
[05:35] <sabdfl> matsubara: do you want me to publish a fix for the edit-spec-name bug?
[05:35] <Keybuk> malcc: do you know anything about the buildds?
[05:35] <malcc> keybuk: A little
[05:35] <Keybuk> https://launchpad.net/distros/ubuntu/+builds?build_state=pending&build_text=
[05:36] <Keybuk> how do things in SECURITY or BACKPORTS get built?  they don't seem to be using the currently idle buildds
[05:37] <matsubara> sabdfl: I'm looking at it atm
[05:37] <malcc> Keybuk: I don't know for sure, I'm checking with the other guys
[05:40] <Keybuk> also ...
[05:40] <Keybuk> https://launchpad.net/distros/ubuntu/+source/python-support/0.3.8
[05:40] <Keybuk> why has that got "No builds recorded" ?
[05:41] <malcc> Keybuk: I'm guessing we don't have chroots for these pockets. I didn't think we built security in Soyuz at all, and this looks like a publically visible list of pending security builds, which would be bad
[05:41] <Keybuk> malcc: ok, we'll ignore those then
[05:41] <elmo> security isn't built by soyuz/launchpad yet
[05:41] <Keybuk> why isn't python-support being built?
[05:43] <Keybuk> it seems like they fell flat on their face about 2 hours ago, and haven't moved since
[05:43] <Keybuk> is the "scanner" running?  (that's the right term, yes?)
[05:44] <malcc> Keybuk: Yes that's the right term and I'll check
[05:56] <malcc> Keybuk: I'm afraid I'm stuck, I've queued your question for Kinnison or cprov as soon as they're available, seems I don't know the right little about the buildds :(
[06:00] <Keybuk> thanks
[06:12] <kiko> GOOD MORNING LAUNCHPAD
[06:18] <Keybuk> Kinnison: ah, you're available?
[06:21] <Kinnison> Keybuk: Me? Available? pah
[06:21] <Kinnison> Did malcc pass on my comments?
[06:21] <Keybuk> Kinnison: no, he did not
[06:21] <Kinnison> aah okay
[06:21] <Kinnison> one sec
[06:22] <Kinnison> BACKPORTS in the queue suggests missing chroots
[06:22] <Kinnison> SECURITY in the queue suggests incomplete arch set for security uploads
[06:22] <Kinnison> missing builds indicates the queue builder is causing a problem
[06:22] <Keybuk> right, those I didn't care too much about
[06:22] <Keybuk> it's the missing builds that's the problemn
[06:22] <Kinnison> infinity re-wiggled the queue-builder recently
[06:22] <Kinnison> so you'd need to check with him really
[06:23] <elmo> he's on holiday
[06:24] <Kinnison> I thought that was last week
[06:24] <Kinnison> am I a week out of sync?
[06:27] <elmo> R  [  35: Adam Conrad         ]  [VAC]  July 1 - July 9
[06:27] <Keybuk> Kinnison: yeah, "wait for infinity" is not an option at this point
[06:29] <Kinnison> Arrr, okay I'll go look
[06:29] <Kinnison> give me 5
[06:30] <Kinnison> Okay, so the queue builder has been being run
[06:30] <Kinnison> Can you give me an example of a package not being scheduled?
[06:31] <elmo> python-support was I think the one they were using
[06:33] <Kinnison> 0.3.8 ?
[06:34] <Kinnison> source published about three hours ago... hmm
[06:38] <Kinnison> As soon as this publishing run is finished I'll do a manual queue-builder run to see what's up
[06:50] <flacoste> where can I find the revision that is running in production?
[06:51] <matsubara> flacoste: launchpad.canonical.com/ProductionsStatus
[06:51] <flacoste> tnx!
[06:52] <matsubara> s/ProductionsStatus/ProductionStatus/
[06:52] <matsubara> actually it's wrong
[06:52] <matsubara> flacoste: https://launchpad.canonical.com/LaunchpadProductionStatus
[06:52] <flacoste> that one worked!
[06:56] <Kinnison> Keybuk: Interesting, the queue builder just ran fine
[06:57] <Kinnison> Keybuk: indeed there are now things building
[06:57] <Kinnison> Keybuk: looks like the queue builder wasn't running for some bizarre reason
[06:57] <Kinnison> Keybuk: it should be fine now
[06:57] <Keybuk> odd
[06:57] <Keybuk> thanks
[06:57] <Kinnison> Sorry about that
[07:32] <sabdfl> mdke__: ping
[07:34] <mdke__> sabdfl: hi
[07:36] <sabdfl> mdke__: what number can i reach you on?
[07:36] <mdke__> sabdfl: see query
[07:37] <mdke__> sabdfl: ah, possibly I'm not getting through, hang on
[07:37] <sabdfl> i don't see nuttin' :-)
[07:37] <mdke> sabdfl: hear me now?
[07:37] <jsgotangco> goodnight
[07:37] <sabdfl> nup
[07:38] <sabdfl> night jerome
[07:38] <jsgotangco> hey sabdfl =)
[07:38] <jsgotangco> yeah night
[07:50] <kiko> sabdfl!
[08:16] <cprov> Keybuk: is queue-builder working as expected now ?
[08:16] <Keybuk> let me check
[09:04] <salgado> SteveA, around?
[09:22] <kiko> cprov-afk, ping when you are around
[09:45] <kiko> hey matsubara 
[09:45] <kiko> when was the last rollout?
[09:46] <salgado> this morning?
[09:46] <kiko> ah, cool.
[10:11] <jelmer> Hi
[10:11] <kiko> yo
[10:11] <jelmer> Is there any way to see what happened to https://launchpad.net/products/launchpad/+spec/bzr-roundtrip-svn, it appears to have been removed
[10:12] <kiko> jelmer, it was moved to /products/launchpad-bazaar/
[10:13] <jelmer> Ah, thanks
[10:16] <jelmer> The link on https://wiki.launchpad.canonical.com/BzrRoundtripSvn is broken in that case, but I don't seem to have write access to that page (nor to /products/launchpad-bazaar/)
[10:19] <jelmer> Also, it should now be (if the spec hasn't changed) implemented by http://bazaar-vcs.org/BzrForeignBranches/Subversion
[10:21] <kiko> jelmer, should that wikipage be public?
[10:25] <jelmer> The BzrRoundtripSvn one? It's always been, but I don't know if it should be.
[10:31] <kiko> I think it should be, but hmmm, where should it live. where's ddaa?
[10:52] <sabdfl> so lunchpadders, how's it hanging today?
[10:53] <sabdfl> kiko: any fallout from those blueprint landings?
[10:53] <sabdfl> i saw the spec-name-edit bug matsubara fixed, thank you
[10:53] <kiko> sabdfl, I need to see tomorrow's report -- so far, none has been reported here
[10:53] <kiko> cool
[10:53] <sabdfl> kiko: https://launchpad.net/projects/launchpad/+specs
[10:54] <kiko> ah, very nice
[11:08] <flacoste> LastiQ: I will now give your patch a try
[11:09] <LarstiQ> k
[11:09] <LarstiQ> I didn't manage to improve on it, but the basics should work
[11:16] <sivang> guys, Ian wanted to put home-user-backup into "Pending Approval" but for some reason LP wouldn't let him, can someone do that for him ? :-)
[11:17] <sivang> hmm
[11:17] <sivang> sorry, no need
[11:17] <sivang> I was able to do so. weird
[11:24] <lifeless> gnight
[11:25] <sivang> night lifeless 
[11:29] <sivang> night folks
[12:09] <flacoste> LarstiQ: I don't see any differences with the previous behavior
[12:09] <flacoste> what should have changed?
[12:10] <flacoste> i went over the sample session that I attached to bug 4663, and I get the same exact output
[12:10] <Ubugtu> Malone bug 4663 in bzr "bzr log does not work on merged revisions" [Medium,In progress]  http://launchpad.net/bugs/4663
[12:11] <flacoste> only notable differences: I get warnings about change in configuration (rename branches.conf to locations.conf and other parameter changes)