[12:52] <jblack> Who is the expert on user accounts? 
[12:54] <spiv> jblack: How do you mean?  What do you want to know?
[12:54] <jblack> > (By the way, is there any way to change my username to 'jam' or
[12:54] <jblack> > 'jameinel' instead of the full john@arbash-meinel.com?)
[12:55] <spiv> There's a few things here.  Launchpad names don't contain "@".
[12:56] <spiv> But it's possible to login with your email address rather than your username, Launchpad's happy either way.
[12:56] <jblack> He probably thinks this because the login box accepts "john@arbash-meinel.com". 
[12:56] <spiv> Oh, hmm, maybe launchpad itself only takes email address.
[12:57] <spiv> Ah, yeah, launchpad.net only allows email addresses for logging in.
[12:58] <spiv> We could change that, although with browser form autocompletion, it's generally not a big issue.
[12:59] <spiv> (and existing email addresses have the advantage of being easier to remember than yet another login)
[01:01] <spiv> So, he could file a bug on Launchpad asking for it to be logging in by nickname to be allowed, rather than just email address.
[01:02] <spiv> I'm personally a little hesistant to support multiple ways of doing things, it can make things less usuable rather than more.
[01:04] <jblack> Since launchpad doesn't have a habit of allowing long-lived cookies, if his browser doesn't support saving form data then see where he could get annoyed. *Not that he is
[01:05] <spiv> Well, cookie lifetime is about to get bumped up to 60 days, I think.
[01:05] <jblack> 60 days may or may not be reasonable. I think its currently set for browser close.
[01:06] <spiv> It's currently about 12 hours, iirc.
[01:06] <spiv> We recently moved the session data into postgres so that it would be persistent across webapp restarts and the like.
[01:06] <jblack> You look correct. I just double checked.
[01:07] <jblack> "Don't oversleep! You could have to log in again!"
[01:09] <spiv> Heh.
[01:19] <jblack> bradb: ping
[01:21] <mpt> jblack, he's not here
[03:19] <dilys> Merge to devel/launchpad/: Remove an unnecessary LEFT OUTER JOIN from a query generated by the ValidPersonOrTeam vocabulary. r=kiko (r3028: Guilherme Salgado)
[03:44] <stub> lifeless: Is it ok for me to make multiple cherry picks in bzr, followed by a single commit? Or should I still merge, commit, merge, commit, merge, commit?
[03:47] <stub> bzr on balleny seems much, much faster
[03:51] <lifeless> stub: yes, I updated the snapshot
[03:51] <lifeless> late last week
[03:52] <lifeless> uhm, we dont record cherry picks as such at the moment
[03:52] <lifeless> so, do whatever is easiest.
[03:52] <stub> Doesn't really matter now that commit is quick ;)
[03:57] <stub> Does IO wait time (as reported by top) mean *just* sucking stuff from disk, or does it measure more than that under Ubuntu?
[03:58] <stub> c/sucking/sucking and stuffing/
[04:20] <lifeless> you mean the figure up the top ?
[04:24] <stub> Yup. The CPU percentage
[04:28] <lifeless> IIRC the 
[04:28] <lifeless> percentage of processes blocked on IO
[04:28] <lifeless> or something like
[04:28] <lifeless> where IO != disk alone
[04:31] <lifeless> thats pretty harsh
[04:31] <fabbione> Launchpad is offline at the moment for maintenance. It should be back, better than ever, soon. Thanks for your patience.
[04:31] <lifeless> its being upgraded
[04:31] <fabbione> should tell me that after i login
[04:31] <lifeless> HOW?!
[04:31] <fabbione> before i enter and change stuff?
[04:31] <fabbione> and push the "commit changes" button?
[04:32] <lifeless> its a web app - it wasn't offline before, now it is
[04:32] <fabbione> WEEEEEE
[04:32] <lifeless> we can't tell how many requests are outstanding
[04:32] <fabbione> you mean you just started the upgrade in the last 2 minutes?
[04:32] <lifeless> yes
[04:32] <fabbione> crap
[04:33] <fabbione> ok how long is going to take?
[04:33] <lifeless> stub: how long is the upgrade looking ?
[04:34] <lifeless> 20 minutes ?
[04:34] <stub> lifeless: Done
[04:34] <lifeless> stub: sweet. fabbione ^^
[04:35] <mpt> if we had ultra-persistent logins implemented, fabbione could now just click "Reload"
[04:35] <mpt> to resubmit the form
[04:35] <stub> I can get the downtime down to about 5 minutes for most upgrades now ;)
[04:35] <fabbione> mpt: that did work.. or it seems so
[04:35] <lifeless> stub: slick
[04:35] <lifeless> stub: benefits of automation ?
[04:36] <stub> lifeless: Benefits of planning, multiple app servers, and a more intelligent full text index rebuilder
[04:36] <mpt> stub, so "soon" can be changed back to "in a few minutes"?
[04:36] <stub> I'll be updating the rollout docs for 8.0 and the procedures
[04:36] <mpt> fabbione, cool
[04:36] <stub> mpt: I can't guarentee that ;) Some upgrades will still take a while depending on how much database stuff needs to happen
[04:37] <mpt> ok, how long is "a while"? :-) Within an hour?
[04:39] <stub> mpt: It really depends. Worst case would be about 1.5 hours I *think*, but I won't know for sure until we actually do that case on this hardware. If we have major data migration work to do, it can still be longer. We had one rollout where it took the scripts about 4 hours to run.
[04:39] <stub> mpt: We do have ultra persistent logins
[04:40] <stub> There is a bug open on that, because they are too persistent for people using shared computers
[04:40] <lifeless> 'logout' ?
[04:41] <mpt> was that introduced recently?
[04:41] <lifeless> yes
[04:42] <stub> mpt: We have had persistent logins for a week or two (persistent cookies, and the credentials remembered over server restarts). They used to time out after 12 hours, but this roll out bumped that up to 60 days.
[04:43] <stub> So if there are any more reports about people getting logged out, either their browser or proxies are screwing them over or we have an undiscovered bug lurking that will be a real pita to find.
[04:43] <mpt> lifeless, most Web apps with a "Log Out" button still have a "Shared computer" or similar checkbox on the login form
[04:43] <mpt> for cases when, for example, you pay for ten minutes of time at a cafe and don't *quite* log out in time
[04:43] <mpt> stub, excellent
[07:21] <fabbione> lifeless: ping?
[07:24] <lifeless> pooong
[07:27] <fabbione> lifeless: i am having a stupid issue with bzr
[07:27] <fabbione> machine1 has the original archive.
[07:27] <fabbione> people.ubuntu.com has a pushed one
[07:27] <fabbione> machine2 branch from people
[07:27] <fabbione> machine2 can't push to people....
[07:28] <fabbione> or i can't figure out how to let machine2 to do it
[07:28] <fabbione> bzr branch sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/
[07:28] <fabbione> works fine
[07:28] <fabbione> whatever i try to say to bzr push towards that archive it ends up in an error
[07:29] <fabbione> note that the archive is perfectly synced
[07:29] <fabbione> no merges or new commits
[07:29] <fabbione> bzr: WARNING: Unable to update the working tree of: sftp://people.ubuntu.com/home/fabbione/public_html/archives/system-integrity-check/
[07:29] <fabbione> what am i missing here?
[07:30] <lifeless> a) #bzr is the right place
[07:30] <lifeless> b) its a UI glitch, its perfectly normal and correct
[07:31] <fabbione> a) ok.. b) what should i do to workaround it?
[07:31] <lifeless> theres nothing to workaround
[07:31] <lifeless> check the exit code - its 0
[07:31] <lifeless> it is giving you a warning, not an error
[07:31] <fabbione> ok
[07:33] <fabbione> thanks mucho
[07:33] <lifeless> np
[08:43] <dilys> Merge to devel/launchpad/: [trivial]  Drop is_person constraints (r3029: Stuart Bishop)
[09:08] <BjornT> stub: ping
[09:09] <stub> BjornT: pong
[09:13] <BjornT> stub: nevermind, i was about to ask you about how to fix something, but i noticed it has already been fixed in rocketfuel
[09:45] <carlos_> morning
[09:51] <SteveA> good morning
[09:55] <SteveA> lifeless: ping
[09:55] <Kinnison> Morning stevea
[09:57] <SteveA> hi Kinnison.
[09:57] <SteveA> That was yesterday.  I'm much better today.
[10:00] <Kinnison> SteveA: phew
[10:00] <SteveA> yeah ;-)
[10:00] <SteveA> i think i'll take it easy on the eyes today, though
[10:01] <SteveA> lots of workrave breaks
[10:24] <kiko> hello there
[10:24] <kiko> how's it going
[10:25] <Kinnison> Kaboom!
[10:26] <kiko> hey stub!
[10:26] <stub> kiko: hey
[10:27] <kiko> how's it going?
[10:27] <stub> The usual :-) 
[10:27] <stub> 'Nother lovely day in the land of smiles
[10:27] <kiko> naked girls, 30C, thai food, etc?
[10:28] <kiko> hey SteveA 
[10:28] <stub> Naked girls are 15 minutes walk away, and only come out at night. But it is 30C and the food is good, cheap and plentiful :)
[10:29] <kiko> and what about the production update?
[10:31] <stub> production update all done, patchlevels as discussed
[10:31] <kiko> thanks stub, rock and roll -- perhaps email launchpad and -users?
[10:32] <stub> We need that log of changes for -users announcements, otherwise it would be a bit pointless (?)
[10:33] <kiko> I have a log of changes here, so sure. 
[11:19] <SteveA> stub: ping?
[11:19] <stub> SteveA: pong
[11:19] <SteveA> i'm catching up with email
[11:19] <SteveA> has the cached celeb stuff landed yet?
[11:20] <sivang> morning all
[11:20] <SteveA> i was thinking about the cached celeb, and the mail thread about it
[11:20] <SteveA> as sqlobject does cacheing like we want if we get an object by id, and as we want a launchpad instance to fail early if the celebs are not as expected
[11:20] <SteveA> then we could re-do the celebs to do a single query / set of queries by name to look up celeb ids at startup
[11:20] <SteveA> and then use celeb ids from then on
[11:21] <stub> SteveA: Yes
[11:21] <SteveA> and not need fancy cacheing proxies etc.
[11:21] <stub> (landed)
[11:21] <SteveA> __getattribute__ always makes me queasy
[11:21] <Kinnison> SteveA: __get__ makes me more queasy
[11:21] <stub> I took jamesh's approach and simplified it, with comments about possible future enhancements.
[11:22] <SteveA> Kinnison: __get__ ?  as in from a descriptor
[11:22] <stub> __get__ is just downright wierd, and I havn't found good docs on it yet
[11:22] <Kinnison> SteveA: aye, as in to do with how @property is done
[11:23] <kiko> SteveA, I looked at the current solution and it appears to be doing a lot of good in production
[11:24] <SteveA> cool
[11:24] <SteveA> i just read the mail from jamesh
[11:24] <SteveA> i don't understand the part about thread-safety at the end though
[11:25] <kiko> SteveA, can you make it a priority this week to get jamesh' __len__ fix reviewed and landed?
[11:25] <SteveA> ok
[11:25] <kiko> the final important fix we need to do is inTeam caching
[11:25] <kiko> I spoke to salgado about this
[11:25] <SteveA> me too
[11:26] <kiko> and you, I remember now :)
[11:26] <SteveA> we don't want to do inTeam cacheing as such
[11:26] <kiko> right
[11:26] <kiko> you told me
[11:26] <kiko> so I was asking if you don't want to give salgado an idea of how you want this done, and have him implement it for you to review?
[11:27] <SteveA> maybe.  i'll look to see where we're up to with it
[11:28] <kiko> thanks -- I think salgado would appreciate being given that opportunity
[11:39] <spiv> stub: best doc on descriptors I've seen is http://users.rcn.com/python/download/Descriptor.htm
[11:43] <stub> spiv: ta
[11:49] <kiko> stub, is launchpad going down for maintainence?
[11:49] <Kinnison> eight kilobytes is utter shite
[11:50] <Kinnison> Hmm, it's not the buffer, it's that for some bizarre reason it uses nonblocking receive
[11:56] <matsubara> good morning!
[11:58] <stub> kiko: nope
[11:59] <kiko> and the message is gone, too!
[11:59] <stub> you saw a message?
[11:59] <kiko> yeah, on the webapp
[11:59] <stub> bah - one of the appservers hadn't cleared its 'down for maintenance' file
[12:00] <stub> Sorted
[12:00] <kiko> cool.
[12:01] <kiko> SteveA, talk to me, come on
[12:03] <kiko> 36ms  	SELECT private, owner, activitytimestamp, communityscore, datecreated, activityscore, title, duplicateof, description, hitstimestamp, hits, communitytimestamp, name, summary FROM Bug WHERE id = 633
[12:03] <kiko> stub, is there any explanation on why that wouldn't take 1ms? contention?
[12:04] <stub> contention
[12:04] <stub> Or just busy
[12:05] <kiko> 23ms  	SELECT id FROM BugExternalRef WHERE bug = 633
[12:05] <stub> Lots of disk activity
[12:06] <stub> karma updater has kicked in
[12:06] <stub> Which will continue to be slow until my patch is reviewed and landed
[12:07] <kiko> stub, what's blocking your review?
[12:08] <stub> me not nagging anybody?
[12:08] <SteveA> it's in the general queue
[12:08] <SteveA> i'll take a look now
[12:08] <SteveA> i need a change from EMAIL
[12:08] <kiko> SteveA, can you take that..
[12:08] <kiko> cool
[12:08] <kiko> this will be a great week for perf
[12:10] <SteveA> stub: what does WITHOUT OIDS mean?
[12:11] <stub> By default tables get a magic column, but it is only really useful in rare cases (and even then, not strictly necessary). We don't need them anyway. 
[12:12] <stub> I'll be updating all the tables at some point to remove them, but it isn't urgent
[12:12] <stub> WITHOUT OIDS is the default in 8.1 (or is it 8.0?)
[12:24] <Kinnison> SteveA: Apparently you were party to some local zope mods on jackass
[12:24] <Kinnison> SteveA: Did those ever make it into rocketfuel?
[12:25] <SteveA> stub: reviewed
[12:25] <SteveA> Kinnison: jackass?
[12:26] <SteveA> what was running there?
[12:26] <Kinnison> SteveA: The poppy instance for dak
[12:27] <SteveA> i don't recall zope mods for that, only poppy mods
[12:27] <SteveA> is there a problem with running poppy?
[12:28] <Kinnison> cprov is encountering issues with some tests running on his laptop needing reconnects mid-upload
[12:29] <cprov> SteveA: yes, maybe you remember something about this issue
[12:29] <SteveA> as far as i recall, all changes to poppy, and workarounds to connections being aborted on long uploads, were done in the poppy code 
[12:30] <cprov> SteveA: gustavo added a weird polling on ftp.sock during the upload session, it needs further explanation.
[12:30] <SteveA> what is the problem you're seeing?
[12:32] <cprov> SteveA: aparently the ftp connection drops during the upload session (it's not a long one) and the only way to recognize it is polling the ftp.sock (private attribute) and if it's gone ftp.connect() and ftp.login() again
[12:33] <SteveA> hmm
[12:33] <SteveA> so, there is a problem with the default ftp server code that the ftp connection will be aborted during an upload session, if the upload is long
[12:33] <SteveA> beacuse the control connection will get no data for a while, even though the data connection is getting data
[12:34] <SteveA> so the control connection will figure "oh, nothing happening, i'll disconnect"
[12:34] <SteveA> i wrote a fix for poppy that deals with this
[12:34] <carlos> daf, Seems like tests are not detecting that I don't have installed python2.4-twisted-mail
[12:34] <carlos> daf, what's using it?
[12:34] <cprov> SteveA: and is it applied  jackass instance ?
[12:34] <SteveA> the fix didn't involve polling
[12:34] <daf> carlos: I can't remember
[12:35] <SteveA> it involved correctly resetting the activity timer on the control connection whenever some data arrives on the data connection
[12:35] <cprov> SteveA: the polling is in the client side ...
[12:35] <SteveA> i have no idea what jackass is for, and where the fix was applied
[12:35] <daf> carlos: buildd-sequencer.txt is what failed
[12:35] <daf>     ImportError: You need to have the Twisted Mail package installed to use twisted.protocols.smtp. See http://twistedmatrix.com/projects/mail.
[12:36] <SteveA> the fix was certainly applied for poppy in production
[12:36] <SteveA> because longer uploads would always fail without it
[12:36] <carlos> hmm, I see
[12:36] <cprov> daf: dapper ?
[12:36] <carlos> cprov, yes
[12:36] <daf> cprov: yes
[12:36] <carlos> daf, import_fascist is missing that import then
[12:36] <cprov> cprov: twisted pkg was split in a wierd way, maybe lp-deps isn't up 
[12:36] <carlos> daf, it detected the web package
[12:37] <carlos> but didn't complain about the mail one
[12:37] <daf> this was when running python test.py -f yesterday
[12:37] <SteveA> cprov: see poppy/server.py, class STORChannel
[12:37] <cprov> SteveA: I suspect we are talking about the same patch ... elmo just gave it to me ... will isolate the patch an send you, ok ?
[12:38] <daf> carlos: and yes, the fascist does appear in the traceback
[12:38] <SteveA> cprov: ok.  what code are you using? how does it compare to the code in RF?
[12:41] <carlos> daf, hmmm I don't see it, perhaps other failures are hidding it..
[12:42] <cprov> SteveA: so, I have RF HEAD and a kind of special zope+poppy instance from elmo
[12:42] <cprov> SteveA:  I can see the class STORChannel(OriginalSTORChannel):
[12:43] <cprov> SteveA: I can't see where is the respective code in RF
[12:48] <cprov> niemeyer: hey, how is it going ?
[12:48] <niemeyer> Buenos dias!
[12:48] <kiko> fala niemeyer 
[12:49] <niemeyer> cprov: So far so good :)
[12:49] <cprov> niemeyer: maybe you have some info to bug # 29645
[12:49] <cprov> niemeyer: this is a sabdfl's phrase, you need to find other ;)
[12:50] <niemeyer> cprov: Ah, didn't know that.. will look for another one :)
[12:50] <niemeyer> cprov: Will check it
[12:50] <cprov> niemeyer: good, thx
[12:56] <niemeyer> cprov: ^
[12:59] <cprov> niemeyer: try again 
[12:59] <niemeyer> cprov: Is the backtrace expected?
[12:59] <Kinnison> Umm, given a list L, what's the best way to produce list K which is [ L[0] , L[0:1] , L[0:2] , ..., L ]  ?
[01:00] <niemeyer> [L[:i]  for i in range(len(L))] ?
[01:00] <niemeyer> Perhaps (1, len(L))
[01:00] <cprov> niemeyer: it's not, thought it's been solved, file a bug 
[01:01] <Kinnison> niemeyer: (1, len(L)+1) does the trick, ta
[01:01] <niemeyer> Kinnison: The +1 after len(L) shouldn't be needed..
[01:02] <Kinnison> It is
[01:02] <Kinnison> otherwise it stops one earlyu
[01:02] <Kinnison> s/u$//
[01:02] <niemeyer> Kinnison:
[01:02] <niemeyer> >>> L = [1,2,3] ; print L[:len(L)] 
[01:02] <niemeyer> [1, 2, 3] 
[01:03] <Kinnison> range(a,b) is from a to b-1
[01:03] <Kinnison> range(10) is 0-9
[01:03] <niemeyer> Kinnison: Duh, right
[01:03] <niemeyer> [L[:i+1]  for i in range(len(L))]  would do the trick then
[01:04] <Kinnison> the latter I think
[01:07] <Kinnison> kiko, mdz: on libcommand* in universe sources now
[01:18] <dilys> Merge to devel/launchpad/: [r=SteveA]  Karma cache refactoring (r3030: Stuart Bishop)
[01:18] <kiko> rock and roll stub 
[01:20] <Kinnison> kiko, mdz: libxml*
[01:20] <Kinnison> I love the initial publish process
[01:20] <Kinnison> it makes me so happy
[01:21] <kiko> it is so friggin slow
[01:24] <cprov> kiko: it's relative, do you have a faster replacement ? so, current publisher is the fastest ! we can have so much fun watching spn crossing the screen like in a 9600 bps terminal ;)
[01:25] <kiko> like a fast link to QSD in the old days
[01:26] <cprov> malone: why are assigned "needs-info" bug not listed in "My Assigned Bugs" ? 
[01:27] <kiko> because they are needs-info.
[01:27] <cprov> kiko: it's unfair IMO, I would like to keep track of my needs-info bugs too
[01:28] <kiko> it's been the subject of some debate
[01:28] <kiko> you can query them using the advanced form if you like
[01:28] <cprov> kiko: uhm ... could be a solution 
[01:28] <Kinnison> kiko: If you can work out a faster way to drag a file down from an HTTP server other than using urllib2.urlopen() then you win a prize
[01:35] <kiko> daf, ping?
[01:39] <daf> kiko: pong
[01:51] <kiko> daf, you don't talk to me padrino
[01:52] <daf> oh, bah
[01:52] <daf> I need to register
[01:53] <SteveA> carlos: ping
[01:54] <carlos> SteveA, pong
[02:08] <ddaa> stub: maybe it's me, but when I read your "What is a Product Series" mail, all I see is a barrage of "you're on crack ddaa".
[02:08] <ddaa> makes it difficult for me to reply
[02:10] <ddaa> I'll try...
[02:11] <sivang> bah
[02:11] <sivang> selecting ValidAssignee timed out for me, any idea?
[02:11] <sivang> (I was trying to assigna  bug to Scott)
[02:12] <carlos> spiv, hi, around?
[02:21] <spiv> carlos: Yeah.
[02:21] <carlos> spiv, hi, I'm having problems with your suggested 'self.form.extractOneKey' method
[02:21] <carlos> and I was not able to find any reference to it...
[02:22] <carlos> isn't it just self.form[key]  ?
[02:23] <carlos> spiv, I'm talking about review of PoMsgSetPage
[02:23] <carlos> s/about/about your/
[02:24] <daf> I think fel.form[key]  can contain a list
[02:25] <spiv> carlos: let me look at my review, I think I was proposing that there should be one, rather than there is one..
[02:26] <carlos> hmm
[02:26] <spiv> carlos: right, it was a hypothetical method name.
[02:26] <carlos> ok, I misunderstood you :-P
[02:26] <carlos> daf, really?
[02:26] <daf> sure
[02:26] <carlos> daf, I suppose it depends on the form, right?
[02:26] <spiv> carlos: The thing is, you're doing a fair bit of manual mucking about because you want forms to have more data than simple key/value pairs.
[02:26] <daf> http://launchpad.net/blah?foo=a&foo=b
[02:26] <carlos> if you add twice the same entry
[02:26] <daf> form['foo']  = ['a', 'b'] 
[02:27] <daf> I think
[02:27] <carlos> daf, right
[02:27] <spiv> Although as daf points out, you can actually include the same key multiple times in the same form.
[02:27] <carlos> spiv, well, our forms should have just one key
[02:27] <carlos> if we have more than one is either bad user input
[02:27] <carlos> or a bug
[02:28] <spiv> carlos: interesting, that wasn't at all clear to me from reading the code.
[02:28] <carlos> so I think is safe to assume it's just one element and show an error if we get a list
[02:28] <spiv> Oh, sorry, I see what you mean.
[02:28] <spiv> I think ;)
[02:28] <carlos> spiv, let me show you the new code
[02:28] <carlos> I changed it
[02:28] <spiv> Sounds good :)
[02:29] <sivang> ddaa: how can I register my a branch of mine with LP ?
[02:29] <sivang> ddaa: I have it published and accessible http, can I do that without an admin intervention?
[02:29] <carlos> spiv, https://chinstrap.ubuntu.com/~dsilvers/paste/fileICjL4I.html
[02:30] <carlos> spiv, I need to change the extractOneKey call with self.form[] 
[02:30] <ddaa> sivang: if it's a bzr branch, it's just "add branch" on the corresponding product, or on your person's page if it has no associated product.
[02:31] <carlos> and I suppose that I should also check if 'key' is a list to show an error
[02:32] <spiv> carlos: So, I guess I didn't explain my idea so well.
[02:33] <sivang> ddaa: ok, is it ok to open a project for it, if it's a project based on a specification?
[02:33] <carlos> spiv, I discarded the record idea
[02:33] <spiv> carlos: It looks to me as if it would be simpler if you could pass structs in forms.
[02:33] <carlos> spiv, I have the explanation in my email
[02:34] <spiv> carlos: because really set_1_msgid and set_1_translation_... look like they're effectively different attributes of the same thing.
[02:34] <spiv> Hmm, ok.
[02:34] <spiv> You mean the specific implementation, or the whole concept?
[02:34] <ddaa> sivang: you mean "a product". You can create a product if you want, you do not need to, and I believe you are able to change the product after registration, so you can postpone the product creation.
[02:34] <carlos> spiv, but as a summary, I don't think we need to add support for records just for this part of launchpad, we don't have a hard restriction on them
[02:34] <ddaa> sivang: just do what makes most sense to you, if that's not supported by Launchpad, that's a bug.
[02:35] <spiv> carlos: Well, you're basically doing the same thing ad hoc.
[02:35] <carlos> spiv, you are right, it's a record, the concept is what you said, but the implementation... I'm not sure we should do it now unless other parts of launchpad can reuse it too
[02:35] <daf> spiv: yeah, it's almost like a dum/restore
[02:35] <spiv> carlos: So I'd be tempted to just use the stuff that's already built into zope 3 to ease this stuff.
[02:35] <daf> dump
[02:36] <daf> (written late one night in Mark's flat, IIRC)
[02:36] <carlos> hmm I thought we need to do some changes to launchpad to be able to use it
[02:36] <carlos> spiv, if it's already there... I will try that path then
[02:37] <spiv> carlos: It seems to be in there already, I think, but maybe it needs a small tweak to activate it.
[02:37] <carlos> ok, I need to talk later with SteveA I will check it with him
[02:37] <carlos> to be sure
[02:37] <carlos> spiv, thanks
[02:37] <spiv> carlos: I would like to get a zope expert's opinion on the topic, too, because I'm not sure if that particular feature is considered a good idea in zope 3 or not.
[02:37] <spiv> Yeah, check with Steve.
[02:37] <daf> what code is this, by the way?
[02:38] <spiv> As far as the review goes:
[02:38] <daf> s/code/branch/
[02:38] <carlos> daf, PoMsgSetPage
[02:38] <daf> aha
[02:38] <carlos> daf, chinstrap.ubuntu.com:/home/warthogs/archives/carlos/launchpad/PoMsgSetPage/
[02:39] <spiv> I'm happy enough for that code to be merged with your ad hoc pulling processing of this structured form -- but I strongly suspect this won't be the only bit of launchpad where this may be useful, hence my interest in a more general solution.
[02:39] <daf> let's file a bug on it
[02:39] <carlos> daf, let's ask Steve first ;-)
[02:39] <daf> I think it would simplify the code in a good way
[02:40] <daf> even if it's only useful here
[02:40] <daf> sure, pending Steve's approval
[02:40] <carlos> ok
[02:40] <spiv> carlos: Thanks for describing your use case for me so I fully understand what you need
[02:40] <carlos> spiv, no, thanks for your input ;-)
[02:41] <spiv> daf: I agree it would be nicer, but if it's just for this one piece of code, it may not be worth it.
[02:41] <spiv> Anyway, we have a plan of action now :)
[02:41] <daf> yes
[02:52] <SteveA> spiv: there is various form marshalling stuff in zope3, as in zope2.  but i think it is not the right way to do it -- it leads to more problems than it solves
[02:53] <SteveA> and it is largely unused for that reason, and also because we have forms and widgets now for the same kind of thing
[02:53] <sivang> daf: so, how can I remove the project I've open and open a product instead of it, and associate the bzr branch to it?
[02:53] <daf> sadly, you can't delete projects
[02:53] <SteveA> spiv: we could think about adapting a request to an IFormData kind of thing, and have useful APIs on an IFormData, perhaps
[02:53] <sivang> daf: AFAICT I only need one product with one associated branch
[02:53] <daf> I would just create a product with the same name
[02:54] <SteveA> spiv: including getOneKey or some such
[02:54] <daf> then there should be an "Add Branch" link
[02:54] <sivang> daf: ok, will do, thanks
[02:54] <SteveA> so, we can have a launchpad-specific API on forms without extending the Zope3 request a lot
[02:54] <spiv> SteveA: I thought that might be the case (about the existing form marshalling).
[02:55] <spiv> It would be nice to have a cleaner solution.
[02:55] <spiv> Although I'm not sure if there's any other places we need it.
[02:55] <spiv> It seems like something that would be useful more than once, but maybe not....
[02:57] <sivang> daf: https://launchpad.net/products/launchpad/+bug/29655 <== this is it
[02:57] <Ubugtu> Malone bug 29655: "selecting ValidAssignee times out" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
[02:57] <sivang> daf: now , I will go find out what about that meeintg, If I'm cleanred I'll brb, if not it's bbiab
[02:57] <daf> ok :)
[02:59] <SteveA> spiv: can you tell me the outcome of the librarian error stuff?
[03:00] <spiv> SteveA: still unsure what the cause is
[03:00] <spiv> stub: have you updated the staging librarian config to only listen on localhost?
[03:01] <spiv> SteveA: stub was going to change the staging librarian to listen only localhost, which shouldn't break anything that ought to be using it, and hopefully cause errors in a rogue gina or whatever it is that's putting garbage into it from somewhere else.
[03:02] <spiv> SteveA: If that doesn't work, I think your suggestion about getting clients to declare what db they're using when they upload will be needed.
[03:02] <spiv> I guess the clever way to do that would be to figure out a query that gives a unique result on each database we have, so both the client and the server can do the query and check that they're consistent.
[03:05] <SteveA> i think we should have the client say the database details anyway
[03:05] <SteveA> perhaps in an X-whatever HTTP header
[03:05] <SteveA> then at least we can debug this
[03:06] <spiv> (Well, the upload protocol isn't HTTP, it's just something similar but much simpler)
[03:06] <spiv> Yeah, and extra header on the uploads would be the way to do it.
[03:06] <spiv> We'll have to phase it in, though, rather than make the server require it immediately.
[03:06] <SteveA> sure
[03:06] <SteveA> make it optional at first
[03:07] <spiv> We can always make the server log a warning (including source IP) if it doesn't get the header.
[03:08] <SteveA> the other way to do it is to have a table with one col and one row saying the database id
[03:08] <SteveA> and include that instead
[03:09] <SteveA> but that sounds more complicated
[03:09] <SteveA> although maybe needed when we have multiple database back-ends
[03:09] <spiv> If there's a way to query the dbname and/or hostname, that'd probably do.
[03:09] <spiv> I'm sure stub will have a good idea for this.
[03:09] <SteveA> it won't do when we have multiple database back-ends
[03:10] <spiv> Hmm, true.
[03:10] <SteveA> whichever way it happens, please do this soon
[03:10] <spiv> Here's a partial solution:
[03:11] <SteveA> as even being able to log things will allow us to debug it better
[03:11] <spiv> query LaunchpadDatabaseRevision
[03:11] <stub> eh?
[03:11] <spiv> stub: we're discussing how to make sure the librarian server and clients are using the same database, so we don't get id stomping.
[03:12] <spiv> As appears to be happening on staging.
[03:13] <stub> Each of our databases has a unique name, so we can query that
[03:13] <sivang> daf: back for 15 minutes
[03:14] <stub> spiv: SELECT current_database()
[03:14] <sivang> daf: can you try re-assign the bug in question and see if validAssignee times out for you as well?
[03:14] <spiv> SteveA: I can do it on Monday, but can't do it any sooner.  (I'm about to go to bed, then it's a public holiday, a day of leave, then a weekend, and I won't have internet access probably)
[03:14] <daf> sivang: who did you try to reassign it to?
[03:14] <sivang> daf: I searched for Keybuk 's email / account name
[03:14] <daf> oh, to Scott
[03:15] <sivang> daf: yeah :)
[03:16] <stub> spiv: I didn't update the staging librarian to only listen on localhost, as you pointed out that parameter was used by both the client and server and that syntax would only work on the server end.
[03:16] <stub> oh.... I was going to get the port blocked.
[03:17] <spiv> stub: Well, there's ways around that.
[03:17] <stub> Which I won't do now anyway, as staging is being used for testing by the soyuz stuff, so drescher needs to be able to connect
[03:17] <spiv> stub: Are the client and server using the same deployment?
[03:17] <spiv> Ah.
[03:17] <stub> spiv: yes
[03:17] <spiv> Ok, then here's the dodgy way: 
[03:17] <sivang> Kinnison: should this imrpove once sessions are stored in pg rather in zodb ?
[03:18] <spiv> directly edit the "uploadPort = str(config.librarian.upload_port)" line of daemons/librarian.tac to have the "tcp:12345:interface=127.0.0.1" or whatever string.
[03:19] <spiv> But if certain other hosts actually need to connect, a port block is probably better anyway.
[03:19] <Kinnison> sivang: yes
[03:19] <spiv> Ok, it's way too late, I must sleep.
[03:19] <spiv> G'night all.
[03:21] <spiv> stub: If you can try the port blocking solution in the interim until I code up the SELECT current_database() check, that'd be great.
[03:24] <Keybuk> why does Launchpad time out logins?
[03:24] <Keybuk> can't it be set to just remember sessions forever?
[03:25] <Kinnison> IIRC it's not launchpad so much as the session affinity crap on the load balancer
[03:25] <stub> Keybuk: It now should only timeout logins after 60 days or when your browser decides not to bother sending cookies any more. So if you havn't logged in for 12 hours, that is to be expected but it should be sorted as of this rollout.
[03:25] <sivang> daf: let me know ifyou need anything else
[03:25] <stub> Kinnison: That is now off. We no longer need it.
[03:25] <Kinnison> stub: we're finally using the postgres db?
[03:26] <stub> Kinnison: Yes. As of a week or two ago. I just switched the 60 day timeout on today though.
[03:26] <Kinnison> stub: right
[03:26] <Kinnison> stub: and that's 60 days from last use? Not 60 days from login?
[03:27] <stub> 60 days of inactivity (I hope ;) )
[03:27] <Kinnison> good
[03:27] <stub> Back in an hour...
[03:28] <Kinnison> ciau
[03:28] <ddaa> Keybuk: I think your feedback would be useful in the "what is a product series" discussion I'm having with stub on the launchpad mailing list.
[03:29] <Keybuk> ddaa: ok, I'll look at that -- I'm up to date with launchpad atm except any mail that happened while I was at the gym
[03:30] <ddaa> Keybuk: it looks like this discussion is more about what ProductSeries should mean, and why it ended up this way historically. I think you have been an important actor in designing this part, and it has not changed recently.
[03:31] <ddaa> Also, the HCT/Dyson stuff are the primary clients of this data, as I understand the situation.
[03:32] <Keybuk> heh, the only actor who did ProductSeries was Mark :)
[03:32] <Keybuk> it was a surprise to me when it turned up overnight too
[03:32] <ddaa> whatever, if we can agree on a way to get rid of it, I would be happy.
[03:33] <ddaa> hu, that's not what I mean...
[03:34] <daf> sivang: sorry, was on the phone
[03:34] <daf> sivang: which bug were you reassigning?
[03:34] <daf> 29654?
[03:34] <ddaa> If we can figure out what it's really useful for, and provide a model that's more in line with the use cases, i would be happy
[03:35] <ddaa> and less confusing, too
[03:35] <ddaa> (sounds better that way)
[03:40] <ddaa> they more bandwidth and they not needed
[03:44] <jbailey> https://bugzilla.ubuntu.com/show_bug.cgi?id=16216 has a link to https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/16216
[03:44] <Ubugtu> Ubuntu bug 16216: "start week day wrong in Spanish" Product: Ubuntu, Component: locales, Severity: normal, Assigned to: jbailey@ubuntu.com, Status: NEW
[03:45] <jbailey> But this doesn't take me to the right bug in Launchpad, it takes me to the one that pointed me to the bug in bugzilla.
[03:45] <jbailey> help? =)
[03:47] <daf> ?!
[03:48] <daf> searching for site:launchpad.net "start week day wrong in Spanish" yields no results
[03:49] <daf> my primary suggestion at this point is to mail James H
[03:49] <jbailey> daf: Thanks. =)
[03:50] <daf> no worries
[03:51] <daf> ah -- perhaps the redirect just points to the first bug it finds that's watching the bugzilla bug
[03:53] <daf> still can't find the imported bug, though
[03:53] <jbailey> That's a much nicer thought than more dataloss.
[03:53] <daf> sadly, I rather suspect that the bug didn't get imported
[03:54] <daf> on the bright side, importing it should be easy
[03:54] <daf> but on the third hand, this could affect lots of other bugs that we haven't noticed yet
[04:35] <kiko> salgado, did cprov and Kinnison's answers satisfy you?
[04:35] <kiko> daf, jbailey: can you email the list with the evidence so we can deal with that
[04:36] <jbailey> kiko: I've emailed jamesh directly, per dafs notes.  Should I just send the same email to the launchpad list?  It was mostly a snapshot of the IRC conversation.
[04:36] <kiko> please do -- if it's not on-list, it is lost
[04:37] <jbailey> kiko: Also, I was hoping to ping him about the dataloss since the conversion (new comments going into bugzilla)
[04:37] <kiko> jbailey, how have these comments been going in?
[04:37] <kiko> and has it stopped happening?
[04:37] <jbailey> kiko: No idea.
[04:37] <jbailey> Also no idea.
[04:37] <jbailey> Pure fluke that I noticed,  james said he'd run a query to see how bad it was.
[04:37] <kiko> I can do it
[04:37] <jbailey> Usually I disable all bugzilla bugmail.
[04:37] <daf> ouch
[04:38] <salgado> kiko, I haven't reached that point in my inbox yet. :-(
[04:38] <daf> ddaa: I've pushed my o-b-t
[04:38] <kiko> salgado, is it that bad?
[04:38] <daf> ddaa: I think I've covered the major things we talked about
[04:39] <ddaa> daf: that's good news
[04:39] <ddaa> daf: are you asking me to review it?
[04:39] <kiko> daf is giving out copious amounts of good news today
[04:39] <salgado> kiko, not really, I was fixing some issues Bjorn pointed on his review and I'm now reviewing matsubara's branch
[04:39] <kiko> ah, cool.
[04:39] <daf> ddaa: er, I don't know :)
[04:39] <ddaa> daf: that's fine if you don't. I trust you to have the situation better rather than worse.
[04:40] <kiko> ddaa, if you have time, feel free to review it
[04:40] <daf> if ddaa doesn't spiv will be pretty keen, I think
[04:40] <daf> (it's blocking is push-sftp stuff)
[04:40] <ddaa> I think it will land sooner if I do not look at it :)
[04:41] <kiko> okay, send it to spiv
[04:41] <kiko> does anyone know where the debbugs sync tool lives in our tree?
[04:41] <kiko> SteveA?
[04:43] <bradb> kiko: lib/canonical/launchpad/scripts/debbugs.py
[04:44] <kiko> bradb, is that the only thing that exists? nothing uses debbugs?
[04:45] <kiko> didn't jamesh review this?
[04:45] <bradb> This was written long before we did code reviews.
[04:45] <bradb> So I doubt anyone but Mark has read it.
[04:46] <kiko> but I was sure that james had reviewed this.. wtf
[04:47] <bradb> Could be.
[04:47] <kiko> is THAT the only thing that exists?
[04:48] <kiko> mark said "it was nearly ready" 100x
[04:48] <bradb> Only thing I know of.
[04:48] <stub> kiko: debugs was due to be rolled out, but has probably grown some hair
[04:49] <stub> It was ready and waiting but couldn't be switched on until GIna was in production
[04:50] <stub> So now it will need testing against staging by someone to get things working again and confirm it is all happy.
[04:50] <kiko> stub, where the hell does it live in our tree then?
[04:50] <kiko> I mean, I can't find it
[04:50] <ddaa> stub: would you mind checking that PQM is not stuck?
[04:51] <stub> cronscripts/update-debwatches.py and cronscripts/create-debwatches.py
[04:52] <stub> Some tests would be nice too, but that might involve reverse engineering debbugs in order to create some sample data (or bribing colin or ian or whoever to help)
[04:52] <kiko> I disagree with doing a completely different solution to updating watches
[04:52] <kiko> at a glance I say we should adapt this to malone/externalsystem.py
[04:52] <kiko> but.. 
[04:53] <stub> Currently running buildbot tests...
[04:53] <stub> bug no activity...
[04:54] <kiko> buildbot tests have been caught hanging before
[04:54] <kiko> stub, would it be possible to tail the log output somewhere consistently?
[04:54] <stub> kiko: Could be done in test_on_merge.py I guess - just spool the output to /tmp/whatever and keep flushing
[04:54] <ddaa> stub: please kill that bitch
[04:55] <daf> ddaa: "please" and "bitch" are somewhat incongruous :)
[04:55] <stub> ddaa: Needed a kill -9 again
[04:56] <ddaa> yeah, same as last time... no wonder...
[04:56] <daf> fuxtex
[04:56] <ddaa> fuxtex mean anything...
[04:56] <SteveA> daf: hello.  voice call?
[04:57] <ddaa> any deadlock situation appears to cause a block on a futex call when using strace
[04:57] <daf> SteveA: sure -- mobile or Skype?
[04:57] <kiko> night stub 
[04:57] <ddaa> well... not any, but many of them...
[04:59] <SteveA> daf: skype
[05:00] <daf> SteveA: ready
[05:12] <dilys> Merge to devel/launchpad/: [r=spiv]  fix bug 2653, don't show information about email attachments, like GPG signatures, in comments. (r3031: Bjorn Tillenius)
[05:18] <ddaa> sigh
[05:18] <ddaa> it's my cscvs compatibility patch that causes buildbot to hang...
[05:24] <carlos> SteveA, hi, sorry I had some network problems...
[05:31] <Keybuk> https://launchpad.net/distros/ubuntu/+source/ifupdown/+bugs
[05:31] <Keybuk> ^ bradb: the first bug says "in progress (unassigned)" ... but it's assigned to me!
[05:32] <jordi> hello
[05:34] <carlos> jordi, hi
[05:35] <bradb> Keybuk: I'll report a bug, thanks.
[05:35] <carlos> jordi, yesterday I saw that the wiki is not updated with the new procedure to upload new translations
[05:35] <carlos> jordi, and there are some pending imports there
[05:35] <carlos> are you still handling them?
[05:35] <carlos> (the ones from the wiki)
[05:35] <Keybuk> bradb: your new form ... my one main comment is that it's too bunched up
[05:36] <Keybuk> could we have some more whitespace between each row
[05:36] <Keybuk> otherwise the text kinda merges into one, and I have to stare hard to actually tell where one bug begins or ends
[05:36] <Keybuk> another option would be to white/grey the cells
[05:36] <Keybuk> actually, white/grey would probably work nicely
[05:36] <bradb> Keybuk: How do you think it compares to http://flickr.com/photos/84096161@N00/90749634/ ?
[05:36] <jordi> carlos: yeah, there are a few new ones, and others that are cruft (ie, need mailing the requester and telling them that they are being rejected)
[05:37] <bradb> i.e. three-column vs. two-column layout
[05:37] <Keybuk> bradb: that is just a mess, frankly
[05:37] <jordi> carlos: sometimes they need investigation to see if requester = upstream and it takes time
[05:37] <Keybuk> too much information to sift though to find a bug
[05:37] <jordi> I had been focusing on the new quue fir a while
[05:38] <Keybuk> bradb: if the Reported.*EST stuff was in a lighter colour (like silver) it wouldn't be too bad
[05:38] <carlos> jordi, I think you should add a note to the wiki page and update the wiki so the new additions are directly on the new queue...
[05:38] <bradb> Keybuk: If we silvered or removed that row, and removed the "Last Updated" line, which UI do you prefer, the two-column or three-column layout?
[05:38] <dilys> Merge to devel/launchpad/: [r=kiko]  Launchpad FAQ page (/faq) (r3032: Dafydd Harries)
[05:39] <Keybuk> bradb: if the table one had alternate colours for the rows, definitely the table
[05:39] <jordi> yeah
[05:39] <jordi> let me do it now
[05:40] <bradb> Keybuk: ok, thanks. I'm making some small tweaks to the two-column layout and am planning to send the data I've collected to launchpad@
[05:40] <carlos> jordi, thanks
[05:42] <bradb> Keybuk: bug 29671 for what you reported earlier
[05:42] <Ubugtu> Malone bug 29671: "Listing shows bug "unassigned" even when it's assigned" Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: Confirmed http://launchpad.net/bugs/29671
[05:42] <Keybuk> ah ok
[05:43] <daf> SteveA: http://www.onlamp.com/pub/a/python/2005/11/03/twill.html
[05:44] <daf> SteveA: skip to page 3
[05:48] <daf> SteveA: even better, http://wwwsearch.sourceforge.net/mechanize/
[05:50] <sadhermi1> hi
[05:52] <seb128> hi
[05:52] <seb128> carlos: around?
[05:52] <SteveA> daf: yes.  this is basically what we'll be using as soon as we get the new zope3.
[05:53] <daf> SteveA: excellent
[05:53] <carlos> seb128, hi
[05:53] <seb128> hey :)
[05:54] <seb128> carlos: a french user pointed https://launchpad.net/distros/ubuntu/dapper/+source/gsmartcard/+pots/gsmartcard/fr/+translate which has 0 string to translate
[05:55] <seb128> carlos: it's not a main package, so it has been imported by somebody?
[05:55] <jordi> seb128: by an accident
[05:55] <seb128> jordi: what kind of accident? 
[05:55] <carlos> seb128, any dapper translation resource that we have imported was done by mistake
[05:55] <seb128> change dapper by breezy
[05:55] <seb128> still 0 string
[05:55] <carlos> seb128, we didn't disabled the old import script when dapper was open on production
[05:56] <carlos> seb128, then, it's a bug with that package
[05:56] <carlos> let me check...
[05:56] <seb128> thank you
[05:57] <carlos> seb128, seems like the .pot file was never imported
[05:57] <carlos> I will check why
[05:57] <seb128> ok, thank you
[06:05] <carlos> seb128, that .pot file is completely broken
[06:06] <carlos> seb128, has duplicated entries
[06:07] <seb128> carlos: ah, so that's a package bug? 
[06:07] <carlos> seb128, yes
[06:07] <seb128> hum
[06:07] <carlos> I will fix manually breezy's one
[06:07] <seb128> but you import universe to rosetta?
[06:07] <seb128> I thought it was main only
[06:07] <carlos> seb128, the new policy says that we are not going to do that
[06:07] <carlos> but we did it already for breezy
[06:07] <carlos> I will block it for dapper
[06:08] <seb128> ok, thank you
[06:10] <jordi> where's kiko?
[06:11] <SteveA> jordi: london office, which is disconnected right now
[06:11] <jordi> ah
[06:11] <jordi> requirements?
[06:11] <jordi> ~
[06:11] <jordi> damn
[06:11] <jordi> sorry
[06:12] <jordi> https://launchpad.net/malone/bugs/5952
[06:12] <Ubugtu> Malone bug 5952: "Group "owners" should be able to add translators" Fix req. for: rosetta (upstream), Severity: Major, Assigned to: Nobody, Status: Confirmed
[06:12] <jordi> I don't quite understand his last comment
[06:54] <iwj> I sent a mail to malone but haven't had an ack.  What does that mean ?  (Sent at 16:11:25, but against flashplayer-{nonfree,mozilla}).
[07:00] <BjornT> iwj: seems that your signature didn't verify properly. currently you don't get an error message when such errors occurs, which you should.
[07:07] <iwj> My signature didn't verify properly ?  In what way ?
[07:07] <iwj> Hmm.  gpg agrees.
[07:07] <iwj> I made the signature with mailcrypt.
[07:11] <AlinuxOS> carlos, in this "ka" georgian seciton... are there only main packges..
[07:11] <AlinuxOS> ?
[07:11] <carlos> AlinuxOS, talking about rosetta-breezy.tar.gz?
[07:11] <AlinuxOS> yes
[07:11] <carlos> AlinuxOS, yes, there are only translations for main
[07:12] <AlinuxOS> example I have metacity.po file can I put there?
[07:12] <AlinuxOS> every package is tested on my system
[07:12] <AlinuxOS> only gnome-menus dosen't work (a known reason)
[07:13] <carlos> AlinuxOS, if msgfmt -v -c your_file.po -o /dev/null works that's ok
[07:14] <AlinuxOS> carlos, so I can put metacity.po there
[07:14] <carlos> yes
[07:15] <AlinuxOS> ok
[07:15] <carlos> are you going to send a full tarball to pitti?
[07:15] <iwj> Yay, an error message with a comprehensible complaint.
[07:15] <carlos> AlinuxOS, I think it's enough if you just send your files
[07:15] <AlinuxOS> carlos, he told me that I can send only a "ka" seciton to him.
[07:15] <AlinuxOS> yes...
[07:16] <carlos> oh, ok
[07:16] <AlinuxOS> he makes them in this night...
[07:16] <AlinuxOS> :D
[07:16] <AlinuxOS> I'll import them to rosetta too :)
[07:17] <AlinuxOS> carlos, and what about mozilla locales?
[07:18] <AlinuxOS> I have mozilla locales too
[07:19] <carlos> AlinuxOS, not yet integrated with language packs
[07:19] <AlinuxOS> I have ka_GE.xpi
[07:19] <AlinuxOS> ah
[07:19] <AlinuxOS> in breezy or in dapper?
[07:21] <carlos> we will try to have it integrated with dapper
[07:21] <AlinuxOS> ah
[07:21] <AlinuxOS> ok :) mozilla is ready
[07:21] <AlinuxOS> 1.0.7 verison.
[07:22] <ddaa> cool, I can reproduce the buildbot hang here
[07:22] <ddaa> there is still hope
[07:22] <ddaa> (somewhere...)
[07:24] <carlos> AlinuxOS, talk with Martin to include it on dapper
[07:24] <ddaa> basically, it looks like our buildbot has bitrotten into incompatibility with breezy's twisted...
[07:24] <iwj> Woohoo.  Now I have a bug reply mail saying my bug has been filed but the bug doesn't exist.
[07:24] <iwj> Subject: [Bug 29677]  Sound does not work properly in Flash in firefox
[07:24] <iwj> https://launchpad.net/products/launchpad/+bug/29677 = 404
[07:24] <Ubugtu> Error: Error getting Malone bug #29677: Bug does not exist
[07:25] <iwj> https://launchpad.net/bugs/29677 = 404
[07:25] <Ubugtu> Error: Error getting Malone bug #29677: Bug does not exist
[07:25] <iwj> Yes, Ubugtu, I know !
[07:26] <iwj> Oh, wow, one of these bugs has a bit of Emacs mail mode header junk in it.  Oh well.
[07:39] <carlos> SteveA, will we have a skype call today?
[08:00] <zyga> carlos: good day  :-)
[08:00] <carlos> zyga, hi
[10:01] <ddaa> lifeless: buildbot broken
[10:02] <ddaa> lifeless: I'm looking into cscvs right now, removing gnarly cruft as a warm up
[10:03] <ddaa> I'd like to put bzr support in ASAP, and I see no reason to keep on carrying the arch support
[10:03] <Nafallo> bzr sounds good to me. I'm a real bzr-fanboy since today :-)
[10:03] <Nafallo> (before that I was a fake fanboy ;-))
[10:04] <ddaa> how do you feel about a bunch of crack (the whole meta-cvs thing, in fact) getting removed to keep just the bit that matters: the foo->database logic and then the database->bzr logic?
[10:06] <ddaa> Nafallo: lot of work to do to get there, but I'm trying to avoid getting stuck into maintaining an insane cvs->baz->bzr toolchain.
[10:07] <Nafallo> I completly understand why :-)
[10:18] <sivang> ddaa: better kill it when it\'s still young
[10:19] <Nafallo> lol
[10:19] <Nafallo> nice wording :-)
[10:38] <sivang> Nafallo: I know ddaa will like it :)
[10:41] <lifeless> ddaa: not sure what you mean
[10:41] <lifeless> ddaa: FWIW today is a public holiday here
[10:42] <lifeless> if you mean the abstract VCS interface, thats about the only thing that made cscvs bearable to work with when dealing with svn and cvs at the same time
[10:51] <ddaa> ho, no, that's the good part of it
[10:53] <ddaa> I mean stuff like "checkout", "diff", etc.
[10:53] <ddaa> and cmds.todo
[10:53] <ddaa> anyway, have a nice holiday
[10:55] <lifeless> oh
[10:55] <lifeless> well frankly I'd ignore that
[10:55] <lifeless> as it has nothing to do with arch/bzr support
[10:55] <lifeless> and if we ever get to release cscvs again, its kinda useful
[11:18] <ddaa> well, if you say it's useful...
[11:18] <ddaa> and I do plan to get cscvs released, if only because I do want to spend the rest of my career fixing it.
[11:19] <ddaa> lifeless: so, what do you think of rooting out arch support?