[01:20] <Ubugtu> New bug: #89760 in launchpad "In LP Beta: Tabs in the Milestones doesn't work" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89760
[01:23] <pochu> heya, nice report :)
[01:23] <kiko> :)
[01:24] <LaserJock> hi kiko 
[01:24] <pochu> kiko: you are like my laptop ;)
[01:24] <kiko> hey LaserJock 
[01:24] <kiko> pochu, it never sleeps? :)
[01:24] <pochu> kiko: my laptop or me? :)
[01:24] <kiko> LaserJock, I will have free slots to give the MOTU bug list attention this week
[01:24] <LaserJock> doesn't suspend right? ;-)
[01:24] <kiko> rejoice!
[01:25] <LaserJock> kiko: awesome!!
[01:26] <ajmitch> kiko: thanks!
[01:28] <kiko> I am today finishing a report which is, oh, THREE MONTHS late
[01:28] <kiko> this will be a big weight off my back
[01:28] <kiko> phew!
[01:29] <ajmitch> and I thought I had problems with a report 4 days late :)
[01:30] <LaserJock> ajmitch!!
[01:30] <ajmitch> yessir?
[01:33] <kiko> ajmitch is the man
[01:34] <LaserJock> that he is
[01:34] <ajmitch> hm
[08:19] <carlos> morning
[10:24] <lifeless> how do I get to a non-beta URL ?
[10:24] <lifeless> I need to tell someone how to do something with regular launchpad
[10:25] <lifeless> but it keeps redirecting, so I cant see what that looks like
[10:25] <ddaa> lifeless: go to launchpad.net root
[10:25] <ddaa> and click "disable redirection"
[10:27] <dneary> Hi all
[10:28] <dneary> I uploaded a .pot and a bunch of .po files on Friday, they're listed as Accepted, but there are no translations on the branch in question - anyone know why that might be?
[10:28] <dneary> (for the 2.1 branch of qtwengophone)
[10:28] <ddaa> carlos: danilos: ^
[10:29] <carlos> dneary: the problem is that we didn't implement a way to give priority to those imports over Ubuntu ones and we are opening Feisty for translations right now, so the amount of files to import is huge....
[10:30] <lifeless> ddaa: thanks!
[10:31] <dneary> carlos: Ah, OK
[10:31] <dneary> I didn't understand that Friday, but I get it now
[10:31] <dneary> carlos: Isn't that a flaw in the system, though?
[10:31] <carlos> yeah, that's why I said 'we didn't implement...'
[10:31] <dneary> It makes us non-Ubuntu projects feel like second-class Launchpad citizens
[10:32] <dneary> OK, thanks
[10:32] <carlos> well, it's not that Ubuntu has priority
[10:32] <carlos> it's just that we are importing a lot of files at the same time
[10:32] <ddaa> it's just that it's first come first served
[10:32] <ddaa> and that ubuntu is a very big guy with a very large plate
[10:32] <carlos> ddaa: right, thanks
[10:34] <dneary> OK
[10:34] <carlos> dneary: the idea is give non ubuntu projects priority over Ubuntu, so this kind of huge imports doesn't affect you
[10:34] <dneary> Any idea when the ETA for those imports to be finished is? Can you see the state of the queue?
[10:34] <carlos> https://beta.launchpad.net/translations/imports/+index?target=all&status=APPROVED&type=all
[10:34] <carlos> https://launchpad.net/translations/imports/+index?target=all&status=APPROVED&type=all
[10:34] <dneary> Will they be done by Wednesday?
[10:34] <carlos> sorry, use the second link
[10:35] <carlos> that's how the queue is atm
[10:36] <dneary> https://launchpad.net/translations/imports/+index?target=products&status=APPROVED&type=all
[10:36] <dneary> Woohoo! I'm first in the queue
[10:36] <carlos> dneary: I hope, I'm asking some DB magic to mitigate the problem as it's taking much more time than expected but at current rate, it would still take a couple of days
[10:36] <dneary> But I have no idea where I am in the "all files" queu
[10:36] <carlos> dneary: for products, yes ;-)
[10:36] <carlos> the problem is that the distros queue is the same
[10:37] <carlos> dneary: I guess you are near the end of the queue
[10:37] <carlos> it's sorted by date
[10:37] <dneary> carlos: I also uploaded a .tar.gz of .po files through https://translations.launchpad.net/wengophone/2.1/+translations-upload - but I don't see them in the queue
[10:38] <carlos> dneary: If you used that URL, the files are pending to be approved
[10:39] <dneary> Yes, I see them: https://launchpad.net/translations/imports/+index?target=products&status=NEEDS_REVIEW&type=all&start=75&batch=75
[10:39] <dneary> I have a quick question - how do people manage merges between Launchpad files and their files?
[10:40] <dneary> cron jobs?
[10:40] <dneary> Regular manual imports/exports?
[10:40] <dneary> How do you handle the string changes in svn conflicting with translations in launchpad?
[10:40] <carlos> right now?, manual exports. To do uploads, some use scripts (like the ones I think you were testing)
[10:40] <dneary> carlos: Yeah - I don't think that the scripts are very effective
[10:41] <dneary> And we also script downloads
[10:41] <dneary> Using a regexp on webmail :)
[10:42] <carlos> well, the thing is that the maintainers should cope with those conflicts as we recommend to point to Rosetta as the place to publish the .po files. You can download and then upload the file later without using the web translation form.
[10:42] <carlos> having two persons translating one on svn
[10:42] <carlos> and another in Rosetta
[10:42] <carlos> is a source of conflicts
[10:42] <carlos> either both use SVN or both use Rosetta
[10:43] <carlos> dneary: we are planning a better way to integrate translations with source trees (other than current mechanisms) but it's still in design phase
[10:45] <ddaa> f
[10:50] <Ubugtu> New bug: #89833 in malone "+editstatus entry point surprising" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89833
[11:02] <lifeless> reviewer meeting now
[11:02] <BjornT> i'm here
[11:03] <spiv> I'm here.
[11:07] <lifeless> == Agenda ==
[11:07] <lifeless>  * Roll call
[11:07] <lifeless>  * Next meeting
[11:07] <lifeless>  * Queue status.
[11:07] <lifeless> ok
[11:07] <lifeless> spiv: ?
[11:07] <lifeless> SteveA: ?
[11:07] <lifeless> jamesh: ?
[11:08] <spiv> I'm here.
[11:08] <spiv> Ah, lifeless just phoned.
[11:08] <spiv> His net connection is down.
[11:09] <spiv> So I guess I'll run the meeting in the meantime.
[11:09] <spiv> SteveA: still recovering from the flu, I guess?
[11:09] <spiv> jamesh: here?
[11:09] <jamesh> spiv: yeah
[11:09] <spiv> jamesh: don't labour too hard :)
[11:10] <spiv> Ok, next meeting...
[11:10] <lifeless> its just come back
[11:10] <spiv> Ah, great.
[11:11] <lifeless> thanks though!
[11:11] <spiv> Not a problem.
[11:11] <lifeless> so, we're splitting the meetings in two
[11:11] <lifeless> I propose the .au themed one be 4pm (GMT+11) which should be within Bjornt's working hours
[11:11] <spiv> Yes please!
[11:11] <lifeless> and if BjornT can be kind enough to attend both, we can keep consistency.
[11:12] <lifeless> if thats too early for BjornT, then 5pm(GMT+11)
[11:12] <lifeless> BjornT: what do you say?
[11:13] <BjornT> lifeless: au 4pm is 7am for me, so i'd prefer 5pm
[11:13] <lifeless> np
[11:13] <spiv> That's fine with me.
[11:13] <lifeless> all in objection, type something now
[11:14] <lifeless> BjornT: please coordinate a time with the non .au reviewers that is convenient for you, and update teh https://launchpad.canonical.com/ReviewerMeetingAgenda?action=edit with that
[11:14] <spiv> lifeless, BjornT: thanks!
[11:14] <BjornT> lifeless: sure
[11:14] <lifeless> BjornT: are you willing to chair that meeting? or just be present ?
[11:15] <BjornT> lifeless: i can chair the non-au one.
[11:15] <lifeless> cool!
[11:15] <lifeless> ok, queue status (one second while I note this down)
[11:17] <lifeless> jamesh: can you look at david/launchpad/complete-revisions-landing - the review metadata for it
[11:17] <lifeless> jamesh: I think its not 10 days old, and something fishy has happened
[11:17] <lifeless> and yes, yes you do
[11:17] <jamesh> lifeless: he probably backdated it when adding it
[11:17] <jamesh> lifeless: or changed the URL
[11:18] <lifeless> you also have a branch of marks, and flacoste has a branch of tims that are getting old
[11:18] <lifeless> BjornT: can you nag flacoste :)
[11:18] <BjornT> sure :)
[11:18] <lifeless> spiv: your branches - how are they looking ?
[11:18] <lifeless> specifically flacoste-..
[11:19] <lifeless> jamesh: have you landed my patch to the pending-reviews yet ?
[11:19] <spiv> I only have one :)
[11:19] <spiv> I'll do flacoste's tonight.
[11:19] <jamesh> lifeless: not yet
[11:19] <lifeless> spiv: you'll have more for tomorrow :)
[11:19] <lifeless> jamesh: :(. 
[11:19] <spiv> lifeless: well, I can't comment on that today :)
[11:20] <lifeless> thats good
[11:21] <lifeless> there are 13 open reviews
[11:21] <lifeless> but jamesh is back from sprint now
[11:21] <lifeless> and noone else is on leave AFAIK
[11:24] <lifeless> are you still doing 2 reviews a day ?
[11:25] <spiv> I have been a bit lax on the 2/day front.
[11:25] <BjornT> me too, although i generally review the branches before the get 2 days old.
[11:26] <lifeless> ok,
[11:26] <lifeless> what I'll do for the next week is stack your queues deep
[11:26] <lifeless> that way, we wont have the low bandwidth-latency multiplier effect :)
[11:26] <ddaa> I think the new folks need some mentoring about focus and small branches...
[11:26] <spiv> +1
[11:27] <lifeless> jamesh: it will help me immensely to deploy my pending reviews update
[11:27] <jamesh> lifeless: yep.  I'll get onto it tomorrow
[11:27] <lifeless> thank you
[11:27] <lifeless> thats all from me
[11:27] <lifeless> anything new ?
[11:28] <lifeless> ddaa: how old is david/launchpad/complete-revisions-landing
[11:28] <BjornT> nothing from me
[11:29] <ddaa> lifeless: put it up for review on thursday
[11:29] <ddaa> had been work-in-progress for some time before
[11:29] <lifeless> ddaa: you did something strange when you did that
[11:29] <ddaa> just moved it around, and changed work-in-progress to needs-review
[11:29] <lifeless> ddaa: do you recall what it was ? (Did you change url? change the timestamp?)
[11:29] <ddaa> ha, yes, changed url
[11:30] <ddaa> complete-revisions -> complete-revisions-landing
[11:30] <lifeless> ddaa: please dont do that, the system is primitive and trivially breakable
[11:30] <ddaa> made it depend on recent rocketfuel, instead of cherrypickable...
[11:30] <lifeless> new url + old timestamp -> looks like its been unallocated for 10 days
[11:30] <ddaa> s/cherrypickable/mergeable in production/
[11:31] <ddaa> hu, okay sorry...
[11:32] <lifeless> ddaa: so either just make a new entry, or keep the url please
[11:33] <ddaa> gotcha, url == id
[11:33] <BjornT> carlos: you added your firefox-import branch as needs-review on PendingReviews
[11:33] <carlos> hmm
[11:34] <carlos> sorry, I forgot to change the status
[11:34] <carlos> thanks for the warning
[11:38] <lifeless> thanks for coming, metting over
[11:43] <BjornT> spiv: could you take a quick look at the changes in test_acceptance.py in https://devpad.canonical.com/~jamesh/pending-reviews/jml/launchpad/fix-intermittent-test/full-diff
[11:43] <BjornT> spiv: just to make sure that the changes look semantically correct
[11:45] <spiv> BjornT: ok, I'll take a look now
[11:45] <BjornT> thanks spiv
[11:47] <spiv> BjornT: I don't know why he does joinThread in the deferToThread decorator.  It should be redundant.
[11:49] <spiv> BjornT: he never sets _bail_registered to True!
[11:51] <BjornT> yeah, i was going to comment on that :), and also propose another way of doing it.
[11:51] <spiv> BjornT: The basic transformation of test_* methods looks sound, though.
[11:52] <BjornT> spiv: ok, thanks. i'll include your comments about joinTread.
[11:53] <spiv> BjornT: please feel free to require lots of explanation about anything that's unclear.  I'm familiar with Twisted testing idioms, and also discussed this with jml a fair bit over VOIP, but ideally this should be comprehensible to more than just two people :)
[11:54] <BjornT> spiv: i will :)
[11:55] <spiv> BjornT: The trick here is that TrialTestCases allow test methods to return a Deferred to wait for, and the framework will keep running the Twisted reactor until that Deferred is called back.
[11:56] <BjornT> yeah. i remember that from having reviewed one of salgado's branches that did the same.
[11:56] <spiv> So now he's running the two twisted services in-process, and waiting for events from them to determine test completion, and to avoid blocking the event loop he's running most of the assertions and bzr client code in a seperate thread.
[11:57] <spiv> Incidentally, jml says that these tests take a minute less to run now they don't need to spawn subprocesses :)
[11:58] <SteveA> morning
[11:59] <spiv> I'll probably apply the same sort of changes to the authserver and librarian tests eventually, so they can avoid subprocesses too.
[11:59] <BjornT> spiv: and that's the reason for having to run TrialSuite()._bail() at exit?
[11:59] <spiv> The reason for that really deserves a honking great comment.
[12:00] <spiv> That arranges for the Twisted reactor to get shutdown, which in turn means that it's threadpool is stopped.  Otherwise, the process hangs indefinitely at exit because of non-daemonic threads.
[12:00] <BjornT> there's an XXX that has the beginning of a comment for it, but it doesn't include the end of it :)
[12:01] <spiv> Ah, heh, so there is.
[12:20] <Ubugtu> New bug: #89846 in soyuz "binary ancestry calculation broken for new binary packages" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89846
[01:00] <cprov> good morning
[01:27] <Znarl> stub, lifeless, SteveA : Ping?  gandwana Launchpad Apps Server [1/2]  is down.
[01:48] <kiko> wake up gandwana 
[01:49] <SteveA> stub, lifeless, Znarl: is anyone else working on gandwana?
[01:50] <Ubugtu> New bug: #89854 in launchpad-bazaar "codebrowse fails with infinite redirections" [High,Confirmed]  https://launchpad.net/bugs/89854
[02:14] <sinzui> Hello. I am Curtis Hovey. This is my first day on the Launchpad team. Anyone have a clue-by-4 to point me how I start my day?
[02:15] <bac> good morning curtis and welcom
[02:15] <bac> welcome, i mean
[02:15] <spiv> sinzui: welcome
[02:16] <spiv> sinzui: I'm about to go to bed, but bac, SteveA or kiko ought to be able to sort you out.
[02:17] <bac> sinzui: sure i'll give you a hand
[02:17] <sinzui> spiv: thanks. As I thought
[02:18] <jordi> welcome sinzui!
[02:19] <bac> sinzui: i just sent you a private message -- you see it?
[02:20] <sinzui> bac: no :(
[02:22] <bac> sinzui: you use IM or skype?
[02:22] <sinzui> bac: gaim
[02:23] <sinzui> bac: my message to you didn't show. back to x-chat
[02:23] <Hobbsee> bac: you're not identified.
[02:23] <Hobbsee> bac: you need to be identified to freenode to send private messages.
[02:25] <bac> Hobbsee: thanks
[02:25] <Hobbsee> bac: no problem, need help with registering/identifying?
[02:26] <SteveA> sinzui: Welcome Curtis.
[02:26] <SteveA> kiko: ping
[02:26] <bac> Hobbsee: yeah i need to take care of that.  thanks for the reminder.
[02:26] <sinzui> SteveA: hi
[02:27] <Hobbsee> bac: /msg nickserv help should get you started :)
[02:27] <bac> SteveA: if you want i can help sinzui get started since it's all pretty fresh.
[02:32] <SteveA> sinzui: I just send you a standardized "welcome to canonical" message
[02:32] <sinzui> SteveA: thanks
[02:32] <SteveA> bac: sure, that would be great!  please do.
[02:33] <bac> sinzui: what is your AIM id?  until i get my freenode nick sorted out it may be best to move over to IM
[02:33] <sinzui> bac: CurtisHovey
[02:40] <SteveA> sinzui: did you get the email?
[02:40] <SteveA> sinzui: I got a bounce kinda thing from Verizon saying "UCE not wanted"
[02:40] <sinzui> SteveA: yes, I'm reading the wiki
[02:41] <SteveA> do you use Verizon?  want to see the bounce?
[02:41] <sinzui> SteveA: interesting. I Verizon doesn't like kiko either.
[02:51] <kiko> sinzui, your ISP is pretty horrible wrt incoming email. I have never once managed to email you directly :-(
[02:52] <sinzui> kiko: I'll look into switching my email though my domain provider. I get more control too
[03:07] <carlos> sinzui: you can get a POP3 account for canonical email
[03:08] <sinzui> carlos: I see that. I'm writing the request now
[03:08] <carlos> ok
[03:12] <statik> moin
[03:27] <BradCrittenden> statik: hello. how was your weekend?
[03:28] <statik> BradCrittenden: excellent, thanks. I think my brain melted a little from being immersed in another language. how was yours?
[03:29] <BradCrittenden> good.  nice weather mostly.  had a good time.
[03:29] <BradCrittenden> sorry for the absurdly long nick.  trying to resolve registration on the other
[03:35] <Ubugtu> New bug: #89866 in malone "Search bugs in all projects fails with an UnexpectedFormData error" [Undecided,Confirmed]  https://launchpad.net/bugs/89866
[03:46] <ddaa> barr1: ping
[03:47] <barr1> ddaa: pong
[03:47] <ddaa> barr1: got some time to talk about pyrex vs. ctypes?
[03:48] <barr1> ddaa: sure.  i've only dabbled, but i'll help if i can!
[03:49] <ddaa> barr1: I understand you talked about my use of pyrex to bind to libsvn with SteveA at Pycon.
[03:49] <ddaa> and that you suggested using ctypes instead of pyrex
[03:49] <ddaa> right?
[03:50] <barr1> yep
[03:50] <barr1> ctypes is a python 2.5 thing tho
[03:50] <UB`> hi
[03:50] <ddaa> So SteveA asked to have a talk with you about it.
[03:50] <UB`> i've a little problem 
[03:50] <UB`> I sent a bug message with a log pasted
[03:50] <ddaa> barr1: I haven't looked much at ctypes, but the reason I chose pyrex instead
[03:50] <barr1> thing i like about ctypes is that it comes w/py2.5 out of the box
[03:51] <UB`> but there are some security issues 
[03:51] <UB`> I have to edit that message
[03:51] <UB`> could you help me?
[03:51] <ddaa> is that ctypes is ABI-based, you need to somehow embed the definition of the ABI you are in binding to the Python code
[03:51] <ddaa> UB`: file a support request/question on the launchpad product
[03:52] <ddaa> pointing to the specific log message to edit
[03:52] <ddaa> or tell stub directly
[03:52] <ddaa> he's the database admin, and does things like excising stuff out of the db when there is no UI for it.
[03:53] <UB`> could I disturb him in private?
[03:53] <ddaa> barr1: while pyrex is API based, you just give it a high-level description of the API, and just as much as you need to bind to, and the compiler deals with the ABI.
[03:53] <ddaa> UB`: sure, removing security-sensitive data is reason enough
[03:53] <UB`> thank you
[03:54] <ddaa> barr1: also, most open source libraries, (including libsvn) really only document APIs
[03:55] <ddaa> and inferring the ABI out of the headers files can be a painful exercise
[03:55] <ddaa> I understand that ctypes is great when you need to bind to arbitrary windows APIs, where the ABI is known and very stable.
[03:55] <ddaa> where a compiler is not generally available, and turn-key operation is essential
[03:56] <ddaa> but I'm far from convinced it's a good fit for binding on linux
[03:56] <ddaa> barry: your turn :)
[03:57] <barry> ddaa: interesting. you've obviously looked at this stuff in more detail than i have.  i really only mentioned ctypes in passing, but it sounds like you have good reasons to prefer pyrex.  the only question is whether that outweighs the benefit of pyrex as an add-on dependency.
[03:57] <barry> s/benefit/cost/
[03:58] <ddaa> One thing I am assuming so far, is that there is no tool to automatically produce the ABI out of header files.
[03:59] <ddaa> that produces something usable by ctypes
[03:59] <barry> ddaa: i've not heard of anything, but i could make inquiries in the python community if you want
[03:59] <ddaa> since libsvn is incredibly anal about ABI compatibility, that would essentially negate my argument against ctype in this case
[04:00] <ddaa> barry: I'm interested in any input you may have.
[04:01] <ddaa> I'm not strongly committed to pyrex, and it does involve add a lot of cruft (the high-level API description)
[04:01] <ddaa> since the libsvn API is mind-bendingly complex
[04:01] <barry> i always like to reduce moving parts if possible, especially in favor of out-of-the-box support.  would it be useful to do try to do a limited a/b test of the two modules?
[04:02] <ddaa> what do you mean "a/b test of the two modules"?
[04:02] <barry> you probably already have a bunch of pyrex glue -- would it make sense to try to duplicate some of that w/ctypes and evaluate the cost/benefit for this particular application?
[04:03] <ddaa> I guess that would provide an interesting data point
[04:03] <ddaa> but I have two practical objections 
[04:04] <ddaa> 1. it's a lot of work that would have to be re-done for simple prospection
[04:04] <ddaa> 2. it will not be definitive since the really interesting APIs I want to bind to are not wrapped yet.
[04:05] <ddaa> so 2 just means that whatever the result, it will have to be considered with a grain of salt
[04:06] <ddaa> and 1 means that I will only be willing to go down that road if there is some hint that it's not going to be a lot of effort, or that it will indeed lead to interesting results
[04:06] <ddaa> for any pertinent value of "interesting"
[04:06] <barry> right. well, istm that you've looked at the technical issues in much more detail than i have, so i'm not sure i can add anything useful ;).  i'll be happy to help in any way i can though!
[04:06] <ddaa> barry: the point is, I did not look at ctypes much
[04:07] <ddaa> most of my argument is based on knowing there is a ABI/API dichotomy
[04:07] <ddaa> and having practical experience with the pyrex side of the problem
[04:07] <ddaa> so maybe I am entirely misguided :)
[04:08] <barry> ddaa: what's the best way to get the current pyrex bindings?  is there a bzr branch somewhere i can grab?  if so, perhaps i can look at that and try to do some ctypes bindings to get a feel for it, though i've never looked at libsvn
[04:08] <ddaa> barry: /code/david/cscvs/pyrex on devpad
[04:09] <ddaa> it's still very experimental
[04:09] <barry> cool, thx.  i'll also try to do a bit of research on the api/abi issue
[04:09] <ddaa> another data point that might be relevant:
[04:09] <ddaa> I have no interest in writing a general wrapper for libsvn
[04:10] <ddaa> it's more a framework than a library, and it's absurdly generic in some places
[04:10] <ddaa> so I am focusing on the simplest wrapper that does was cscvs needs
[04:10] <LarstiQ> ddaa: ctypese can be rather cumbersome, but being pure python is the final win for my opengl uses.
[04:11] <ddaa> LarstiQ: here you go :) well defined ABI, portability, no compiler available
[04:11] <LarstiQ> exactly
[04:12] <barry> ddaa: gotcha
[04:12] <LarstiQ> it also was much easier to get supports vectors out of libsvm with ctypes than with swig
[04:12] <ddaa> LarstiQ: pyrex is like skinning two headed goats using a silver knife under a full moon.
[04:13] <ddaa> it's scary and weird at first, but it does grow on you after a while
[04:13] <LarstiQ> ddaa: all the right conditions then
[04:14] <ddaa> which interestingly, is the opposite of svn, which is friendly and comfortable at first, but sends you mad after a while.
[04:14] <barry> ddaa: lol
[04:14] <ddaa> oops... sorry, did it again...
[04:16] <ddaa> LarstiQ: swig? OMG
[04:16] <ddaa> the native libsvn python bindings are done using swigs
[04:16] <LarstiQ> ddaa: current libsvm binding is written in that
[04:16] <LarstiQ> or, with
[04:16] <ddaa> current?
[04:16] <LarstiQ> extending it is painful
[04:16] <ddaa> official
[04:16] <LarstiQ> ddaa: right
[04:16] <ddaa> it's pretty much unmaintained
[04:17] <ddaa> except for the bits that jelmer had to beat into compliance to get actual work done...
[04:17] <LarstiQ> no no
[04:17] <LarstiQ> libsvm != libsvn
[04:17] <ddaa> ...
[04:17] <barry> btw ddaa: this kind of came up because of talks for bridging the svn/bzr gap.  i wanted to try the svn plugins for bzr, but found the mass of stuff i had to install and compile from source on my mac was just overwhelming
[04:18] <ddaa> barry: pretty much directly caused by upstream bindings being a steam pile of unmaintained swig insanity.
[04:18] <barry> (my thinkpad was running some feisty daily build and was having trouble getting on the network at pycon)
[04:18] <barry> ddaa: yep
[04:18] <ddaa> which is largely why I'm getting into this whole mess to start with
[04:18] <ddaa> got no trust in upstream to maintain those bindings
[04:18] <LarstiQ> how did pycon go?
[04:19] <barry> ddaa: anything to make that mass easier to deal with
[04:19] <barry> LarstiQ: best one evar
[04:19] <barry> almost 600 people
[04:19] <barry> i'd say 50-100 sprinters after the conference proper ended
[04:20] <ddaa> barry: actually, the original cause was "I tried to fix the upstream bindings, but they broke me".
[04:20] <barry> ddaa: <snif> ;}
[04:20] <ddaa> steel pot / clay pot thing
[04:20] <LarstiQ> barry: cool
[04:21] <barry> ddaa: even though you can apt-get the bzr-svn plugin, it doesn't work.  building from source is a soul crusher
[04:21] <ddaa> *nod*
[04:21] <barry> ddaa: the high level goal is this:  several projects wanted to explore bzr but have their code in an svn repository, and have devs who don't live and breath revision control systems
[04:22] <ddaa> mh
[04:22] <ddaa> I can see how ctypes would be a good fit there.
[04:22] <barry> so what we want is something that will look and smell exactly like "svn" client to those devs while others can experiment with bzr, eventually touting the benefits, teaching others how to use it, and then eventually migrating them to use the bzr client
[04:22] <ddaa> provided there's something to help bridge the API-ABI gap.
[04:23] <barry> we talked about a bunch of alternative approaches, but i think they all had problems.  stevea mentioned something (i forgot the term) but a bzr server that also speaks svn
[04:23] <ddaa> bzr-svn is great. It got an amazing potential for getting through the back door.
[04:24] <ddaa> bzr-svnserve is also useful
[04:24] <barry> ddaa: i tend to think that would be idea because it wouldn't require moving the repo to start the transition
[04:24] <LarstiQ> it needs a lot more work though
[04:24] <barry> sorry, bzr-svn would be ideal i think
[04:24] <ddaa> but there's a whole spectrum of embrace-extend-bzrminate tools
[04:25] <ddaa> barry: completely agree
[04:25] <ddaa> and I agree that ctypes is what would be best to make bzr-svn rock
[04:25] <barry> yep.  it's definitely worth working on because i think there's a lot of interest in bzr, but also a lot of reluctance to just make the switch, especially because many projects have recently gone through a cvs->svn migration
[04:26] <barry> that's a lot of upheaval for a dev community
[04:26] <LarstiQ> yeah
[04:26] <ddaa> barry: you're preaching to the converted
[04:27] <barry> :)
[04:27] <ddaa> 1. bzr-svn to get the committers to switch to bzr one by one
[04:27] <ddaa> 2. bzr-svnserver to switch the server to bzr without bothering non-committers
[04:28] <ddaa> actually makes it a winning proposition for us to have big projects switch to svn
[04:30] <ddaa> barry: so, yeah. If you can come up with a practical way to bind to libsvn with ctypes, I'm willing to put my cscvs effort behind it.
[04:30] <barry> there's sort of two (or three) propaganda points you have to win: first, convince people that the 'd' in dvcs is a fundamentally better way to operate; 2) that it's worth the overhead to learn a new model and set of commands; 3) that you won't lose anything by switching (i.e. it's a pure win), and 4) bzr is as mature and stable as svn (i.e. you will never ever ever lose data in bzr)
[04:30] <ddaa> might make the cscvs work more costly than it has to be, but it would have a very positive externality.
[04:31] <barry> ddaa: agreed
[04:32] <ddaa> barry: actually, those all four points can go away with bzr-svn because it has the potential to make _trying_ bzr in situation near zero-cost.
[04:33] <ddaa> and experience shows than in any given project of significant size, you'll find at least one influential developer willing to try a DVCS.
[04:33] <ddaa> but often it's prevented by the interoperability watershed
[04:33] <barry> ddaa: agreed, although at some point you want people to move their data into bzr and turn off their svn repos. that requires a lot of confidence that your data is rock solid stable (i.o.w. it's part technical part evangelical)
[04:34] <ddaa> I think it's mostly (but not quite) a red herring.
[04:34] <barry> ddaa: another data point: we keep all the python.org files under svn (i do the same for all my personal servers).  that process has broken down for a number of reasons, so we've switched to bzr for all our etc files
[04:35] <ddaa> When people love and want to use a tool, they pretty much want to be convinced that switching is safe.
[04:35] <barry> ddaa: agreed!
[04:36] <barry> and as long as it's relatively speedy, or that whatever performance costs you incur are amortized over all your work (i.e. always branch into a repo)
[04:37] <ddaa> speed is another problem, got plenty of solutions and good work is being done
[04:37] <ddaa> the new formats are already enabling improvements in bzr-svn performance
[04:38] <barry> oh, and have you ever tried to put your os system files under svn?  what a royal pita.  requires you to hand edit .svn/entries files.   not fun
[04:38] <LarstiQ> barry: is bzr doing better at that?
[04:38] <ddaa> and you just have a handful of nutcases (linus and keithp leading the pack) who argue that a system needs to be designed for speed to be fast enough.
[04:39] <ddaa> I think these folks are overgeneralizing their specialized domain knowledge.
[04:39] <barry> LarstiQ: from what i've read on the python dot org mailing list over the weekend, yes it went much more smoothly.  we couldn't put / under bzr because it took too long, but putting /etc under bzr was quite acceptable.  and no ugly manual hacks required
[04:40] <LarstiQ> barry: cool. We haven't really focused on supporting it :)
[04:40] <barry> ddaa: i come from the gvr school of thought on optimization :)
[04:40] <ddaa>  /etc should be cool, not to wide, and mostly text
[04:40] <barry> oh and warsaw's law on performance: there's no performance problem that if ignored long enough won't eventually go away :)
[04:40] <LarstiQ> haha
[04:41] <ddaa> barry: not quite true here, there are some serious bottleneck is the current released bzr formats.
[04:41] <barry> kidding, but still :)
[04:41] <ddaa> and dumb-fs remote operation is always going to be slow
[04:41] <LarstiQ> ddaa: the main problem is permissions
[04:41] <ddaa> something to do with the speed of light...
[04:42] <ddaa> LarstiQ: right... some bored student should write a plugin for this.
[04:42] <barry> i'm thinking about moving my own system files under bzr at some point, but i'm really lazy with my sysadmin'ing these days.  i've been doing it too long to want to chance something that works
[04:43] <barry> oh, btw, while ihave you here.  is there any way to quiet down those "read knit index" messages and pages of dots when doing a branch operation?
[04:43] <ddaa> barry: export TERM=vt100
[04:43] <ddaa> emacs can deal with the control chars used for the bzr progress bar
[04:44] <ddaa> I assume you say that because you are using the shell-mode :)
[04:44] <barry> you are correct sir! :)
[04:45] <barry> thanks!
[04:45] <dneary> Hi
[04:45] <ddaa> carlos: danilos: ^
[04:46] <ddaa> dneary: I hope I'm not assuming too much :)
[04:46] <dneary> If a .pot has already been approved, and I upload some .pos, will they get put into the queue again, or will they be imported quickly?
[04:46] <dneary> ddaa: :-P
[04:46] <carlos> dneary: the .po files are already approved
[04:46] <Ubugtu> New bug: #57762 in launchpad-cal "Calendar subscription portlet shows lots of repeated subscriptions." [Medium,Fix released]  https://launchpad.net/bugs/57762
[04:47] <carlos> dneary: if you upload them into the .pot file's +upload page, and the .po files use the language code as its file name
[04:47] <carlos> the system will auto approve them
[04:49] <dneary> Do they get imported straight away, or they get added to the "approved" queue?
[04:50] <dneary> (the one with 37K files in it)
[04:50] <carlos> dneary: they are added to the Needs review
[04:50] <carlos> then, the script will detect that are already approved
[04:50] <carlos> and it will move them to Approved status
[04:50] <carlos> were will be imported
[04:51] <dneary> OK
[04:51] <carlos> but no, you will not be able to 'jump' the huge queue
[04:51] <dneary> Do I have to add a .pot file to a .tar.gz with .po files in it?
[04:52] <carlos> dneary: hmm, I know we needed it in the past, but I think it should work now
[04:52] <carlos> dneary: the system will tell you it
[04:53] <dneary> OK, thanks
[04:53] <dneary> (sorry for all these questions, by the way)
[04:53] <carlos> dneary: confirmed, it works
[04:53] <carlos> dneary: no problem at all
[04:54] <dneary> If I have a more recent .pot, and upload the .pot plus the .po files, does the new .pot need a human approval, or is it auto-approved?
[04:55] <carlos> if the .pot file is already approved, it's auto approved, yes
[04:55] <dneary> ok
[04:55] <dneary> thx
[08:05] <Ubugtu> New bug: #57109 in rosetta "Duplicated entries in /distros/ubuntu/+lang/xx" [High,Fix released]  https://launchpad.net/bugs/57109
[08:08] <bac> BjornT: can i ask you a quick question about malone and bugwatchers?
[08:10] <kiko> bac, you can ask me.
[08:11] <bac> kiko: hi. i've got a local LP and a local bugzilla so i can play with bugwatchers
[08:13] <bac> if i create a fake project XYZ and specify it uses an external bugzilla i thought i'd be able to open a bug and have it propagate to the external.
[08:13] <kiko> bac, okay so far.
[08:13] <bac> but this doesn't appear to be the case
[08:13] <kiko> bac, you can't file new bugs on products which don't use launchpad officially
[08:13] <kiko> however, you can add tasks on existing bugs.
[08:14] <bac> so if i had A in LP using malone with an upstream dependency on B which uses an external bugzilla, i could have a watcher from A to a bug in B?
[08:16] <Ubugtu> New bug: #57587 in malone "+bugcontact page has misleading information" [Low,Fix released]  https://launchpad.net/bugs/57587
[08:16] <kiko> bac, yes, though by upstream dependency you must mean "additional task".
[08:17] <bac> kiko: perhaps that's what i mean.
[08:17] <bac> i realize i need to play with it some more to formulate my questions.
[08:18] <kiko> bac, thing is, we shouldn't really allow you to file bugs on B in launchpad; you would be led to believe that B will actually do something with your bug (which it won't)
[08:19] <Theuni> LarstiQ: hmm. the 'bzr push sftp...' seems to hang
[08:19] <bac> kiko: ok.  i see that.  but if i open a bug against A in malone which becomes clear is really an issue in B, do i have to manually go to B's bug system and open a bug there?
[08:20] <kiko> bac, you do, yes. that's part of what "upstream forwarding" means
[08:20] <bac> kiko: ok.  that's my misunderstanding then.  i thought we could create a bug in the upstream tracker and automatically link to it
[08:20] <Theuni> ah. i've got an ssh timeout to bazar.launchpad.net but the read() doesn't pick that up and hangs
[08:21] <Ubugtu> New bug: #57571 in malone "Assigning a team as bug contact of a distro crashes if the team doesn't have a contact email" [Medium,Fix released]  https://launchpad.net/bugs/57571
[08:22] <kiko> bac, we can't push, no -- we need an account on the upstream system, first
[08:23] <bac> ok.  that gives me new ammo for playing with it.  thanks.
[08:24] <LarstiQ> Theuni: hmm
[08:26] <pochu> Theuni: isn't it bazaar? or it's that a typo?
[08:26] <Theuni> pochu: i'm just looking at what strace told me
[08:26] <Theuni> but that's what i've put in.
[08:26] <Theuni> might be a typo
[08:27] <Theuni> it's a bit weird that it times out though
[08:27] <pochu> Theuni: I think it should be bazaar, and not bazar
[08:27] <pochu> LarstiQ: ^
[08:27] <Theuni> pochu: jup. looks better
[08:27] <pochu>  i've got an ssh timeout to bazar.launchpad.net
[08:29] <LarstiQ> pochu: thanks for catching that :)
[08:29] <LarstiQ> yes, it's bazaar, not bazar
[08:29] <Theuni> How long does it take until an SSH key gets enabled, or do I have to do something else?
[08:29] <Theuni> (except uploading the key)
[08:33] <pochu> LarstiQ: np
[08:34] <pochu> LarstiQ: I wasn't sure, but that was strange to me :)
[08:34] <Theuni> I'm not getting 'Permission denied (publickey).
[08:34] <Theuni> s/not/now/
[08:35] <LarstiQ> Theuni: are you using the correct user to login? Ie, what launchpad knows you as.
[08:35] <Ubugtu> New bug: #89938 in malone "[beta]  Very difficult to unsubscrivbe from a package" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89938
[08:36] <Theuni> LarstiQ: uhhh. darn.
[08:37] <Theuni> hmm. i thought 'sftp://ct-gocept@' would take care of that.
[08:43] <Theuni> how can i convince bazaar to make the ssh verbose to check what goes wrong?
[08:44] <LarstiQ> Theuni: you could have a look at ~/.bzr.log
[08:44] <Theuni> doesn't help. gives me only the traceback of the ssh transport but not the output from the ssh
[08:48] <Theuni> actually i get the same error when doing a simple ssh and explicitly stating 'ct-gocept' as the username
[08:50] <carlos> see you all tomorrow!
[08:52] <thumper> ddaa: could you help Theuni?
[09:01] <Ubugtu> New bug: #49598 in malone "Unable to unsubscribe from private bug" [Medium,Fix released]  https://launchpad.net/bugs/49598
[09:04] <lamont> cprov: ^^??
[09:05] <lamont> kiko?
[09:06] <bac> Theuni: fwiw i just tried to ssh to bazaar.launchpad.net and got "Permission denied (publickey)", so it's not just you.  i suspect  that machine doesn't allow ssh logins, so it may be orthogonal to your original problem.
[09:08] <bac> lamont: me too.
[09:09] <bac> Theuni: what is the complete URL you are giving to bzr?
[09:11] <lamont> spiv/SteveA/mdz: any hints who knows about the current process for translations getting into launchpad from the buildds?
[09:11] <Ubugtu> New bug: #3186 in blueprint "New spec form has undescribed no-capitals constraint" [Medium,Fix released]  https://launchpad.net/bugs/3186
[09:13] <danilos> lamont: maybe I can help
[09:14] <danilos> lamont: though, I know little about buildd side of things
[09:14] <lamont> danilos: it's really a simple question... is ~lamont/translations still involved.  I believe (and have now asserted) that it is not.. 'twould be nice to know if that breaks anything before it really breaks it...
[09:16] <danilos> lamont: are you talking about ~lamont/+translations page? I am not sure I understand you
[09:16] <lamont> danilos: if you're not a launchpad back-end developer, it wouldn't make sense
[09:17] <lamont> in ancient times, translations were fetched from people.ubuntu.com/~lamont/translations to get them into LP...  It looks like that's been gone for sometime now (maybe since LP took over the archive)
[09:17] <Theuni> bac: this is the command i'm running
[09:17] <Theuni> bzr  push sftp://ct-gocept@bazaar.launchpad.net/~refreshng-dev/refreshng/trunk
[09:17] <lamont> given that google and yahoo are the only folks fetching the translations since late feb, I think I'm safe in not fetching them to people anymore, ...
[09:17] <danilos> lamont: translations need to be packaged to show up in launchpad
[09:18] <lamont> right.  and the question centers around the current process for gathering the translations from the buildd and packaging it up to throw at launchpad.
[09:18] <danilos> lamont: i.e. source packages need to include pot and po files, which is how they enter import queue; I haven't been working on LP long enough to know how it worked in the past
[09:19] <lifeless> Theuni: ssh keys enable instantly
[09:20] <danilos> lamont: are you actually preparing an ubuntu package? what is that you want to do?
[09:20] <mdz> lamont: infinity or carlos would probably be the best people to talk to about the details of that setup
[09:20] <lamont> danilos: what I want to do is stop running getTranslations.py on rookery since it tends to back up and have many copies running concurrently.
[09:21] <lamont> mdz: right - I'll make sure I didn't break it when I turned off my script on rookery a few min ago.. nearly certain it's no longer involved, and I'll confirm that.
[09:21] <bac> Theuni: you are authenticating as ct-gocept but trying to write to ~refreshng-dev's space.  do you have permission to do that?
[09:23] <lifeless> bac: there is a problemin the dc
[09:23] <danilos> lamont: I don't know what's getTranslations.py doing, but if POT and PO files end up in the source .tar.gz, that should be enough for launchpad to read the files in; checking with carlos tomorrow morning might be best, though
[09:23] <lifeless> bac: I'm looking at it now
[09:23] <lifeless> in fact, it seems happy now
[09:23] <lamont> danilos: right
[09:23] <lifeless> weird
[09:24] <lamont> lifeless: btw, uh.. happy b-day
[09:24] <lifeless> lamont: thanks!
[09:24] <lamont> I _MEANT_ to say something on the correct day, even.
[09:24] <Theuni> bac: i created that group. even if i put in ct-gocept instead of the group it fails.
[09:24] <lifeless> :)
[09:25] <lamont> more like un-birthday than belated birthday though.  my bad
[09:25] <lifeless> Theuni: you've added your ssh key to your account ?
[09:25] <Theuni> yup
[09:25] <Theuni> and i see it being used
[09:25] <lifeless> Theuni: try this:
[09:25] <lifeless> sftp username@bazaar.launchpad.net
[09:25] <lifeless> ls
[09:25] <lifeless> ^D
[09:26] <Theuni> still perm denied (public-key)
[09:26] <bac> lifeless: that doesn't work for me either
[09:26] <lifeless> whats your lp homepage ?
[09:27] <bac> lifeless: and i can do 'bzr push' to lp
[09:27] <lifeless> $ sftp bazaar.launchpad.net
[09:27] <lifeless> Connecting to bazaar.launchpad.net...
[09:27] <lifeless> sftp> ls
[09:27] <lifeless> ~admins                         ~baz-developers                 ~bugsquad                       ~bzr                            ~debian-opensync                
[09:27] <lifeless> ~launchpad                      ~launchpad-beta-testers         ~launchpad-bugs                 ~launchpad-security             ~lifeless                       
[09:27] <Theuni> https://launchpad.net/~ct-gocept/
[09:27] <lifeless> ~motu                           ~planet-ubuntu                  ~revu                           ~subunit                        ~ubuntu-bugs                    
[09:27] <lifeless> ~ubuntu-dev                     ~ubuntu-qa                      ~ubuntu-universe-contributors   ~ubuntu-universe-sponsors       ~ubuntumembers                  
[09:27] <lifeless> ~vcs-imports                    
[09:27] <lifeless> sftp> ^D
[09:27] <lifeless> bac: if that doesnt work, you cannot push to lp
[09:28] <bac> lifeless: indeed i can.
[09:28] <bac> lifeless: could it be an issue between local and LP usernames being different?
[09:28] <lifeless> bac: you might think so, but I assure you the code path is the same.
[09:28] <lifeless> note that what I asked Theuni to do was 'sftp username@bazaar.launchpad.net'
[09:29] <bac> lifeless: yes, i saw that
[09:29] <lifeless> your local account is not involved
[09:29] <bac> ls
[09:30] <Theuni> lifeless: and that's what i did (username being ct-gocept)
[09:30] <Theuni> is there a chance that the dash in the name is a problem?
[09:30] <lifeless> Theuni: please try again
[09:31] <lifeless> is the ip address you are trying from 212.72.145.97 ?
[09:32] <Theuni> i don't think so
[09:32] <Theuni> i'm not sure though
[09:32] <Theuni> other outside systems detect me as 75.13.110.34
[09:32] <bac> lifeless: here is my counter-example:
[09:32] <bac> bac@bac-edgy:/canonical/bac/bzr.dev$ bzr push
[09:32] <bac> Using saved location: sftp://bradcrittenden@bazaar.launchpad.net/~bradcrittenden/bzr/doc-cleanup/
[09:32] <bac> Enter passphrase for key '/home/bac/.ssh/id_dsa': 
[09:32] <bac> 1 revision(s) pushed.                               
[09:33] <bac> brb
[09:33] <lifeless> bac: and if you do 'sftp bradcrittenden@bazaar.launchpad.net' ?
[09:34] <bac> bac@bac-edgy:/canonical/bac/bzr.dev$ sftp bcrittenden@bazaar.launchpad.net
[09:34] <bac> Connecting to bazaar.launchpad.net...
[09:34] <bac> Enter passphrase for key '/home/bac/.ssh/id_dsa': 
[09:34] <bac> Permission denied (publickey).
[09:34] <bac> Couldn't read packet: Connection reset by peer
[09:34] <lifeless> did you enter the passphrase correctly ? :)
[09:35] <lifeless> bac: you changed the username
[09:35] <lifeless> bac: please copy and paste what I asked you to try
[09:36] <lifeless> Theuni: please try again, I'm tailing logs
[09:36] <Theuni> tried
[09:36] <lifeless> right, I see your attempt
[09:37] <Theuni> sounds creepy ;)
[09:37] <lifeless> it is getting a failed publickey error
[09:37] <lifeless> I'm ocmparing with a completely unknown user login
[09:39] <bac> lifeless: sorry -- on the phone at the moment.  back in a bit.
[09:39] <bac> but,yes, i entered the passphrase correctly
[09:39] <lifeless> Theuni: you might try changing your account name
[09:39] <lifeless> bac: yes, but you changed the username
[09:39] <lifeless> Theuni: I /dont/ think that the cause, but as its easy to test
[09:40] <lifeless> Theuni: also, have you got the correct part of your ssh key uploaded - you should have uploaded the contents of id_dsa.pub
[09:40] <Theuni> yup, did that.
[09:40] <Theuni> i'll try uploading again first, then change the username
[09:41] <Theuni> now it works
[09:41] <Theuni> weird
[09:41] <Theuni> same key
[09:41] <Theuni> looks also exactly the same in the upload
[09:41] <bac> lifeless: my bad.  used bcrittenden instead of bradcrittenden
[09:41] <bac> lifeless: sorry for contributing to the confusion
[09:41] <lifeless> bac: you didn't confuse me any :)
[09:41] <lifeless> bac: I suggest you add a ssh host line for bazaar.launchpad.net setting the username
[09:41] <lifeless> in your ssh config
[09:42] <lifeless> ciao, aikido time
[09:42] <Theuni> have fun and thanks!
[09:44] <Theuni> now i think i broke it otherwise
[09:44] <Theuni> I cancelled the push because it seemed to hang but the 'trunk' directory was created and new attempts to push just fail
[09:44] <Theuni> and i can't delete the trunk directory
[09:45] <salgado> Theuni, try "bzr push --overwrite ..."
[09:45] <Theuni> bzr: ERROR: File exists: u'/~refreshng-dev/refreshng/trunk': mkdir failed: unable to mkdir
[09:48] <lifeless> upgrade your bzr perhaps? we've made this more tolerant recently
[09:49] <Theuni> what version would recently be?
[09:50] <Theuni> i'm on 0.14
[09:52] <Theuni> looks like the latest release
[10:04] <Theuni> lifeless: can't get it working this way ... :/
[10:06] <Ubugtu> New bug: #89954 in malone "bug subscription inconvenient" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89954
[10:17] <ddaa> hello
[10:19] <Theuni> how do i get the code out of there after I did a bzr push?
[10:19] <Theuni> i thought i use the branch command but that says "not a brnach"
[10:20] <ddaa> Theuni: I can probably help you, but I see there had been a long discussion already and I do not have the context.
[10:21] <Theuni> that's alright the discussion up there is pretty much done.
[10:21] <Theuni> I've just finished a bzr push and wonder how to get it out of there again.
[10:22] <Theuni> ah
[10:22] <Theuni> this time it's called checkout
[10:23] <ddaa> are you disturbed that the command to upload data has a different name from the command to download data?
[10:23] <radix> Theuni: if you can pass a location to checkout you should also be able to pass it to branch
[10:24] <ddaa> actually, radix has a point, "bzr branch" can upload _and_ dowload data :)
[10:24] <radix> Theuni: they both fetch code, but "checkout" creates a bound branch which means commits go straight back to the location you checked out from, whereas with a branch commits are always local
[10:24] <radix> s/code/branches/ :)
[10:34] <Theuni> radix: interesting. however, i wasn't able to branch from the remote location
[10:34] <newz2000> a week or two ago, salgado made a change to https://launchpad.net/distros/ubuntu/+cdmirrors-rss and it made it to beta, I was wondering if there's any hope of getting that migrated to non-beta soon.
[10:35] <radix> Theuni: can you give me the URL that worked with checkout but not with branch? is it public?
[10:36] <Theuni> it's http://bazaar.launchpad.net/~refreshng-dev/refreshng/dev
[10:37] <radix> Theuni: branching that works here - maybe you tried branching when it hadn't yet been mirrored to the http server (there is a slight delay between pushing up to SFTP and having it appear on HTTP)
[10:37] <ddaa> on the order of a minute...
[10:37] <radix> ddaa: congrats on the speed improvements :-)
[10:38] <ddaa> radix: I mostly ran around telling people I needed them to do work urgently :)
[10:39] <Theuni> radix: ah ... ok. didn't know there was time-delayed caching involved ...
[10:39] <radix> it is getting closer and closer to unnoticeable
[10:39] <ddaa> Theuni: the place you upload to is not the place that's visible via http
[10:40] <Theuni> thought so after radix told me
[10:40] <Theuni> just didn't know beforehand
[10:40] <ddaa> basically so people cannot abuse it as a free hosting service
[10:40] <ddaa> for websites and such
[10:40] <radix> I think launchpad'd make a great music sharing site ;)
[10:40] <Theuni> hihi
[10:41] <ddaa> radix: don't spread the idea too much
[10:41] <ddaa> or we might require people to sign a disclaimer in blood before using it :D
[10:42] <ddaa> or worse
[10:42] <ddaa> send mneptok to get them
[10:44] <radix> heh
[10:58] <medders> just a quick question, can I submit a support request using emails?
[11:05] <Ubugtu> New bug: #89972 in launchpad "No link from Team overview to Products the team maintains" [Undecided,Unconfirmed]  https://launchpad.net/bugs/89972
[11:21] <Ubugtu> New bug: #5166 in rosetta "Improvement on locking translations" [Medium,Confirmed]  https://launchpad.net/bugs/5166
[12:10] <marienz> hi! I'm probably just being blind, but can someone point me to the link to the official bzrtools bug tracker I think I'm overlooking? :)
[12:10] <marienz> https://bugs.launchpad.net/bzrtools/+bugs lists the bugs in bzrtools, but the link there to "report a bug" tells me "bzrtools does not use malone as its bug tracker"
[12:11] <kiko> really now!
[12:11] <marienz> I'm assuming launchpad knows where its official tracker is, since it knows about those bugs.
[12:11] <kiko> let me take a look at those
[12:14] <Theuni> hmm
[12:14] <Theuni> Why can't I run 'bzr push' twice?
[12:14] <Theuni> I pushed successfully once from a branch I have on my notebook but I can't push a second time.
[12:14] <kiko> you can hopefully
[12:14] <lifeless> normally you can
[12:15] <Theuni> *ngngng
[12:15] <Theuni> oh. forget it. the broken trunk is still in the way. i used the wrong target.
[12:15] <kiko> maybe you could buy some food instead of damaging your hardware?
[12:15] <kiko> heh
[12:15] <Theuni> i'm chewing gently. buying food would make me put weight on. ;)
[12:16] <kiko> what broken trunk?
[12:16] <Theuni> of my product.
[12:17] <Theuni> i had a push that i cancelled in between and now that branch isn't accessible anymore
[12:17] <Theuni> i can't delete it and i can't overwrite it
[12:17] <kiko> I can't believe that problem is still not fixed
[12:17] <kiko> I thought jam had changed bzr to let us repush in that situation, lifeless?