[12:13] <lucasvo> hm. how can I delete a branch?
[12:16] <kiko> ha ha
[12:16] <kiko> that's a FAQ
[12:16] <kiko> there's a bug open on it, fwiw
[12:17] <lucasvo> kiko: that means impossible?
[12:17] <kiko> I think you can't do it currently, no
[12:17] <lucasvo> lol
[12:18] <lucasvo> can one ask an admin?
[12:18] <kiko> I don't think so, but ddaa may know (tomorrow)
[12:19] <lucasvo> ok
[12:19] <lucasvo> ty
[12:34] <lifeless> kiko: there is some
[12:35] <kiko> lifeless, some?
[12:35] <lifeless> some documentation on shared branches
[12:35] <kiko> ah. on help.launchpad.net?
[12:35] <lifeless> sorry, shared repository
[12:36] <lifeless> err, whatever it was you asked, its partially documented for end users.
[12:36] <lifeless> oh help.lp.net - no, I dont know.
[12:36] <lifeless> but I think not
[12:36] <lucasvo> kiko: could you do me a favour?
[12:37] <lucasvo> kiko: does inkscape render the LP Logo correctly on your machine?
[12:37] <kiko> lucasvo, firefox does at least
[12:37] <lucasvo> kiko: on my edgy machine it renders it with black steam
[12:37] <kiko> yeah
[12:37] <kiko> you can clear that layer easily though can't you?
[12:37] <lucasvo> same on your side?
[12:38] <kiko> yep
[12:38] <lucasvo> ?
[12:38] <kiko> let me install inkscape so I can see
[12:38] <lucasvo> ty
[12:39] <kiko> horribly slow download though
[12:39] <lucasvo> gnome renders it correctly as well
[12:45] <kiko> oh
[12:46] <kiko> ISWYM
[12:46] <kiko> it's completely black
[12:47] <kiko> lucasvo, I was able to fix it though
[12:47] <kiko> use object->fill and stroke
[12:47] <lucasvo> and then?
[12:48] <lucasvo> it says: Paint is undefined
[12:49] <kiko> click on gradient.. well...
[12:49] <kiko> download the file again.
[12:49] <lucasvo> thanks!
[12:50] <kiko> lucasvo, does that look better? I need to scramble home
[12:50] <lucasvo> kiko: well, it's still not the same, but I can live with it. thanks
[12:51] <lucasvo> kiko: who is responsible for it?
[12:51] <kiko> lucasvo, mpt.
[12:52] <kiko> he will be up in a few hours, btw.
[12:54] <lucasvo> and I'll be asleep.
[12:54] <lucasvo> kiko: thanks anyway
[12:54] <kiko> sure think. thanks!
[12:55] <lucasvo> kiko: is he a graphician?
[12:55] <kiko> an artist you mean?
[12:55] <kiko> not really if so
[12:56] <kiko-zzz> but I've put down an outline here that we need some kit for people that want to endorse launchapd
[12:56] <kiko-zzz> err launchpad
[12:56] <kiko-zzz> so I might be able to get you with a button/banner sometime soon.
[01:08] <lucasvo> kiko-zzz: ok, thanks
[01:55] <BlueAidan> hmm
[05:47] <lifeless> random python question
[05:47] <lifeless> can a so be used to init a package? i.e. __init__.so
[05:49] <stub> No idea
[05:54] <lifeless> >>> import bzrlib.p
[05:54] <lifeless> Traceback (most recent call last):
[05:54] <lifeless>   File "<stdin>", line 1, in ?
[05:54] <lifeless> ImportError: dynamic module does not define init function (initp)
[05:54] <lifeless> >>> import bzrlib.p.__init__
[05:54] <lifeless> >>> bzrlib.p.__init__
[05:54] <lifeless> <module 'bzrlib.p.__init__' from 'bzrlib/p/__init__.so'>
[05:55] <lifeless> I suspect it can be made to work
[05:59] <stub> The trick would be to see if other modules in the package can be imported
[05:59] <stub> Most code I've seen though just does 'from _foo import *' - it lets you muck around or wrap the C code in a nicer environment, setup docstrings etc. So unless you are worried about import times...
[06:01] <lifeless> well
[06:02] <lifeless> its more that we have a plugin system that duplicates a certain amount of 'import'
[06:02] <lifeless> so we should strive to be compatible
[07:28] <stub> I'm going to grab some lunch and then push out r3843
[08:28] <mpt__> bug 12345
[08:28] <Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  http://launchpad.net/bugs/12345
[08:47] <sivang> morning
[08:58] <stub> Launchpad will be going down in 15 minutes for its regular upgrade. Estimated downtime is 10 minutes.
[09:24] <lifeless> stub: (importd.tests.test_baz2bzr.TestBaz2bzrImportFeature) hung
[09:26] <stub> Thought it would. I have no idea why my test suite modifications make pipeBaz2bzr hang :-P 'icky debugging later I guess.
[09:29] <stub> malcc: Just upgrading Launchpad. Any problems with me pushing out r3843 to drescher?
[09:30] <malcc> stub: Yes, my fix for one of the bugs in r3817 hasn't landed yet
[09:31] <stub> malcc: Ok. I'll leave drescher untouched - none of the db patches look like they affect soyuz so we can keep the existing version running.
[09:31] <malcc> stub: Cool, thanks
[09:51] <stub> I need faster CPUs, or less data :-(
[10:17] <SteveA> mpt_: ping
[10:32] <stub> Is it my imagination, or is Launchpad now much snappier after this upgrade?
[10:34] <mpt__> SteveA, pong
[10:35] <SteveA> hi mpt_ 
[10:44] <mdke> jordi: obviously I failed yesterday to achieve the desired result on the mailing list. I've now found the correct option. I also went through the spam, out of 550 posts there was only one genuine email
[10:46] <sivang> labas SteveA 
[10:47] <SteveA> laba
[10:47] <sivang> SteveA: s/s$// ?
[10:55] <SteveA> sivang: it's a slang form
[10:55] <sivang> SteveA: ah :)
[10:59] <jordi> mdke: ugh
[10:59] <jordi> mdke: thanks mate
[11:04] <sivang> It seems that the DB copy make harness is working on and the one I see by the local app server answering me on the browser, is different, is that so?
[11:05] <sivang> weird thing is that I use http urls that are using the local running rocketfuel copy, which means using the same db, but, when creating a spec through a pagetest frommake harness interatively, I can't see it when I list specs in the browser
[11:09] <jamesh> sivang: the tests run using a separate DB in a known state (as it looks after loading sample data)
[11:10] <jamesh> sivang: running the tests against launchpad_dev would result in failures if you change anything locally, which would make things unreliable.
[11:10] <sivang> jamesh: I see, thanks. I also think I found where my error is...:)
[11:11] <sivang> jamesh: lanunchpad_dev is for the local running rocketfuel yes?
[11:11] <jamesh> yes
[11:11] <sivang> cool, thanks.
[11:14] <lucasvo> mpt: I'd like to put a Hosted on Launchpad badge on my homepage
[11:14] <lucasvo> kiko gave me an svg of the logo. However this is not being displayed correctly in inkscape...
[11:15] <lucasvo> http://www.vincisolutions.org/launchpad_orig.svg
[11:16] <mpt> lucasvo, hmm, that's polluting a bit :-/
[11:16] <lucasvo> mpt: kiko told me that you are the one to ask.
[11:17] <lucasvo> Is there I logo I can manipulate in Inkcape?
[11:18] <sivang> mpt: we should use natural gass ;-)
[11:19] <sivang> jamesh: so make harness uses the special DBs for tests then?
[11:19] <sivang> jamesh: (just as make check)
[11:20] <sivang> s/DBs/DB/
[11:24] <jamesh> sivang: yeah.  launchpad_ftest, iirc
[11:24] <jamesh> sivang: if you need to make sample data changes for your tests, read database/sampledata/README
[11:27] <sivang> jamesh: cool, thanks again.
[11:28] <sivang> jamesh: as a general rule, it would probably be best to have a test change the sample data for the same instance of the test run, rather then trying to change the initial state of the sample db, right?
[11:32] <Spads> https://launchpad.net/people/planet-ubuntu/+branch/config/main <-- is there a reason that I can't find anything at this http URI?  Is this just something where I need to wait for a batch job?
[11:33] <Spads> the one mentioned on the page I linked, rather
[11:34] <Spads> sftp checkouts seem to work just fine, although I'd prefer anonymous checkout for this job
[11:35] <mdke> I think, although I know very little about it, that http browsing isn't supported yet
[11:35] <Spads> Well
[11:36] <Spads> I don't need to *browse* per se.  I just wanted to do a "bzr get" on that URI
[11:36] <mdke> that doesn't work?
[11:36] <Spads> bzr: ERROR: Not a branch: http://bazaar.launchpad.net/~planet-ubuntu/config/main/
[11:37] <Spads> this is bzr (bazaar-ng) 0.8.2
[11:37] <mdke> same for me, you'll need someone who actually knows what they are talking about then
[11:37] <Spads> cool
[11:41] <sivang> hmm, make harness's python intp. got hung for me on a getControl..
[12:03] <mdke> Spads: looks like there are none of those around. Maybe #bzr can help?
[12:03] <Spads> Well, it strikes me that this is more a launchpad issue than a bzr issue
[12:04] <Spads> I can do http gets in general on my own systems, no problem
[12:04] <mdke> yeah, just in case there happened to be more people listening in there than in here
[12:07] <Spads> I'll wait for the time zones to work themselves out and ask again
[12:07] <jamesh> Spads: there is data in http://bazaar.launchpad.net/~planet-ubuntu/config/main/.bzr/ -- there are no working trees published on http://bazaar.launchpad.net
[12:07] <Spads> hum.
[12:08] <Spads> oh
[12:08] <Spads> it just appeared
[12:08] <Spads> it was 404 a few minutes ago
[12:08] <Spads> there we go
[12:08] <jamesh> there is also a time delay in publishing the branch
[12:08] <Spads> that's acceptable
[12:08] <Spads> thanks!
[12:09] <jamesh> it essentially does a "bzr pull" from where you put the branch on the sftp server to where the HTTP server looks
[12:09] <jamesh> this ensures that the published branch doesn't get corrupted if you screw things up on the sftp server
[12:09] <Spads> right
[12:10] <jamesh> and makes sure you actually uploaded a bzr branch rather than a copy of windows XP or something
[12:10] <Spads> haha
[12:11] <sivang> heh
[12:21] <sivang> It just hangs on the +addspec after submitting.
[12:29] <sivang> anyway, I've workarounded it by writing the browser.content to a file and getting from the a correct string of an error
[12:39] <sivang> what's the right way to run a single test inside a story ?
[12:44] <lucasvo> shouldn't bzr ignore .pyc files?
[12:55] <stub> lucasvo: You might get a rationale in #bzr
[01:12] <sivang> hey bradb 
[01:21] <lucasvo> anybody can tell me if there is a way to delete a bzr branch in LP? I know I can't do it, but can someone else do it?
[02:05] <plaes> hi, I'm interested in the process how you get the translations from Rosetta back to upstream...
[02:11] <mpt> lucasvo, yes, an admin can do it
[02:12] <mpt> someone like stub or (I think) ddaa
[02:12] <lucasvo> mpt: who is an admin and is willing to do it?
[02:12] <lucasvo> ah, ok
[02:12] <lucasvo> stub: could you please delete this https://launchpad.net/people/harmony-devs/+branch/harmony/trunk/?
[02:13] <lucasvo> ddaa: or could you do it?
[02:14] <ddaa> I do not have the required privs. That involve deleting an object from the db and from two filesystems.
[02:14] <ddaa> I think stub has all the required privs
[02:15] <ddaa> hum...
[02:15] <sivang> so, I've converted xx-specs-02-creation.txt to testbrowser , and I have some clauses that fail when I ./test.py -f --test=pagetests.specs and not when I interactively paste the clauses in make harness
[02:15] <sivang> any idea anybody ?
[02:15] <sivang> the exceptiong i get is:
[02:15] <sivang>      SyntaxError: invalid syntax
[02:15] <mdke> plaes: rosetta doesn't take care of that, individual translation teams need to do that
[02:16] <sivang> what I'm trying to do is set a browser.getControl(name='field.summary').value ="....long string"
[02:16] <mdke> plaes: (if you mean from Ubuntu to upstream)
[02:16] <ddaa> sivang: there must be something wrong with your doctest syntax
[02:16] <plaes> mdke: so, if my team leader doesn't care, then all the translations made in Rosetta are basically lost for other distros?
[02:16] <salgado> sivang, do you have a line break somewhere in that statement?
[02:17] <sivang> sladen: I don't
[02:17] <sivang> do I need to ?
[02:17] <mdke> plaes: well, let's be clear. Rosetta can be used for translating upstream projects. However, translation teams for Ubuntu are responsible for pushing translations from Ubuntu upstream, as with other distributions that don't use rosetta
[02:18] <plaes> mdke: thx, this is what I wanted to know :)
[02:18] <sivang> I would expect the doctest engine to "just work" ;-)
[02:18] <mpt> plaes, it makes sharing easier, but not effortless
[02:18] <mdke> ok
[02:19] <matsubara> sivang: can you mail me the diff, I'll take a look
[02:19] <sivang> matsubara: oh , I would appriciate that alot :)
[02:22] <niemeyer> Morning launchpaders
[02:23] <sivang> hey niemeyer !
[02:23] <sivang> matsubara: sent
[02:24] <sivang> matsubara: I susepct a line break is missing, as salgado noted :) the fact it succeds in the interactive make harness with the hack you setn me, and that it fails when running it suggest so :)
[02:25] <salgado> sivang, a line break shouldn't be needed
[02:25] <lucasvo> ddaa: thanks anyway.
[02:25] <sivang> salgado: ah, then I've done someting wrong for real , doh.
[02:25] <ddaa> lucasvo: if you want us to keep track and handle the issue, your best option is to file a support request
[02:27] <ddaa> https://launchpad.net/products/launchpad/+tickets
[02:27] <ddaa> hey stub
[02:27] <stub> Morning
[02:28] <ddaa> stub: lucasvo wants that branch deleted https://launchpad.net/people/harmony-devs/+branch/harmony/trunk/
[02:29] <stub> We need a script to remove them if we are going to support this
[02:29] <stub> lucasvo: Can you open a bug report or support request? Its not a trivial operation I can do now.
[02:29] <jordi> danilos: what's the status for xaralx?
[02:30] <lucasvo> stub: yes
[02:30] <lucasvo> stub: though there is already an open bug.
[02:30] <lucasvo> stub: and removing branches is an important feauture
[02:34] <lucasvo> stub: fyi bug 29998
[02:34] <Ubugtu> Malone bug 29998 in launchpad "Cannot delete branches, series, etc" [Medium,Confirmed]  http://launchpad.net/bugs/29998
[03:21] <ddaa> lucasvo: it's mostly blocked on sabdfl's moratorium on DELETE permissions...
[03:22] <ddaa> and the fact that there's some long standing issues in related systems that get the priority
[03:23] <lucasvo> ddaa: well, if I accidentally uploaded the wrong bzr tree. why shouldn't I be able to delete it?
[03:23] <lucasvo> ddaa: even if I could just archive it and make it disappear
[03:23] <ddaa> I think you definitely should.
[03:24] <ddaa> Yeah, the stopgap measure would be to allow users to mark branches "inactive"
[03:24] <ddaa> or "deleted"
[03:25] <ddaa> everybody agrees that would be good
[03:25] <lucasvo> but I don't know why one should store data that is completely wrong and for testing purposes only...
[03:26] <ddaa> "inactive" branches would be effectively hidden to users
[03:27] <ddaa> mostly undistinguishable from deleted ones
[03:27] <ddaa> anyway, I agree that it should be easier to do what you ask for
[03:29] <ddaa> But we have limited resources to implement new features
[03:29] <danilos> jordi: carlos responded to the maintainer, not sure if we got another response (we had a wrong list of translators whose translations to remove)
[03:29] <ddaa> The best thing you can do is comment on the bug and post to launchpad-users
[03:30] <lucasvo> this is a pita and makes the launchpad mirror unusable for me.
[03:45] <LarstiQ> lucasvo: for testing, you can use +junk
[03:45] <lucasvo> LarstiQ: testing?
[03:45] <lucasvo> testing what?
[03:45] <LarstiQ> 15:25:23 < lucasvo> but I don't know why one should store data that is completely wrong and for testing purposes only...
[03:46] <lucasvo> LarstiQ: the problem is, I uploaded testing data to a place where real data belongs
[03:46] <LarstiQ> lucasvo: you can push --overwrite after uncommitting
[03:47] <LarstiQ> lucasvo: that is what I do, though I agree actually deleting branches would be nice
[03:50] <lucasvo> LarstiQ: ok, I didn't know that this option exists and that it's allowed
[03:50] <lucasvo> LarstiQ: thanks
[03:51] <mpt> LarstiQ, eventually we'll pass the point where implementing the ability to delete branches would take less time than stub has spent deleting them manually :-)
[03:52] <lucasvo> mpt: I would say this won't be far away from now
[03:52] <lucasvo> (though I don't know how launchpad works)
[03:52] <LarstiQ> mpt: but as those are costs already incurred, will that speed up the implementation?
[03:52] <jordi> danilos: let me check
[03:52] <jamesh> to fully delete a branch would require database and disk access
[03:52] <mpt> possibly not :-)
[03:52] <jamesh> so that the mirrored copy (and possibly sftp copy) of the actual data go away too
[03:52] <kiko> yep
[03:53] <jordi> danilos: the ball is on our court
[03:53] <jamesh> it isn't as simple as granting DELETE permission on a table and whipping up a form
[03:53] <jordi> danilos: "I will take a look as soon as another scripts ends running on that server."
[03:54] <jordi> danilos: so you probably need to reexecute the removal script
[03:54] <kiko> jamesh, though there could be a garbage collector
[03:54] <ddaa> jamesh: from the user's perspective, we could just add Branch.inactive and not have the sftp server and update-rewrite script ignore inactive branches.
[03:54] <danilos> jordi: hum, ok, I don't have those messages by carlos :(
[03:54] <ddaa> Keeping the branch in the DB prevents re-using that id by another branch and helps with the "nothing can DELETE" policy.
[03:54] <lucasvo> ddaa: but then what happens when someone still uploads to them?
[03:55] <danilos> jordi: btw, I don't have write permissions on staging db, at least I don't think so (well, I don't know if I have the read permissions in the first place; stub?)
[04:07] <ddaa> If you mean "what happens is there is a concurrent sftp access while the branch is marked as inactive"
[04:08] <ddaa> lucasvo: then the answer is "the branch stays visible until the end of the sftp session, or until is deleted on the sftp back-end filesystem", whichever comes first.
[04:09] <ddaa> but it only stays visible in that sftp session
[04:09] <ddaa> it also stays visible on http until the rewrite map is updated (every few minutes, I believe)
[04:16] <bradb> happy mailman day all
[04:17] <kiko> hey bradb 
[04:17] <kiko> hey BjornT 
[04:17] <kiko> how are you guys doin
[04:17] <bradb> hey kiko, not too bad, actually
[04:17] <kiko> bradb, tooth stopped bothering you?
[04:17] <kiko> stub, has there been/will there be a rollout today?
[04:17] <bradb> kiko: still hurts, but the situation seems under control for now. rather than the texas chainsaw massacre dentist i was with before.
[04:17] <BjornT> hi kiko. it's going quite well
[04:18] <kiko> bradb, oh, another dentist?
[04:18] <bradb> yeah, with lasers!
[04:18] <kiko> ah, I thought the laser person was the same original dentist. heh
[04:18] <bradb> interestingly, TCM dentist saw *two* cavities in my mouth. the one today, and his hygenist, saw none
[04:19] <bradb> long live digital radiography
[04:19] <flacoste> bradb: that's because he had a payment to do on his chalet ;-)
[04:19] <bradb> flacoste: it was a she, but yeah
[04:19] <flacoste> bradb: his hygenist wasn't aware of that
[04:19] <bradb> the new guy with lasers is cool
[04:22] <jamesh> what do they do with the lasers?
[04:22] <jamesh> keep you distracted?
[04:22] <flacoste> kiko: how's my review going on?
[04:22] <kiko> flacoste, almost there, I'll have it sent today, just have to do my monthly report as well
[04:22] <flacoste> kiko: great!
[04:22] <bradb> jamesh: fillings without novocaine
[04:40] <cprov> kiko: hi, I hope you find sometime today to review bug #43802 solution you suggested, it's in you review section. It worked as expected ;) tks
[04:55] <kiko> cprov, which one? queue-ui?
[04:55] <cprov> kiko: buildd-ui
[04:56] <kiko> cprov, what branch I mean
[04:56] <cprov> kiko: that's the branch name
[04:57] <kiko> it's not on pending-reviews.. yet?
[04:57] <cprov> kiko: not yet
[04:57] <kiko> ah, ok
[05:06] <stub> kiko: Yes - earlier today. I just updated the wiki.
[05:06] <kiko> thanks stub, much appreciated.
[06:05] <jamesh> kiko: just hacked in web links for the current Python SF import (and made the importer support it)
[06:17] <Seveas> kiko, have you already mustered the guts (and found the time) to do the changes for Ubugtu?
[06:41] <robertj> hey all, is there a way to programatically access the information from launchpad?
[06:41] <kiko> moin
[06:41] <robertj> especially karma
[06:41] <kiko> jamesh, you rock!
[06:41] <kiko> robertj, what exactly are you looking for? the answer is not yet, but if you have an interesting feature proposal, maybe!
[06:41] <kiko> Seveas, good idea, I'll do them today.
[06:42] <robertj> kiko: I'm intersted in trust metrics and was thinking about building some test agents that relied on 3rd party datasources (probably advogato, ebay, and launchpad)
[06:43] <kiko> BjornT, jamesh: what's the story on FormLayout, btw? :)
[06:43] <kiko> robertj, what sort of query are you looking for? how much karma does such a person have? how would you specify who the person was? email address?
[06:44] <robertj> kiko: probably launchpad URL
[06:44] <robertj> internally anyway
[06:44] <robertj> externally by the launchpad id
[06:49] <kiko> robertj, well, you /can/ right now parse the HTML. and I can easily add an <id> tag for you to use
[06:49] <kiko> err
[06:49] <kiko> id attribute
[06:49] <robertj> kiko: that just seems naughty
[06:49] <robertj> ;)
[06:49] <robertj> but please do ;)
[06:49] <flacoste> after cleaning it, i now have 8 dead keys :(
[06:49] <kiko> sure. tell me what you would like, robertj, and I'll fix it up.
[06:50] <flacoste> i'll need to go buy a USB keyboard, so I'll be afk for a little longer
[06:50] <flacoste> unless anyone has a gerat keyboard resurrection trick
[06:51] <kiko> nope, go buy two spares <wink>
[06:51] <flacoste> lol
[06:51] <kiko> hey bradb 
[06:51] <kiko> tell me all about the guided filebug page
[06:51] <flacoste> if I'm lucky, I should get a new laptop by the end of the week, i ordered it last week
[06:52] <robertj> kiko: just adding id='karma' to the td would be great
[06:52] <flacoste> but, it really sucks that I blow this spare one just before getting the new one
[06:53] <flacoste> anyway, i'll now go eat and get a new keyboard
[06:53] <flacoste> c u later
[06:53] <robertj> or actually...
[06:53] <kiko> robertj, can you tell me exactly what page and element you're talking about
[06:53] <robertj> to reduce the numer of pages, adding a <span id='karma'> on https://launchpad.net/people/kiko
[06:55] <kiko> robertj, if you file a bug on launchpad, I'll do that just now. it'll be in production by next week.
[06:57] <robertj> bug #54818
[06:57] <Ubugtu> Malone bug 54818 in launchpad "add <span id='karma'> to karma on people page " [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54818
[06:58] <kiko> thanks robertj 
[06:58] <kiko> robertj, anything else simple that you want?
[06:58] <kiko> (that is related to that, as I'm going to be editing that page anyway)
[06:59] <robertj> kiko: confirmed email would be good I guess
[06:59] <kiko> robertj, you don't have that unless you're logged in and the person has chosen to disclose it
[06:59] <robertj> oh, nm then
[06:59] <robertj> is launchpad ever going to be opensourced?
[07:00] <kiko> it will be, but the time is not right for that yet
[07:00] <robertj> Is there a milestone or is it a "we will know"
[07:01] <robertj> also, is there a staging.launchpad.net or equiv?
[07:02] <kiko> there is a staging, yes
[07:03] <kiko> there's no milestone for opensourcing -- it has to do with success of launchpad (which may be a paradoxical goal, we realize)
[07:06] <robertj> kiko: it would be great to see launchpad be an openid provider, and at some point, an infocard minter as well
[07:07] <jamesh> robertj: we've talked about OpenID in the past.  I agree it is a good idea, but it isn't a priority at the moment.
[07:08] <elmo> JOOI, has there been any discussion of per-project theming of LP?
[07:08] <jamesh> not sure what an infocard minter is though
[07:08] <robertj> jamesh: Infocard is the windows identity bit shipping with Vista & it looks good
[07:09] <robertj> jamesh: you can self-issue cards or someone else like launchpad can issue them to you
[07:09] <robertj> and there is an eclipse working group called higgins that is issuing browser issue & server-side software
[07:10] <kiko> elmo, yes, there has -- we want to do it. Might happen first thing post 1.0
[07:10] <jamesh> ugh.  looks like it depends on a lot of WS-Crap
[07:10] <robertj> a new beta was issued breaking everything, but from what I understand hbx (the firefox extension) from cvs will work with live.windows.com
[07:10] <elmo> kiko: ah ok - was just curious - it's the most obvious difference between LP and some of the other python trackers
[07:10] <elmo> wannabe-trackers
[07:11] <SteveA> elmo: can you point us at an example of good per-project theming?
[07:11] <SteveA> or even poor per-project theming?
[07:11] <kiko> elmo, I mean, it would definitely make the pages a lot more familiar if there was a distinctive change when you were looking at ubuntu and looking at, say, python.
[07:11] <SteveA> as kiko says, we've talked about it and discussed with mark, but it would be nice to see examples of what others have done
[07:12] <elmo> SteveA: I don't know if it's "per-project", but when you look at the python wannabe-trackers, the roundup one stands out because it doesn't look live you've changed sites
[07:12] <elmo> I don't know of anything like LP or SF that is  multi-project and does per-project theming tho.  the roundup one is just a dedicated round up instance, IYSWIM
[07:12] <SteveA> I see -- you're talking about the entrants to the python competition
[07:13] <elmo> yes, sorry
[07:28] <robertj> kiko: is staging internal only?
[07:29] <kiko> robertj, no, but I hear it's currently down :-(
[07:29] <robertj> kiko: that's why I hear from my friend curl
[07:31] <elmo> deliberately?  if not, I can restart it
[07:32] <kiko> I'm not sure elmo. do you know, SteveA?
[07:33] <SteveA> no idea.  carlos was doing something on there, testing rosetta distro migration
[07:33] <SteveA> danilos:  any idea why staging is down?
[07:33] <danilos> SteveA: hum, no
[07:33] <danilos> SteveA: I haven't played with it since Friday
[07:34] <danilos> SteveA: has carlos been online today or yesterday?
[07:34] <SteveA> carlos is on vac
[07:35] <SteveA> ok, so staging can be restarted
[07:35] <elmo> done
[07:35] <bradb> kiko: the guided filebug page was started in London, with BjornT and I pairing on my malone-guided-filebug branch. BjornT offered to take it up after London, but other things came up.
[07:36] <kiko> bradb, is it your current task?
[07:36] <bradb> kiko: no, i've been working on release management.
[07:36] <elmo> heh
[07:36] <kiko> bradb, oh. I thought you had said that guided filebug would be done first?
[07:37] <elmo> it just oopses. that's probably why it's down ;-)
[07:37] <kiko> heh
[07:37] <SteveA> hmm
[07:37] <kiko> elmo, with session errors?
[07:37] <SteveA> wonder if it is the session db problem
[07:37] <SteveA> need to tail the logs to see
[07:37] <bradb> kiko: yeah, but then i assumed Bjorn was going to take up the branch, based on our convo in London, so i moved forward with release management. i could make it my current task.
[07:37] <elmo> ProgrammingError: ERROR:  permission denied for relation bounty
[07:38] <SteveA> ooh, big suck
[07:38] <bradb> (also tied up things like filebug xmlrpc, etc.)
[07:38] <kiko> bradb, I don't remember handing that work over to BjornT. It's not reflected on the spec page either
[07:39] <kiko> bradb, question is how much work have you done on releasemgmt?
[07:39] <bradb> kiko: first part is about 70% done. i think i'll have it up for review tomorrowish.
[07:39] <kiko> bradb, then fine, move ahead with it, come back to the other tasks later. what's first part, btw?
[07:41] <bradb> kiko: ok. first part is basically what we spec'd in london. no snazzy reporting, etc.
[07:41] <BjornT> bradb: iirc, i offered to take on the guided bug form if you wouldn't have time, but you said that you probably would have time for it.
[07:42] <kiko> bradb, cool though.
[07:43] <kiko> BjornT, salgado, matsubara-lunch: are there users in sampledata with no preferred email address?
[07:43] <salgado> probably
[07:43] <bradb> lots, i think
[07:44] <bradb> 38, it seems
[07:44] <salgado> yes, lots
[07:44] <kiko> can I have an id?
[07:44] <salgado> 3
[07:44] <kiko> launchpad id 
[07:45] <bradb>   3 | justdave
[07:45] <bradb>   4 | kamion
[07:45] <bradb>   5 | keybuk
[07:45] <bradb>   9 | kiko
[07:46] <kiko> aha!
[07:46] <kiko> heh, thanks
[08:07] <LaserJock> hmm, what would the product be for the librarian?
[08:09] <kiko> LaserJock, I think there's a librarian product, but file it on launchpad if you like
[08:13] <LaserJock> well, maybe you can tell me if this is a stupid idea or not
[08:13] <LaserJock> it's not really a bug, exactly
[08:13] <LaserJock> more wishlist
[08:13] <LaserJock> but when I go to a source package
[08:14] <LaserJock> and I want to download the files (.dsc, .diff.gz, and .orig.tar.gz) maybe because I need the source package from a different release
[08:14] <kiko> okay so far
[08:14] <LaserJock> each file has it's own librarian number
[08:14] <kiko> it does
[08:14] <LaserJock> would it be possible to just use 1 number / source package?
[08:15] <kiko> not easily, no.
[08:15] <LaserJock> k
[08:16] <kiko> the files are uploaded separately, and the librarian has no way of aggregating them
[08:16] <LaserJock> ok, then ignore me then ;-)
[08:16] <kiko> I wonder what you would consider to be a solution there.. offering a zipfile with the 3 items?
[08:17] <LaserJock> well, the reason I wanted to have the same number is I usually grab the file with wget rather than using the browser to save them
[08:17] <kiko> you could use wget and follow all links to the librarian. have you considered that?
[08:17] <LaserJock> if they had the same number then I can just quickly remove the file extention and get all 3 files very quickly
[08:18] <LaserJock> right now, I have to grab the URL for each file
[08:18] <LaserJock> hmm
[08:19] <kiko> hmmm
[08:20] <LaserJock> anyway, it's no biggy, I just found it was faster when I was grabbing stuff from debian because the files were in the same dir
[08:20] <LaserJock> and I wondered if that was possible with librarian or not
[08:21] <kiko> yeah, no directories in the librarian either
[08:21] <kiko> the fact is that the librarian has no idea that those files are related
[08:21] <kiko> only launchpad does
[08:22] <LaserJock> right, it just seems a little odd because I find LP to be very URL driven except for librarian which is basically random
[08:22] <LaserJock> but I suppose there are lots of good reasons to do that
[08:22] <kiko> mostly security-related
[08:22] <kiko> matsubara, is there a way of telling whether a code of conduct is current or not?
[08:23] <LaserJock> kiko: ah, never thought of that
[08:23] <kiko> right
[08:24] <matsubara> kiko: CodeOfConduct.current?
[08:24] <kiko> thanks
[08:29] <kiko> matsubara, is that guaranteed to be unique for the CodeOfConductSet?
[08:30] <matsubara> kiko: what do you mean?
[08:30] <matsubara> it checks the self.version against the hard coded version
[08:38] <gabaug> I want to create a bzr branch for f-spot that can be committed to by other f-spot devs...do I need to create a f-spot team to do that?
[08:39] <kiko> ddaa, ping?
[08:40] <ddaa> kikong
[08:40] <kiko> ddaa, see gabaug's question. if you send me a single-paragraph answer to that I'll add it to the FAQ as part of the checkin I'm about to do.
[08:40] <kiko> it's come up twice in the past 24h.. bazaar is growing up..
[08:41] <kiko> gabaug, I believe the answer is yes, though ddaa knows for sure.
[08:41] <ddaa> gabaug: the team does not have to be called something in specific, but otherwise, yes
[08:42] <gabaug> thanks
[08:43] <ddaa> kiko: that would be spoiling my fun
[08:43] <kiko> ddaa, please
[08:43] <ddaa> I love to answer "yes" when people ask "can I do Foo?"
[08:44] <ddaa> kiko: see https://launchpad.net/bazaar
[08:44] <ddaa> esp. the last paragraph of the "Hosted branches" section
[08:45] <ddaa> I think the context is important, because setting up a hosted branch on launchpad is not quite trivial
[08:45] <kiko> ddaa, thanks.
[08:46] <ddaa> but once you know how to do that, setting up a multi-committer branch is easy
[08:51] <kiko> ddaa, added an item to the FAQ. thanks!
[09:10] <gabaug> hey, so the bazaar page says "To set up a VCS import, edit the source details of the trunk release series     of the product."
[09:10] <gabaug> but I don't have permissions to access the source details page
[09:11] <kiko> gabaug, well, what project might that be?
[09:11] <bradb> kiko: I want to move the targetname fu into IBugTarget, instead of being on IBugTask, so that I can manipulate IBugNomination targets (and other places where IBugTargets are shown) in a consistent way for display. Any objections?
[09:11] <gabaug> kiko: f-spot
[09:12] <kiko> bradb, are you suggesting moving targetname to being target/name?
[09:12] <kiko> bradb, if so, no, you can't do that. FTI depends on it, for one.
[09:12] <bradb> kiko: IBugTarget.targetname
[09:12] <kiko> bradb, no, the column needs to be on BugTask.
[09:12] <bradb> .name would cause naming clashes.
[09:13] <kiko> gabaug, do you know who "Jamie Wilkinson" is?
[09:13] <gabaug> not really, but I need to talk to him I guess?
[09:13] <bradb> kiko: It can still be left on IBugTask, if needed for an optimization. it would just return .target.targetname
[09:13] <kiko> bradb, uhm, is this a storage question, or is it an API question?
[09:14] <kiko> bradb, I think you are confused.
[09:14] <bradb> kiko: API.
[09:14] <kiko> (or perhaps I am)
[09:14] <bradb> I'm pretty clear on what I'm asking, tbh.
[09:14] <kiko> gabaug, well, ideally yes. but what are you proposing to change in https://launchpad.net/products/f-spot/main
[09:15] <kiko> bradb, you're actually not. are you proposing moving the column targetname to the Product/Distribution/DSP?
[09:15] <gabaug> kiko: I just want to create a bzr branch for my personal (and team) development that is automatically synch'd to f-spot HEAD in gnome CVS
[09:15] <kiko> gabaug, well, it seems like an import has already been requested for f-spot -- have you checked that page? however, it seems to be currently failing.
[09:15] <kiko> ddaa, how do I find out why f-spot is failing?
[09:16] <bradb> kiko: there is no targetname column, there's a targetnamecache column though. i'm not proposing a db schema change at all.
[09:16] <gabaug> kiko: yeah, I see that...I don't know how that relates to what I want to do..could I get permission (and get my team permission) to edit that source?
[09:16] <bradb> i'm proposing that IBugTask is the wrong place for the attribute .targetname. IBugTarget is the right place for it.
[09:16] <kiko> gabaug, well, is something wrong with the current source information?
[09:17] <ddaa> kiko: usually, you would ask me (yes, we need to give real user feedback) but it's not a question I can answere right now because importd is in the middle of a major disruptive rollout
[09:17] <ddaa> though...
[09:17] <kiko> bradb, I don't understand what that would mean implementation-wise. I understand moving the attribute in the interface. Then what happens to the content class?
[09:18] <kiko> bradb, oh. hmm.
[09:18] <bradb> kiko: then ID, IP, and IDSP would each implement .targetname, removing the need for the mess that is _calculate_targetname
[09:18] <ddaa> ha
[09:18] <ddaa> it's bogus, the branch should be MAIN
[09:19] <ddaa> mh
[09:19] <ddaa> there's already something for MAIN somewhere in the db
[09:19] <kiko> ddaa, I can edit source! hallelujah
[09:19] <bradb> kiko: I point this issue out to you, since I noticed you had some interest in it previously:
[09:19] <bradb>     # XXX 2005-06-25 kiko: if target actually works, we can probably
[09:19] <bradb>     # nuke this or simplify it significantly.
[09:19] <bradb>     def _calculate_targetname(self):
[09:19] <ddaa> https://launchpad.net/products/f-spot/0.1
[09:19] <kiko> bradb, yeah, I know. you could follow target/name
[09:19] <ddaa> gabaug: is there something more you want?
[09:20] <bradb> target/name causes a namespace conflict
[09:20] <bradb> things that implement IBugTarget already have .name attributes
[09:20] <kiko> I know
[09:20] <ddaa> well, there should be a way to clear up the details on the /main branch, but the import appears working and up to date
[09:20] <kiko> bradb, however, it appears to me that _calculate_targetname just calculates another fancy displayname
[09:20] <bradb> technically, i guess this is a target_displayname attribute
[09:21] <kiko> bradb, right. so it could even be target.displayname
[09:21] <bradb> kiko: but that wouldn't have the "foo (upstream)" and such, which is somewhat helpful in the context of malone, imho
[09:22] <kiko> bradb, perhaps the product's  displayname should have (upstream) <wink>
[09:22] <bradb> maybe
[09:22] <bradb> erm
[09:22] <bradb> hm hm hm
[09:23] <kiko> so
[09:23] <kiko> well
[09:23] <kiko> bugtask still needs a targetname and that would essentially come from targetnamecache
[09:23] <kiko> I'm okay with _calculate_targetname using target.displayname
[09:24] <gabaug> ddaa, kiko: I'm new to bzr/launchpad...how can I work on f-spot patches with other people with those tools?  I'm quite confused at this point..do I just need to pull an existing bzr module?
[09:24] <kiko> bradb?
[09:24] <bradb> kiko: do you mean we should nuke the current targetname logic then in favour of whatever .displayname is already returning, or that we should move that logic into the respective .displaynames?
[09:24] <ddaa> gabaug: I suggest you ask general bzr questions on #bzr
[09:24] <kiko> gabaug, well, yes. just bzr branch http://bazaar.launchpad.net/~vcs-imports/f-spot/0.1
[09:25] <gabaug> kiko: and other people will be able to pull my changes and commit back to the same repo?
[09:25] <bradb> _calculate_targetname would no longer be necessary, since .targetname would now be a simple return self.target.somethingname
[09:25] <kiko> bradb, you still need targetnamecache.
[09:25] <kiko> bradb, so .targetname might as well return that.
[09:25] <ddaa> to share back your changes, you can "bzr push" your branch to launchpad, see https://launchpad.net/bazaar for instructions
[09:26] <gabaug> ddaa: but will that pushed branch be kept synchronized w/ f-spot HEAD?
[09:26] <kiko> gabaug, well, no. you will need to push your branch to launchpad.
[09:26] <bradb> kiko: true
[09:26] <ddaa> gabaug: no, you need to get your changes into the upstream CVS for that
[09:26] <kiko> gabaug, no. that pushed branch is /yours/. the branch at http://bazaar.launchpad.net/~vcs-imports/f-spot/0.1 will, however, stay imported.
[09:26] <kiko> gabaug, you will need to merge from the vcs-imports branch into yours periodically to stay up-to-date.
[09:27] <ddaa> gabaug: you should probably contact the f-spot developers (and jaq in particular) for details.
[09:27] <kiko> bradb, that's why I said it is more of an implementation question than an API question :)
[09:27] <gabaug> I *am* an f-spot developer
[09:27] <ddaa> ha ok
[09:27] <gabaug> we are feeling restricted by gnome CVS and I was looking for a way to improve our dev process
[09:27] <kiko> oh
[09:28] <ddaa> that's great news
[09:28] <gabaug> this seemed promising at first, but I think that's because I misunderstood it
[09:28] <kiko> gabaug, are you considering moving from gnome CVS to bazaar completely?
[09:28] <bradb> kiko: as long as you think it's okay to fold the targetname logic into .displayname...! i though IBugTarget.targetname was a safer approach, but...
[09:28] <gabaug> kiko: no, just for collaborative patch development
[09:28] <gabaug> as opposed to sending updated patches back and forth over e-mail
[09:28] <kiko> bradb, it's safer. you can probably use targetname...
[09:28] <kiko> gabaug, and you can. 
[09:28] <kiko> gabaug, the model is:
[09:29] <kiko> a) the vcs-imports branch is synchronized to CVS HED
[09:29] <kiko> b) each developer creates his own branch based on the vcs-imports branch
[09:29] <kiko> c) developers can commit to their personal branches, and merge patches between each other's branches
[09:29] <bradb> kiko: ok
[09:30] <kiko> d) when an approved patch is finally reached, somebody commits that patch to CVS HEAD
[09:30] <kiko> e) everybody does another bzr merge from vcs-imports to grab the latest goodies
[09:30] <kiko> ddaa, is that about right? :)
[09:31] <ddaa> gabaug: kiko is correct
[09:32] <ddaa> gabaug: you probably want to look at http://bazaar-vcs.org/BzrForCVSUsers
[09:32] <bradb> 33C, phew
[09:32] <salgado> can't the last step cause spurious conflicts?
[09:32] <kiko> not spurious
[09:32] <kiko> conflicts because you modified the same files in different ways.
[09:33] <kiko> salgado, however, if you were working on that feature, you should probably have a separate branch for it.
[09:33] <kiko> that way you can throw away your branch after it has been merged upstream, and start a new one.
[09:33] <kiko> #@!*#&@*($UIWYWHUI
[09:33] <kiko> modem users!!@@
[09:34] <ddaa> That's the sort of thing we need a bzr community guy for.
[09:35] <ddaa> I cannot spare the cycle to really figure out what's going on with f-spot, and to give them the help they need to be happy.
[09:35] <kiko> ddaa, docs would probably solve /this/ problem 99%
[09:35] <kiko> I'm happy to do the remaining 1%
[09:35] <salgado> I mean, the changes that went to CVS HEAD are in your branch too. when you merge from the branch that is synced from HEAD, will bzr do the right thing, detect you already have the changes and tell you everything is fine?
[09:36] <kiko> salgado, possibly not -- and the maintainer may have modified your patch before committing. see my comment on throwing away the feature branch.
[09:36] <ddaa> kiko: it's more involved than that you appear to think, but so far that appears to be a standard use case. Docs would certainly help.
[09:37] <kiko> yeah, maybe I'm just biased by the questions I see here.
[09:37] <kiko> but it's necessarily complicated, and docs are a boon when things are necessarily complicated.
[09:37] <ddaa> One of the things that are needed for this sort of thing to happen well is to teach a local expert with the issues, and help people find the best workflow for their project.
[09:38] <kiko> that's a lot of local experts.. 
[09:38] <ddaa> there's a lot of effort involved in Total World Domination
[09:39] <kiko> docs are the only way to scale up to that number of experts though
[09:39] <ddaa> But docs are like pizza.
[09:39] <ddaa> When it's good, it's really good. When it's bad, it's better than nothing.
[09:39] <kiko> that's not pizza. that's sex!
[09:40] <ddaa> My gf disagree that the later applies to sex,
[09:41] <ddaa> I think saying that of sex is an excessively gender-biased position.
[09:41] <bradb> better-than-nothing sex sounds pretty bad
[09:41] <ddaa> ever had a really bad pizza?
[09:41] <ddaa> better-than-nothing sex is even worse
[09:42] <kiko> we all have our standards
[09:42] <bradb> pizza's like poutine: cheese, fat, and more fat is hard to get wrong
[09:43] <ddaa> Vladimir Poutine looked pretty slim the last time I saw a picture of him.
[09:43] <ddaa> Though he's arguably cheesy.
[09:43] <kiko> http://www.thumper.net/tlkmag/archive/fun/poutine/
[09:43] <kiko> and that was a really bad joke
[09:43] <bradb> heh
[09:49] <kiko> salgado, ping?
[09:50] <salgado> kiko, pong
[09:50] <kiko> salgado, can you review a mostly-template-only change that improves UI for some simple things?
[09:52] <salgado> kiko, sure, where's it?
[09:52] <kiko> salgado, finishing a test for it.
[09:55] <ddaa> looks like roomba is okay
[09:55] <ddaa> now, let's do hoover
[10:09] <kiko> salgado, https://sodium.ubuntu.com/~andrew/paste/fileBaTdyM.html
[10:13] <kiko> salgado, review for your patch sent, btw
[10:17] <salgado> kiko, what's that "mostly-template-only" patch for?
[10:17] <kiko> salgado, improve UI for small niggling things: deactivated accounts, code of conduct signing and display of information. Also fix bug 54818 to appease end-users.
[10:17] <Ubugtu> Malone bug 54818 in launchpad "add <span id='karma'> to karma on people page " [Low,Confirmed]  http://launchpad.net/bugs/54818
[10:17] <kiko> salgado, it also adds a few faqs
[10:17] <kiko> salgado, and updates a test to be based on testbrowser.
[10:19] <kiko> salgado, it handles the use case "Launchpad automatically created an account for me. what now?"
[10:25] <laszlok> jordi: two PO files i just uploaded are saying "Needs Review", should i just wait?
[10:59] <matsubara> BjornT: around?
[11:00] <BjornT> matsubara: a little, i'm about to go to bed
[11:03] <matsubara> BjornT: I just need to check with you about a bug watch that is not up to date, but it can wait until tomorrow.
[11:14] <kiko> matsubara, use email.
[11:14] <kiko> (how many times will I have to say that)
[11:14] <kiko> (before my fingers fall off)
[11:18] <bradb> (whitebox testing)--
[11:22] <kiko> danilos, is carlos on vacation?
[11:23] <bradb> holiday/expense system?
[11:23] <kiko> checking..
[11:23] <bradb> that thing needs a name badly
[11:23] <kiko> yeah, he is.
[11:23] <kiko> danilos, are you taking requests? :-)
[11:37] <kiko> salgado, how's it lookin?
[11:37] <salgado> eh?
[11:38] <ddaa> kiko: are you aware that webapp.urlappend does entirely the wrong thing with sftp urls?
[11:38] <kiko> ddaa, did I do something wrong with it? I'm not aware no
[11:39] <ddaa> >>> from canonical.launchpad.webapp.url import urlappend
[11:39] <ddaa> >>> urlappend('sftp://foo/bar/', 'baz')
[11:39] <ddaa> 'baz'
[11:39] <ddaa> works right with http though
[11:40] <kiko> that's most odd
[11:41] <ddaa> took me a little while to figure out what broke importd...
[11:44] <ddaa> Behold a brave new bzr-native importd!!!
[11:45] <ddaa> It's only been in the works for, what? 15 months?
[11:45] <ddaa> no has come the time to garbage-collect pybaz!!!
[11:45] <ddaa> muhuwhahahaha!
[11:45] <bradb> kiko: do you want to review my IBugTarget.targetname change? it removes more code than it adds.
[11:46] <bradb> 11 files changed, 83 insertions(+), 131 deletions(-)
[11:46] <bradb> it's straightforward, mostly moving existing code into more appropriate places