loading but not much more :( [09:42] <skwashd> ok ... 3mins to load on about the 5th attempt ... SteveA maybe your call worked already ;) [09:43] <jamesh> skwashd: is it particular pages, or all pages? [09:43] <skwashd> jamesh: http://launchpad.net [09:43] <skwashd> sorry [09:44] <SteveA> hmm, seems responsive again now [09:44] <skwashd> https [09:44] <Fujitsu> Works for me... [09:44] <jamesh> maybe a problem with one app server? [09:44] <skwashd> yeah ... looks like the little gremlin has been put in the microwave [09:44] <seb128> jamesh: it was any bug page, back to normal now [09:44] <seb128> OOPS-332A434 [09:44] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/332A434 [09:44] <seb128> is one timeout I got [09:44] <SteveA> possibly a conflict with some conscript locking the database in some way [09:45] <SteveA> I'll ask stub to diagnose it [09:45] <lifeless> possibly [09:45] <seb128> grumpf [09:45] <lifeless> not a likely time for it [09:45] <seb128> it's still refusing to load that page [09:45] <seb128> https://launchpad.net/distros/ubuntu/+source/libgnomeui/+bug/60052 [09:45] <Ubugtu> Malone bug 60052 in libgnomeui "i was working with synaptic and firefox on xubuntu and this error popped out" [Undecided,Unconfirmed] [09:46] <seb128> it's slow agaijn in fact [09:46] <seb128> or not [09:46] <skwashd> yeah i was about to say that [09:47] <SteveA> lifeless: would you take a look at the database to see if there's anything obvious locking there? [09:48] <skwashd> it seems like one of the servers is in a DC and the other is in some geek's room ... circa 1993 ... 14.4 dialup ;) [09:48] <jamesh> seb128's page has a crash report, which hits the fmt:text-to-html performance problem [09:49] <lifeless> there is a poimport running [09:49] <mpt> hello lifeless [09:49] <lifeless> and a vacuum in progress [09:50] <SteveA> poimport and vacuum at the same time isn't so good [09:50] <mpt> lifeless, on bzr pqm-submit I get "bzr: ERROR: please run connect() first" [09:50] <mpt> How do I run connect()? [09:50] <lifeless> mpt: I'm busy right now, can you chat with jamesh or spiv about this please. [09:50] <mpt> ok [09:50] <lifeless> thanks [09:50] <mpt> spiv? [09:50] <lifeless> SteveA: yes. [09:51] <skwashd> SteveA: ok ... i will do something else for a while :) [09:51] <lifeless> ok, the vacuum is cancelled [09:51] <jamesh> mpt: that's probably an error from smtplib (problem talking to the SMTP server) [09:51] <lifeless> has that helped ? [09:51] <mpt> spiv, never mind, it mysteriously worked a second time [09:51] <stub> SteveA: pong [09:51] <skwashd> lifeless: uymmm ... not really here === lifeless hands over to stub [09:51] <seb128> lifeless: still seems slow to me [09:52] <lifeless> stub: lp is on go slow [09:52] <lifeless> stub - poimport is running, and vacuum; I just killed the vacuum but does not seme to have helped [09:52] <lifeless> it might be the textfmt bug though [09:52] <stub> You killed the vacuum? [09:52] <lifeless> stub: yes [09:53] <jamesh> seb128: if you go to https://launchpad.net/distros/ubuntu/+source/libgnomeui/+bug/60052/+edit and edit out the base-64 encoded crash dump, the bug page should load okay again [09:53] <Ubugtu> Malone bug 60052 in libgnomeui "i was working with synaptic and firefox on xubuntu and this error popped out" [Undecided,Unconfirmed] [09:53] <stub> I have no idea how that affects 8.1 :-( autovacuum is supposed to run all the time... [09:53] <seb128> jamesh: thank you for the hint [09:53] <lifeless> stub: gleep. [09:53] <seb128> I'll try when launchpad accepts to load a page again ;) [09:54] <jamesh> seb128: it's the new word breaking code -- it doesn't scale well to 200k character long words [09:54] <seb128> we should lart users doing that :) [09:54] <seb128> like don't accept the bug [09:54] <lifeless> stub: I killed the actual per-db vacuum, not the background task [09:54] <seb128> and suggest gently to attach that [09:54] <lifeless> stub: it starts them up automatically [09:55] <stub> yer - session database is being vacuumed, so looks ok. [09:55] <jamesh> seb128: apport tells the user to attach the crash report, and the +filebug page doesn't have an "attach file" box: Some percentage of users will paste it in the description. [09:56] <stub> There is some process connected as the 'ro' user, doing something hairy. Don't know what it is though. [09:56] <lifeless> stub: right, so it was on launchpad_prod before [09:56] <lifeless> 8848 ? [09:58] <stub> cronjobs are running anyway - karma update happening now [09:58] <stub> The ro connection is gone now [09:58] <stub> Just publisher, cron stuff, and normal launchpad. [09:58] <stub> And things are snappy [09:58] <stub> So possibly triggered by whatever runs before the karma updater === stub has a look === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [09:59] <stub> Just flag-expired-memberships which should be quick, and not running as the ro user. [09:59] <stub> Which leads me to suspect the publishing run doing something evil(er) [10:00] <stub> Perhaps the cronjobs conflicting with soyuz publisher. No way to tell now. [10:02] <stub> Oh... my mistake. No cronjobs - didn't look closely enough. it was just launchpad. [10:03] <stub> Mirror prober was running though at one point, so perhaps interfering with the publishing run. === carlos [n=carlos@75.Red-88-12-132.dynamicIP.rima-tde.net] has joined #launchpad [10:07] <carlos> morning [10:07] <mpt> a-ha [10:08] <mpt> The latest-specifications portlet says "No specifications registered" only if there both are AND aren't any specifications === jinty [n=jinty@177.Red-83-54-74.dynamicIP.rima-tde.net] has joined #launchpad === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === stu1 [n=stub@ppp-58.8.1.69.revip2.asianet.co.th] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:50] <mpt> jordi, did you see the request about adding wpmu for translation? [11:51] <jordi> mpt: not yet, rosetta list? [11:51] <jordi> I've been busy with the Open week [11:51] <jordi> let me open it up [11:51] <mpt> yes [11:51] <mpt> November 22 [11:52] <mpt> oops, sorry, November 17 [11:52] <jordi> hm, then I missed it last week [11:52] <mpt> (I received it on the 22nd for some reason) [11:52] <jordi> woops, so I moderated it, but didn't wait until it hit my mailbox [11:52] <jordi> man the amount of spam on this list is quite bad this days [11:55] <mpt> Well, think of it this way -- the better Free Software translation coverage becomes, the more people will use Free Software, the fewer computers will run Windows, the fewer computers will be botnet slaves, so the less spam you'll get :-) [11:55] <jordi> I love that POV :) [11:55] <jordi> replied [11:57] <jordi> Hungarian Magyar knyvtrak elibraries [11:57] <mpt> thanks [11:57] <jordi> I was about to approve that spam [11:57] <jamesh> so, I've fixed the word break algorithm to scale linearly with the number of characters in the word [11:58] <jamesh> for a 200000 character word, it brings the time down from 15.3s to 186ms [11:58] <jamesh> should fix the timeouts for pasted apport crash dumps [11:59] <mpt> well done! [11:59] <stu1> I'd opened a bug on this too [12:00] <stu1> I suggested having the code cap the number of characters in the string it is attempting to render to some very high but still renderable upper limit [12:00] <stub> (if len(foo) > 5000: foo = foo[:5000] + ' ...' [12:00] <jamesh> stu1: your bug is a bit broader -- my change just pushes the maximum length we can realistically support out a bit [12:02] <stub> Might be worth doing at the same time never the less. [12:02] <stub> I'm not sure what the upper limit should be though. Maybe 5k, maybe 20k [12:03] <jamesh> it'd be worth checking what size texts we've got currently. [12:04] <jordi> danilos: can you have a look at Subject: Lock down upstream translations in the rosetta-users list? [12:04] <jordi> basically, "how to avoid divergent translations" [12:05] <jordi> do we have an Official plan to address this? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:05] <jordi> I know about adding a filter, etc so they can easily be spotted and reverted [12:05] <danilos> jordi: carlos and I have already had some thoughts on this, need to check if we have a bug or spec regarding this (it looked so familiar when it popped up in yesterday's session as well) [12:06] <jordi> yep === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [12:08] <danilos> carlos: what are our plans re that? (i.e. things like adding "switch back to upstream translation" in review/translation interface?) [12:10] <stub> jamesh: https://devpad.canonical.com/~andrew/paste/filexzof8g.html [12:12] <jamesh> stub: could you check how many of those messages for each size contain the string "ProblemType: Crash"? [12:12] <jamesh> stub: just wondering where the real long comments start and apport reports begin ... [12:12] <jamesh> "real long comments end and apport reports begin", even [12:14] <stub> There are 61 bugs with that string in the description whose desciptions are > 20k in length === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:14] <stub> Out of 656 [12:14] <stub> So 1% of the silly descriptions [12:15] <stub> erm... 10% [12:16] <carlos> danilos: yes [12:16] <carlos> that + a filter to see the ones diverged [12:17] <jordi> carlos: noted, I'll reply accordingly [12:18] <jamesh> stub: I was thinking more a set of results with count(nullif(description like '%ProblemType: Crash%', true)) as an extra column [12:19] <jamesh> stub: to see the number of non apport dump descriptions at each size [12:21] <stub> jamesh: Not many. https://devpad.canonical.com/~andrew/paste/fileoqvRAR.html [12:22] <stub> https://devpad.canonical.com/~andrew/paste/file8XEh63.html [12:26] <jamesh> so, only a small handful for descriptions over 100k [12:26] <jamesh> still a handful for ones over 50k [12:34] <stub> Yup. But there is nothing to stop us getting more at this stage. [12:36] <jamesh> I was more thinking of this from the "how many legitimate messages may get truncated?" p.o.v. [12:37] <jamesh> where I'm ignoring the apport reports === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === niemeyer [n=niemeyer@200.138.132.233] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:21] <Keybuk> stub: around? I need a duckie [01:21] <stub> I'm your ducky [01:21] <Keybuk> can you fix a user account for me [01:22] <Keybuk> https://launchpad.net/people/katie [01:22] <Keybuk> can you make that a real account, with an e-mail address of archive@ubuntu.com [01:22] <stub> Should the email address be private or public? [01:22] <Keybuk> doesn't matter [01:22] <Keybuk> it gets sent to changes anyway :) [01:25] <stub> Keybuk: done [01:25] <Keybuk> thanks [01:25] <Keybuk> cool, soyuz is much happier now [02:08] <SteveA> kiko: ! [02:15] <Ubugtu> New bug: #73588 in launchpad-support-tracker "Ticket action page lacks link to the ticket overview." [Undecided,Unconfirmed] http://launchpad.net/bugs/73588 === Spads [n=spacehob@82.211.81.249] has joined #launchpad [02:54] <ddaa> SteveA: watercooler! === ddaa puts on funnel hat [02:56] <ddaa> watercooler is the key === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has joined #launchpad === ddaa puts off funnel hat [02:56] <ddaa> I mean about those phone calls we should have between buddie teams [02:56] <ddaa> let's just ostentiously call them watercooler calls [02:57] <ddaa> i.e. it's not about status reports, fixing problems, getting in sync, etc. It's about having a watercooler [02:57] <ddaa> or maybe a coffee machine [03:00] <malcc> Coffee machines have many beneficial effects on productivity it's true [03:01] <SteveA> ddaa: hello [03:01] <SteveA> I'm not cool enough to be at a watercooler [03:02] <ddaa> witticisms aside [03:02] <ddaa> during this morning's conf call I saw two issues [03:03] <ddaa> 1. the need to have regular calls with _thumper_ and I, on no specific topic [03:04] <ddaa> 2. this very conf call was unfocused although very interesting, and that made it a bit awkyard around the end because there was a feeling that a meeting needs to achieve some decision [03:04] <kiko> ddaa, btw [03:05] <kiko> ddaa, why does bzr branching off /products/bugzilla take so long? [03:05] <ddaa> Since there seems to be a recognized need for unfocused calls, we need a way to frame them so the lack of focus is not a source of discomfort. [03:05] <kiko> funny [03:05] <SteveA> I think it was a focused call [03:06] <SteveA> with unfocused parts [03:06] <kiko> I have unfocused calls all the time and they are a source of comfort. :) [03:06] <ddaa> kiko: offhand, the answer is probably 1. lots of data 2. lots of roundtrips [03:07] <kiko> ddaa, would the smartserver improve that? [03:07] <kiko> ddaa, can we run the smartserver on a rogue port on the supermirror? [03:07] <SteveA> kiko: there's a plan formenting to get the smartserver running there [03:07] <kiko> fermenting too? [03:07] <ddaa> spiv should get some wiki page up by tonight [03:07] <SteveA> spiv is due to post that today [03:07] <ddaa> so, smartserver will help a bit with latency [03:08] <ddaa> ultimately, it should allow flatlined-bandwidth branching, but it's not there yet [03:08] <kiko> ah. === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [03:09] <ddaa> there are plans to address data size issues, using ghost-revisions and pass-through locations. Dunno about the timeline for this. [03:10] <ddaa> kiko: you can try "bzr checkout --lightweight", that should reduce the amount of downloaded data [03:10] <kiko> right === ddaa workraves [03:11] <kiko> SteveA, lifeless: do you know anything about my suggestion for a dedicated importer box for the bzr team? === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:23] <SteveA> kiko: I just read it in an email. That is all I know. [03:23] <kiko> ok. === static_ [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad [04:12] <ddaa> kiko-fud: you want lennie [04:12] <ddaa> it's got a big head, a big stomach and big balls === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has left #launchpad ["trombone"] [04:14] <carlos> I need some help with timestamps in launchpad [04:14] <carlos> anyone with sometime to help me with this? [04:16] <carlos> BjornT, kiko-fud, jamesh, spiv? [04:17] <jamesh> carlos: what's the problem? [04:17] <kiko-fud> carlos, I'm out for a talk [04:18] <kiko-fud> ddaa, can you point j-a-meinel and poolie to it [04:18] <ddaa> just sent an email [04:18] <carlos> well, I'm getting CURRENT_TIMESTAMP AT TIME ZONE 'UTC' instead of dates [04:18] <carlos> even after commit [04:18] <carlos> and I need to do some date checks [04:18] <jamesh> you mean when reading back an SQLObject attribute? [04:19] <carlos> yes [04:19] <carlos> I think it's only an issue with tests === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad [04:19] <jamesh> committing should invalidate all the cached attributes on an SQLObject [04:20] <carlos> I know, that's why I'm using: [04:20] <jamesh> however, you can manually resynchronise an object with its sync() method [04:20] <jamesh> which will flush any changes and get the field values from the db [04:20] <carlos> >>> transaction.commit() [04:20] <carlos> >>> flush_database_caches() [04:21] <carlos> isn't that what flush_database_caches does? [04:21] <jamesh> (as opposed to syncUpdate(), which just flushes changes to the db [04:21] <jamesh> are you holding a reference to the object over a commit? [04:21] <carlos> yes [04:22] <kiko-fud> that's "bad" [04:22] <jamesh> is this a ZopelessLayer test, or a LaunchpadFunctionalLayer test? [04:22] <carlos> pagetest [04:22] <carlos> it's not a broken transaction [04:22] <carlos> and I'm doing the commit just to get a valid date [04:22] <jamesh> okay. The webapp does some weird things with SQLObject caches (it blows them away on each request) [04:22] <carlos> I thought it's only a problem when the transaction is aborted... [04:23] <jamesh> don't hold references to SQLObjects over transaction boundaries in the webapp or tests that use the webapp environment [04:23] <jamesh> (such as page tests) [04:23] <jamesh> see if that helps [04:24] <carlos> ok [04:24] <carlos> that makes the test more complex... but if that's the only way to use it... === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [04:32] <salgado> mpt, around? [04:32] <kiko-fud> is launchpad off? [04:32] <salgado> wfm [04:32] <kiko-fud> odd, nfm [04:33] <salgado> kiko-fud, how heavy do you think is the need for batching on the 1.0 product/project/distro search page? [04:34] <kiko-fud> salgado, it's expendable. nice to have but won't hold release for it. [04:34] <salgado> I'm not sure we can get batching if using the raw query stub suggested [04:35] <salgado> since the only API I can find is cursor.fetchmany() which only takes a size argument, not a start one [04:36] <flacoste> salgado: you need to take care of it yourself using LIMIT OFFSET in the SQL [04:37] <kiko-fud> right [04:37] <kiko-fud> salgado, are you smoking the wrong crack? :) === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [04:38] <salgado> yeah, the point is that I'm not sure it's worth [04:38] <salgado> I'd have to write a SelectResults-like class to feed the batch code [04:39] <salgado> and in there re-implement a bunch of stuff from sqlobject [04:39] <kiko-afk> ddaa, ping? [04:39] <kiko-afk> salgado, hmm, can't you just get an iterable... mmmm [04:39] <kiko-afk> salgado, if it's hard just leave it. [04:39] <ddaa> kiko-afk: pong [04:39] <salgado> a lazy iterable, it'd have to be [04:39] <ddaa> kiko-afk: your nick management sucks [04:40] <SteveA> salgado: I misread that as a lazy irritable [04:41] <SteveA> then I read "management" on ddaa's line afterwards [04:41] <SteveA> and all I got was "lazy irritable management" [04:41] <SteveA> I think I'll go get a cup of hot tea [04:41] <salgado> heh [04:42] <flacoste> salgado: you might want to nag stevea and niemeyer for launchpad storm support [04:42] <flacoste> should make that kind of stuff easier to implement [04:42] <salgado> I hope so [04:43] <salgado> but since this is a 1.0 spec, I think it'd be better to just use a hard limit and somehow display a warning to the user that we found too many results [04:43] <niemeyer> salgado: What's the issue? [04:43] <salgado> hey niemeyer [04:44] <salgado> https://launchpad.canonical.com/SearchingProjects [04:44] <salgado> we have this huge query on the bottom of that page === niemeyer checks [04:45] <salgado> and we can't use SQLObject for that, since we're selecting columns with the same name but from different tables [04:47] <salgado> and AFAIU, our IDBICursor doesn't give us a lazy SelectResults-like object as the return value [04:48] <niemeyer> Hmmm [04:49] <niemeyer> Ok.. the lazy results is solved in Storm.. [04:50] <niemeyer> Now, I'm not sure about what'd be the best way to turn that big union into an object. Is that what you're looking for? [04:50] <carlos> jamesh: same problem [04:51] <SteveA> flacoste: jamesh and niemeyer will be getting together early next year to work on storm in launchpad [04:52] <SteveA> niemeyer, jamesh: did you set a date for that yet? [04:52] <salgado> niemeyer, if I could feed that query into storm and get a lazy iterable back it should be all fine [04:52] <niemeyer> salgado: You can do it, of course [04:52] <carlos> jamesh: https://devpad.canonical.com/~andrew/paste/fileb9S823.html [04:52] <niemeyer> salgado: But isn't SQLObject able to do the same? [04:53] <carlos> that's the set of instructions executed [04:53] <niemeyer> salgado: I mean.. running a query by hand and getting results back should be feasible [04:53] <carlos> jamesh: pofile.importFromQueue modifies the pomsgset object [04:54] <niemeyer> SteveA: Nope.. no dates so far [04:54] <salgado> niemeyer, I can't use SQLObject for that since I'm not including all columns of all tables, so it can't generate an object from the data it gets from the DB [04:54] <niemeyer> SteveA: My suggestion is still first week of february [04:54] <salgado> I thought of using a view because then I could use an SQLObject to map that view [04:55] <carlos> jamesh: and pomsgset.isNewer has a couple of prints and one of those prints shows the SQL statement (it's not a direct field in pomsgset, but pomsgset.getSelection(index).date_reviewed) [04:55] <niemeyer> salgado: You can generate a query.. but isn't there a way to run the query straight into the connection (or close to it)? [04:55] <niemeyer> s/can/can't/ [04:56] <niemeyer> salgado: In that specific case, using an object doesn't offer many advantages over getting a tuple of values. [04:56] <salgado> niemeyer, yeah, but that returns a list of dictionaries and what I want is a SelectResults-like object [04:56] <SteveA> niemeyer, jamesh: please get some firm dates sorted and get visas / tickets etc. [04:57] <niemeyer> salgado: Ah.. I see.. the result isn't an interator you mean [04:57] <niemeyer> iterator [04:57] <salgado> niemeyer, I want this to feed our batching code. I could feed a list into it, but it would defeat the purpose of the batching since all the rows would have been fetched already [04:58] <carlos> jamesh: calling selection.sync() just before using the object is enough to fix it [04:58] <carlos> I hate cache problems :-( === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === kiko [n=kiko@200.18.99.75] has joined #launchpad [04:59] <niemeyer> salgado: Ok, got it [04:59] <niemeyer> salgado: Yeah, Storm allows you to do hand built queries in a more friendly way [05:02] <salgado> niemeyer, that's great. I think it's better for me to set a hard limit on the query now, and leave a note that this can be properly implemented once we get storm. :) [05:02] <niemeyer> carlos: Storm will fix that as well [05:03] <carlos> niemeyer: what's the roadmap for it? === niemeyer becomes a marketer.. [05:03] <carlos> at least, for it in launchpad... [05:03] <carlos> :-P [05:03] <niemeyer> carlos: For Storm, now - some months.. :) [05:03] <niemeyer> carlos: For Storm in Launchpad, we should get started in february [05:04] <carlos> is it already released or planned to be released outside the company? [05:04] <carlos> niemeyer: ok [05:04] <niemeyer> carlos: We were going to work on it in december, but we got caught on boring visa issues [05:04] <niemeyer> carlos: It is planned [05:04] <carlos> ok === carlos is pondering to play with it for other personal projects === joejaxx [i=jadaz87@ubuntu/member/joejaxx] has joined #launchpad === GSF [n=wasted@217.129.146.170] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad === giskard [n=giskard@213-140-22-74.fastres.net] has joined #launchpad [05:53] <giskard> hello * :) [05:53] <giskard> all translation made up on rosetta are copyright of? === dand [n=dand@gw.datagroup.ro] has joined #launchpad [05:57] <danilos> giskard: those who made them [05:57] <giskard> danilos, thank you! [05:58] <danilos> giskard: the only important bit is that canonical is allowed to redistribute them, and especially rosetta can put them as suggestions for any other project registered in launchpad [05:58] <sabdfl> good work in #ubuntu-classroom, kiko [05:58] <giskard> this is not a problem! [05:58] <kiko> thanks [06:00] <kiko> wow, that hurt [06:00] <kiko> my wrists are on fire! === static [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad === Neo|Laptop [n=NeoTherm@phpbb/support/pdpc.student.NeoThermic] has joined #launchpad [06:13] <Neo|Laptop> Hmm, exactly what is launchpad? === Spads [n=spacehob@host-87-74-89-151.bulldogdsl.com] has joined #launchpad [06:31] <ddaa> Neo|Laptop: it is a web site for collaboration of free software developers and users. === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === jkakar [n=jkakar@204.174.36.228] has joined #launchpad [06:38] <Neo|Laptop> ddaa: Ah, thanks. I noted someone registered on launchpad our software, but the user who did so isn't part of our team. I'm just wondering if this could become a problem (i.e. the user might try to claim that they are us) [06:38] <ddaa> We actually encourage this sort of thing, because registered products are useful for various things. [06:39] <ddaa> Generally, if an actual upstream developer wants to get ownership of the project, and if the user who first registered it is unresponsive, you can just ask a launchpad admin (in this chan) and we'll reassign it for you. [06:40] <SteveA> Neo|Laptop: there are some notices in Launchpad that say whether a project officially uses launchpad for various purposes, or whether it is just listed in launchpad [06:40] <ddaa> But it's more important to have the product registered by an active launchpad user than by some inactive "legitimate" person. [06:41] <Neo|Laptop> I see. === a7p [n=Albrecht@p54AE1BAC.dip0.t-ipconnect.de] has joined #launchpad [06:44] <a7p> hello everyone, kiko had a talk @ #ubuntu-classroom an one of his examples was https://launchpad.net/distros/ubuntu/+source/libaio/+bug/27810 .. doesn't this bug have to be closed? [06:44] <Ubugtu> Malone bug 27810 in libaio "libaio: We can't compile programs using it" [Unknown,Fix released] === rpedro [n=rpedro@87-196-42-148.net.novis.pt] has joined #launchpad [06:50] <matsubara> a7p: that question is better answered in #ubuntu-bugs [06:50] <a7p> matsubara, okay, thanks, I will ask there. [06:51] <matsubara> a7p: you're welcome === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === lbm [n=lbm@82.192.173.92] has joined #launchpad === Gwaihir [n=Gwaihir@ppp-27-110.25-151.libero.it] has joined #launchpad === somerville32 [i=somervil@fctnnbsc15w-156034064237.nb.aliant.net] has joined #launchpad [08:15] <kiko> hey flacoste [08:15] <kiko> how are you doing? [08:15] <kiko> ddaa, ping? [08:15] <kiko> BjornT, ping? [08:15] <kiko> carlos, ping? [08:15] <carlos> kiko: pong [08:15] <kiko> carlos! sorry for abandoning you yesterday, I was in dire straits [08:15] <flacoste> hey kiko, i'm doing fine, when you have time this week, i would probably like a 15mins chat on short-term priority [08:15] <ddaa> kiko: poing [08:16] <carlos> kiko: don't worry, I found an alternative UI easy to implement [08:16] <carlos> kiko: what I don't understand is how's that you said that TranslationReview will land today... [08:16] <carlos> kiko: I need to answer Bjorn's review first [08:16] <carlos> and then apply your UI comments [08:16] <carlos> so we can deploy it [08:17] <kiko> flacoste, I'm here -- wanna ring my vonage number? [08:17] <kiko> ddaa, I'm getting into the mindframe of trying to deal with deleting bzr branches [08:18] <ddaa> glad to hear that [08:18] <kiko> ddaa, what is the cheapest possible way we could solve that (beyond doing nothing) [08:18] <flacoste> kiko: what's a vonage number? we can do this on IRC if you like [08:18] <carlos> kiko: I need to leave now [08:18] <flacoste> but I can also use a real phone if you miss the sound of my voice... altough it's still rusty from that SF cold [08:18] <kiko> carlos, okay! [08:19] <kiko> carlos, well, I'm really concerned with the time TR is getting through landing. [08:19] <ddaa> kiko: check this https://blueprints.launchpad.net/products/launchpad-bazaar/+spec/delete-branches [08:19] <carlos> kiko: well, it's related to other tasks distracting me. I want to have everything done before leaving on Friday (I'm on holidays next week) [08:20] <kiko> carlos, I know. [08:20] <kiko> ddaa, thanks, looking into it. [08:20] <ddaa> kiko: once this spec is complete, the "cheapest way" is pretty much "everything except garbage collection" [08:21] <ddaa> arguably, it can be implemented and landed stepwise if the UI to actually delete branches is implemented last [08:21] <ddaa> but in terms of user experience, it just has to be a big chunk [08:46] <Ubugtu> New bug: #73637 in launchpad-support-tracker "Do not expire requests which are assigned to somebody" [High,Confirmed] http://launchpad.net/bugs/73637 [08:50] <Ubugtu> New bug: #73638 in launchpad-support-tracker "Add a reminder feature " [Low,Confirmed] http://launchpad.net/bugs/73638 [09:10] <kiko> so ddaa [09:10] <kiko> about delete branches [09:10] <kiko> can you modify the spec to be a "10CentBranchRemoval" sort of thing? [09:10] <kiko> you can: [09:10] <kiko> - omit handling of vcs-imports [09:10] <kiko> - omit garbage collection [09:11] <kiko> - omit any end-user UI (a button or script for an admin to run is fine for now) [09:11] <kiko> - omit undeletion [09:11] <kiko> ddaa, basically, making step 1 be the whole thing. [09:13] <ddaa> yes except, long as it is, it's not yet complete [09:13] <kiko> ddaa, can you elaborate? [09:13] <ddaa> Schema changes, UI changes, and To be determined [09:14] <ddaa> generally, deleting objects that may be used in foreign keys is pretty much unexplored territory in launchpad [09:14] <kiko> ddaa, maybe split the existing spec in two specs: basic and advanced removal? [09:15] <kiko> ddaa, but we're not suggesting deleting the objects [09:15] <kiko> just "hiding" them [09:15] <ddaa> same difference to the user [09:15] <kiko> it's the same thing indeed [09:15] <ddaa> if it's hidden an unaccessible is as good as deleted as far users can tell [09:15] <kiko> so I'm not sure what you're saying === somerville32 [i=somervil@fctnnbsc15w-156034082109.nb.aliant.net] has joined #launchpad [09:15] <kiko> you seem to be agreeing with me :) [09:15] <ddaa> Mh... so... right [09:17] <ddaa> if we can use introspection to assert that an object is referenced in no foreign key (except in some specific tables), we can split it into "simple deletion", "advanced deletion" and "garbage collection". [09:17] <ddaa> Where the dependency implementation looks like: simple -> advanced, simple -> garbage [09:17] <kiko> yeah [09:18] <kiko> I think that initially though we just want a way of saying "hide branch X" [09:18] <kiko> and the set of steps you outlined in 1. sounds good enough to me [09:19] <ddaa> if it's really hidden it also requires relaxing of the unique name constraint [09:20] <ddaa> and if we want to allow users to do it, we need some UI to undelete, which may be tricky because it cannot rely on unique names anymore... [09:20] <kiko> ddaa, we can just automatically rename it to foo-deleted [09:20] <kiko> ddaa, I don't care about users doing it for now [09:20] <kiko> I think unique names are the way to go [09:20] <ddaa> mh... [09:20] <kiko> just rename deleted ones [09:20] <kiko> like we do with merged people [09:21] <ddaa> SteveA suggested "foo--deleted[-N] " [09:21] <ddaa> yeah double dash [09:21] <kiko> that's fine by me [09:21] <kiko> arch pimp all you like [09:21] <kiko> ddaa, does that sound workable [09:21] <ddaa> double dash is fine because it's not something that people are likely to unintentionally conflict with [09:22] <ddaa> failing to register or rename a branch because of a name conflict with a deleted branch would be... very confusing. [09:22] <ddaa> kiko: so [09:22] <kiko> dude [09:22] <kiko> NOBODY will EVER register a -deleted branch [09:22] <kiko> this sort of confusion already exists today [09:22] <ddaa> kiko: you understimate your users [09:22] <kiko> with person names because if you use -merged you get toast [09:23] <kiko> and it has /never/ happened! === leonel [n=leonel@189.155.122.58] has joined #launchpad [09:23] <kiko> # Append a -merged suffix to the account's name. [09:23] <kiko> name = base = "%s-merged" % from_person.name.encode('ascii') [09:23] <kiko> cur.execute("SELECT id FROM Person WHERE name = %s" % sqlvalues(name)) [09:23] <kiko> ddaa, I don't. I am a realist. and in this case, it Really Doesn't Matter [09:24] <leonel> if launchpad is using python and postgresql what database driver uses Psycopg or Pygresql ? [09:24] <kiko> psycopg and sqlobject, leonel [09:24] <leonel> kiko: thanks . I'm starting a new development and was in doubt what to use [09:25] <ddaa> * database introspection to assert there are no foreign key to the branch except in the RevisionNumber table [09:25] <ddaa> * rename deleted branches to foo--deleted[-N] (-N in case of multiple deleted branches with the same initial name, it WILL happen) [09:25] <ddaa> * add Branch.deleted_date timestamp [09:25] <ddaa> * implement all of step 1 [09:25] <kiko> ddaa, that sounds good to me [09:25] <kiko> is this something you'd like to see solved for a 1.1? [09:25] <ddaa> well, that still lacks something [09:25] <ddaa> a good UI design [09:25] <kiko> just make a delete-branch script [09:25] <kiko> that I can ask stub to run on the server [09:25] <ddaa> Ah right [09:26] <ddaa> In this case, I'm keen to see it happen ASAP [09:26] <kiko> ddaa, okay. if you can modify that spec to be a BasicBranchDeletion and then add the other ideas to AdvancedBugDeletion I will add it to 1.1 and get you time to work on it [09:27] <ddaa> kiko: can you update the spec with the outcome of this discussion? With the three implementation steps (basic, advanced, collection). [09:27] <kiko> ddaa, how about you do it? :-) I am seriously blocking other people if I stop to do that and I fear my stack is so full.. === AlinuxOS [n=AlinuxOS@d83-190-224-39.cust.tele2.it] has joined #launchpad [09:28] <ddaa> kiko: oh well... send me an email with the highlight from this chat and I'll update the spec as soon as I get the round tuits. [09:29] <kiko> ddaa, okay [09:30] <ddaa> kiko: I think branch deletion is relatively low priority. If we fix the more important issues (hiding obsolete-merged branches, recovering from failure on first sftp push) we'll have covered 95% of the use cases. [09:31] <ddaa> But I agree it's important generally to evolve lp into circa 1984 user interface technology, you know, the garbage can... [09:31] <kiko> ddaa, right. I'm tackling sftp push issues with j-a-meinel, I'm now curious about obsolete-merged, and I think hiding branches would at least let me sleep soundly with no tickets on my back [09:32] <ddaa> kiko: https://launchpad.net/products/launchpad-bazaar/+bug/58889 [09:32] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [High,Confirmed] [09:33] <ddaa> combine this with a good naming convention for "branches that actually should be deleted" is good enough in the short term IMO. [09:34] <kiko> that's very easy to fix [09:40] <Ubugtu> New bug: #73644 in rosetta "provide language-support-sco" [Undecided,Needs info] http://launchpad.net/bugs/73644 [09:41] <elmo> is it unreasonable for me to expect "linux 2.6.17" to work as a search term and/or is there already a bug about this? [09:42] <kiko> elmo, not unreasonable, and I think there's already a bug open === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad === jorgp [n=jorgp@adsl-70-234-108-24.dsl.tul2ok.sbcglobal.net] has joined #launchpad === a7p [n=Albrecht@p54AE1BAC.dip0.t-ipconnect.de] has left #launchpad ["Ex-Chat"] === jml_ [n=jml@220-253-106-108.TAS.netspace.net.au] has joined #launchpad === jml_ is now known as jml === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === leonel [n=leonel@189.155.128.233] has joined #launchpad === doko_ [n=doko@dslb-088-073-088-217.pools.arcor-ip.net] has joined #launchpad === jml [n=jml@ppp110-150.lns1.hba1.internode.on.net] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad

[12:47] lifeless: you made a mistake on PendingReviews: you assigned your pending-reviews branch to yourself instead of jamesh like you said you did in your email === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad [01:13] flacoste: heh, whups [01:14] a page-down error [01:14] flacoste: thanks for pointing it out [01:14] no problem === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad ["Bye"] === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad === aleka [n=habesha@hrrsnbrg-bluewave1-69-161-7-92.chvlva.adelphia.net] has joined #launchpad [01:53] any active users on? === aleka [n=habesha@hrrsnbrg-bluewave1-69-161-7-92.chvlva.adelphia.net] has left #launchpad ["Leaving"] === BjornT [n=bjorn@clt-84-32-240-183.dtiltas.lt] has joined #launchpad === jml [n=jml@220-253-103-128.TAS.netspace.net.au] has joined #launchpad === ryanakca [i=ryan@unaffiliated/ryanakca] has joined #launchpad === stub [n=stub@ppp-58.8.13.237.revip2.asianet.co.th] has joined #launchpad === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [04:16] anybody alive from the LP team [04:16] ? === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === jml [n=jml@220-253-103-128.TAS.netspace.net.au] has joined #launchpad [04:27] Burgundavia: yeah. What's up? [04:27] I answered my own question about difference in urls === tristanb_ [n=tristan@spc1-pool2-0-0-cust30.cosh.broadband.ntl.com] has joined #launchpad === jml_ [n=jml@ppp110-150.lns1.hba1.internode.on.net] has joined #launchpad [04:36] Hi guys [04:37] apologies for my ignorance, but does Launchpad offer project hosting a la Sourceforce or Freshmeat? [04:38] every project I look at on there seems to import to Bazaar from CVS or SVN hosted elsewhere, so I'm a bit confused [04:39] tristanb_: you can host bzr branches on launchpad directly. [04:40] e.g. bzr does that :) === jml_ is now known as jml [04:41] tristanb_: There's a summary of how to do this at https://code.launchpad.net/ [04:41] spiv: thanks... so does that include things like allowing people to download release tarballs/debs/RPMs? [04:42] No, unfortunately. [04:42] It's just bzr branch hosting at the moment, rather than release files. [04:42] ah [04:43] that's a shame :( === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has left #launchpad ["trombone"] [04:48] Sourceforge it is then! :) === mpt [n=mpt@121-72-132-184.dsl.telstraclear.net] has joined #launchpad [05:01] Goooooooooooooooooooooood evening Launchpadders! [05:11] hi mpt [05:11] hey mpt, ajmitch [05:15] feels like it's reboot time for some more testing === daq4th [n=darkness@netstation-005.cafe.zSeries.org] has joined #launchpad === mpt [n=mpt@121-72-132-184.dsl.telstraclear.net] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === malcc [n=malcolm@host86-135-237-55.range86-135.btcentralplus.com] has joined #launchpad === glatzor [n=sebi@p549652D1.dip.t-dialin.net] has joined #launchpad === malcc [n=malcolm@host86-135-237-55.range86-135.btcentralplus.com] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === mpt [n=mpt@121-72-132-184.dsl.telstraclear.net] has joined #launchpad === jml [n=jml@ppp110-150.lns1.hba1.internode.on.net] has joined #launchpad === sevrin [n=sevrin@202.75.186.154] has joined #launchpad === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === stub [n=stub@ppp-58.8.13.237.revip2.asianet.co.th] has joined #launchpad === ryanakca [i=ryan@unaffiliated/ryanakca] has joined #launchpad === doko_ [n=doko@dslb-088-073-100-219.pools.arcor-ip.net] has joined #launchpad === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad === mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #launchpad === Spads [n=spacehob@host-87-74-89-151.bulldogdsl.com] has joined #launchpad === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #launchpad === jkakar-zzz [n=jkakar@204.174.36.228] has joined #launchpad === elmo [n=james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #launchpad === danilos [n=danilo@cable-89-216-150-96.dynamic.sbb.co.yu] has joined #launchpad === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #launchpad === static [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #launchpad === cprov-afk [n=cprov@monga.dorianet.com.br] has joined #launchpad === Seveas [n=seveas@ubuntu/member/seveas] has joined #launchpad === stgraber [i=stgraber@unaffiliated/stgraber] has joined #launchpad === sfllaw [i=sfllaw@debian/developer/coleSLAW] has joined #launchpad === ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #launchpad === SteveA [n=steve@costello.z3u.com] has joined #launchpad === spiv [n=andrew@218-214-66-203.people.net.au] has joined #launchpad === lamont [i=lamont@nat/hp/x-4caa1c6b665b1186] has joined #launchpad === [PUPPETS] Gonzo [i=gonzo@80.69.47.16] has joined #launchpad === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #launchpad === _thumper_ [i=user@166-179-22-143.jamamobile.co.nz] has joined #launchpad === zwnj [n=zwnj@194.225.70.57] has joined #launchpad === Fujitsu [n=william@ubuntu/member/fujitsu] has joined #launchpad === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad [08:56] morning [08:57] morning SteveA :-) === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === _thumper_ [i=user@166-179-22-143.jamamobile.co.nz] has left #launchpad [] [09:14] SteveA: I sent an email to the list about some possible traversal changes we might want now we've got mutliple domain names. Have you considered some of these issues already? === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad === Keybuk [n=scott@quest.netsplit.com] has joined #launchpad [09:26] jamesh: ping [09:27] lifeless: pong [09:28] see my pending-reviews patch ? [09:28] I got your email, but haven't looked at the patch yet [09:35] ok === skwashd [n=skwashd@phpgroupware/skwashd] has joined #launchpad [09:39] hi all [09:40] is it just me or is launchpad half dead atm? [09:40] skwashd: does seem slow [09:40] stub: ping [09:40] doesn't work for me [09:40] it doesn't load anything === SteveA calls ppl === skwashd gets as far as the loading but not much more :( [09:42] <skwashd> ok ... 3mins to load on about the 5th attempt ... SteveA maybe your call worked already ;) [09:43] <jamesh> skwashd: is it particular pages, or all pages? [09:43] <skwashd> jamesh: http://launchpad.net [09:43] <skwashd> sorry [09:44] <SteveA> hmm, seems responsive again now [09:44] <skwashd> https [09:44] <Fujitsu> Works for me... [09:44] <jamesh> maybe a problem with one app server? [09:44] <skwashd> yeah ... looks like the little gremlin has been put in the microwave [09:44] <seb128> jamesh: it was any bug page, back to normal now [09:44] <seb128> OOPS-332A434 [09:44] <Ubugtu> https://devpad.canonical.com/~jamesh/oops.cgi/332A434 [09:44] <seb128> is one timeout I got [09:44] <SteveA> possibly a conflict with some conscript locking the database in some way [09:45] <SteveA> I'll ask stub to diagnose it [09:45] <lifeless> possibly [09:45] <seb128> grumpf [09:45] <lifeless> not a likely time for it [09:45] <seb128> it's still refusing to load that page [09:45] <seb128> https://launchpad.net/distros/ubuntu/+source/libgnomeui/+bug/60052 [09:45] <Ubugtu> Malone bug 60052 in libgnomeui "i was working with synaptic and firefox on xubuntu and this error popped out" [Undecided,Unconfirmed] [09:46] <seb128> it's slow agaijn in fact [09:46] <seb128> or not [09:46] <skwashd> yeah i was about to say that [09:47] <SteveA> lifeless: would you take a look at the database to see if there's anything obvious locking there? [09:48] <skwashd> it seems like one of the servers is in a DC and the other is in some geek's room ... circa 1993 ... 14.4 dialup ;) [09:48] <jamesh> seb128's page has a crash report, which hits the fmt:text-to-html performance problem [09:49] <lifeless> there is a poimport running [09:49] <mpt> hello lifeless [09:49] <lifeless> and a vacuum in progress [09:50] <SteveA> poimport and vacuum at the same time isn't so good [09:50] <mpt> lifeless, on bzr pqm-submit I get "bzr: ERROR: please run connect() first" [09:50] <mpt> How do I run connect()? [09:50] <lifeless> mpt: I'm busy right now, can you chat with jamesh or spiv about this please. [09:50] <mpt> ok [09:50] <lifeless> thanks [09:50] <mpt> spiv? [09:50] <lifeless> SteveA: yes. [09:51] <skwashd> SteveA: ok ... i will do something else for a while :) [09:51] <lifeless> ok, the vacuum is cancelled [09:51] <jamesh> mpt: that's probably an error from smtplib (problem talking to the SMTP server) [09:51] <lifeless> has that helped ? [09:51] <mpt> spiv, never mind, it mysteriously worked a second time [09:51] <stub> SteveA: pong [09:51] <skwashd> lifeless: uymmm ... not really here === lifeless hands over to stub [09:51] <seb128> lifeless: still seems slow to me [09:52] <lifeless> stub: lp is on go slow [09:52] <lifeless> stub - poimport is running, and vacuum; I just killed the vacuum but does not seme to have helped [09:52] <lifeless> it might be the textfmt bug though [09:52] <stub> You killed the vacuum? [09:52] <lifeless> stub: yes [09:53] <jamesh> seb128: if you go to https://launchpad.net/distros/ubuntu/+source/libgnomeui/+bug/60052/+edit and edit out the base-64 encoded crash dump, the bug page should load okay again [09:53] <Ubugtu> Malone bug 60052 in libgnomeui "i was working with synaptic and firefox on xubuntu and this error popped out" [Undecided,Unconfirmed] [09:53] <stub> I have no idea how that affects 8.1 :-( autovacuum is supposed to run all the time... [09:53] <seb128> jamesh: thank you for the hint [09:53] <lifeless> stub: gleep. [09:53] <seb128> I'll try when launchpad accepts to load a page again ;) [09:54] <jamesh> seb128: it's the new word breaking code -- it doesn't scale well to 200k character long words [09:54] <seb128> we should lart users doing that :) [09:54] <seb128> like don't accept the bug [09:54] <lifeless> stub: I killed the actual per-db vacuum, not the background task [09:54] <seb128> and suggest gently to attach that [09:54] <lifeless> stub: it starts them up automatically [09:55] <stub> yer - session database is being vacuumed, so looks ok. [09:55] <jamesh> seb128: apport tells the user to attach the crash report, and the +filebug page doesn't have an "attach file" box: Some percentage of users will paste it in the description. [09:56] <stub> There is some process connected as the 'ro' user, doing something hairy. Don't know what it is though. [09:56] <lifeless> stub: right, so it was on launchpad_prod before [09:56] <lifeless> 8848 ? [09:58] <stub> cronjobs are running anyway - karma update happening now [09:58] <stub> The ro connection is gone now [09:58] <stub> Just publisher, cron stuff, and normal launchpad. [09:58] <stub> And things are snappy [09:58] <stub> So possibly triggered by whatever runs before the karma updater === stub has a look === seb128 [n=seb128@ubuntu/member/seb128] has joined #launchpad [09:59] <stub> Just flag-expired-memberships which should be quick, and not running as the ro user. [09:59] <stub> Which leads me to suspect the publishing run doing something evil(er) [10:00] <stub> Perhaps the cronjobs conflicting with soyuz publisher. No way to tell now. [10:02] <stub> Oh... my mistake. No cronjobs - didn't look closely enough. it was just launchpad. [10:03] <stub> Mirror prober was running though at one point, so perhaps interfering with the publishing run. === carlos [n=carlos@75.Red-88-12-132.dynamicIP.rima-tde.net] has joined #launchpad [10:07] <carlos> morning [10:07] <mpt> a-ha [10:08] <mpt> The latest-specifications portlet says "No specifications registered" only if there both are AND aren't any specifications === jinty [n=jinty@177.Red-83-54-74.dynamicIP.rima-tde.net] has joined #launchpad === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === stu1 [n=stub@ppp-58.8.1.69.revip2.asianet.co.th] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad [11:50] <mpt> jordi, did you see the request about adding wpmu for translation? [11:51] <jordi> mpt: not yet, rosetta list? [11:51] <jordi> I've been busy with the Open week [11:51] <jordi> let me open it up [11:51] <mpt> yes [11:51] <mpt> November 22 [11:52] <mpt> oops, sorry, November 17 [11:52] <jordi> hm, then I missed it last week [11:52] <mpt> (I received it on the 22nd for some reason) [11:52] <jordi> woops, so I moderated it, but didn't wait until it hit my mailbox [11:52] <jordi> man the amount of spam on this list is quite bad this days [11:55] <mpt> Well, think of it this way -- the better Free Software translation coverage becomes, the more people will use Free Software, the fewer computers will run Windows, the fewer computers will be botnet slaves, so the less spam you'll get :-) [11:55] <jordi> I love that POV :) [11:55] <jordi> replied [11:57] <jordi> Hungarian Magyar knyvtrak elibraries [11:57] <mpt> thanks [11:57] <jordi> I was about to approve that spam [11:57] <jamesh> so, I've fixed the word break algorithm to scale linearly with the number of characters in the word [11:58] <jamesh> for a 200000 character word, it brings the time down from 15.3s to 186ms [11:58] <jamesh> should fix the timeouts for pasted apport crash dumps [11:59] <mpt> well done! [11:59] <stu1> I'd opened a bug on this too [12:00] <stu1> I suggested having the code cap the number of characters in the string it is attempting to render to some very high but still renderable upper limit [12:00] <stub> (if len(foo) > 5000: foo = foo[:5000] + ' ...' [12:00] <jamesh> stu1: your bug is a bit broader -- my change just pushes the maximum length we can realistically support out a bit [12:02] <stub> Might be worth doing at the same time never the less. [12:02] <stub> I'm not sure what the upper limit should be though. Maybe 5k, maybe 20k [12:03] <jamesh> it'd be worth checking what size texts we've got currently. [12:04] <jordi> danilos: can you have a look at Subject: Lock down upstream translations in the rosetta-users list? [12:04] <jordi> basically, "how to avoid divergent translations" [12:05] <jordi> do we have an Official plan to address this? === matsubara [n=matsubar@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:05] <jordi> I know about adding a filter, etc so they can easily be spotted and reverted [12:05] <danilos> jordi: carlos and I have already had some thoughts on this, need to check if we have a bug or spec regarding this (it looked so familiar when it popped up in yesterday's session as well) [12:06] <jordi> yep === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad [12:08] <danilos> carlos: what are our plans re that? (i.e. things like adding "switch back to upstream translation" in review/translation interface?) [12:10] <stub> jamesh: https://devpad.canonical.com/~andrew/paste/filexzof8g.html [12:12] <jamesh> stub: could you check how many of those messages for each size contain the string "ProblemType: Crash"? [12:12] <jamesh> stub: just wondering where the real long comments start and apport reports begin ... [12:12] <jamesh> "real long comments end and apport reports begin", even [12:14] <stub> There are 61 bugs with that string in the description whose desciptions are > 20k in length === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad [12:14] <stub> Out of 656 [12:14] <stub> So 1% of the silly descriptions [12:15] <stub> erm... 10% [12:16] <carlos> danilos: yes [12:16] <carlos> that + a filter to see the ones diverged [12:17] <jordi> carlos: noted, I'll reply accordingly [12:18] <jamesh> stub: I was thinking more a set of results with count(nullif(description like '%ProblemType: Crash%', true)) as an extra column [12:19] <jamesh> stub: to see the number of non apport dump descriptions at each size [12:21] <stub> jamesh: Not many. https://devpad.canonical.com/~andrew/paste/fileoqvRAR.html [12:22] <stub> https://devpad.canonical.com/~andrew/paste/file8XEh63.html [12:26] <jamesh> so, only a small handful for descriptions over 100k [12:26] <jamesh> still a handful for ones over 50k [12:34] <stub> Yup. But there is nothing to stop us getting more at this stage. [12:36] <jamesh> I was more thinking of this from the "how many legitimate messages may get truncated?" p.o.v. [12:37] <jamesh> where I'm ignoring the apport reports === raphink [n=raphink@ubuntu/member/raphink] has joined #launchpad === niemeyer [n=niemeyer@200.138.132.233] has joined #launchpad === jsgotangco [n=jsg123@ubuntu/member/jsgotangco] has joined #launchpad [01:21] <Keybuk> stub: around? I need a duckie [01:21] <stub> I'm your ducky [01:21] <Keybuk> can you fix a user account for me [01:22] <Keybuk> https://launchpad.net/people/katie [01:22] <Keybuk> can you make that a real account, with an e-mail address of archive@ubuntu.com [01:22] <stub> Should the email address be private or public? [01:22] <Keybuk> doesn't matter [01:22] <Keybuk> it gets sent to changes anyway :) [01:25] <stub> Keybuk: done [01:25] <Keybuk> thanks [01:25] <Keybuk> cool, soyuz is much happier now [02:08] <SteveA> kiko: ! [02:15] <Ubugtu> New bug: #73588 in launchpad-support-tracker "Ticket action page lacks link to the ticket overview." [Undecided,Unconfirmed] http://launchpad.net/bugs/73588 === Spads [n=spacehob@82.211.81.249] has joined #launchpad [02:54] <ddaa> SteveA: watercooler! === ddaa puts on funnel hat [02:56] <ddaa> watercooler is the key === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has joined #launchpad === ddaa puts off funnel hat [02:56] <ddaa> I mean about those phone calls we should have between buddie teams [02:56] <ddaa> let's just ostentiously call them watercooler calls [02:57] <ddaa> i.e. it's not about status reports, fixing problems, getting in sync, etc. It's about having a watercooler [02:57] <ddaa> or maybe a coffee machine [03:00] <malcc> Coffee machines have many beneficial effects on productivity it's true [03:01] <SteveA> ddaa: hello [03:01] <SteveA> I'm not cool enough to be at a watercooler [03:02] <ddaa> witticisms aside [03:02] <ddaa> during this morning's conf call I saw two issues [03:03] <ddaa> 1. the need to have regular calls with _thumper_ and I, on no specific topic [03:04] <ddaa> 2. this very conf call was unfocused although very interesting, and that made it a bit awkyard around the end because there was a feeling that a meeting needs to achieve some decision [03:04] <kiko> ddaa, btw [03:05] <kiko> ddaa, why does bzr branching off /products/bugzilla take so long? [03:05] <ddaa> Since there seems to be a recognized need for unfocused calls, we need a way to frame them so the lack of focus is not a source of discomfort. [03:05] <kiko> funny [03:05] <SteveA> I think it was a focused call [03:06] <SteveA> with unfocused parts [03:06] <kiko> I have unfocused calls all the time and they are a source of comfort. :) [03:06] <ddaa> kiko: offhand, the answer is probably 1. lots of data 2. lots of roundtrips [03:07] <kiko> ddaa, would the smartserver improve that? [03:07] <kiko> ddaa, can we run the smartserver on a rogue port on the supermirror? [03:07] <SteveA> kiko: there's a plan formenting to get the smartserver running there [03:07] <kiko> fermenting too? [03:07] <ddaa> spiv should get some wiki page up by tonight [03:07] <SteveA> spiv is due to post that today [03:07] <ddaa> so, smartserver will help a bit with latency [03:08] <ddaa> ultimately, it should allow flatlined-bandwidth branching, but it's not there yet [03:08] <kiko> ah. === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [03:09] <ddaa> there are plans to address data size issues, using ghost-revisions and pass-through locations. Dunno about the timeline for this. [03:10] <ddaa> kiko: you can try "bzr checkout --lightweight", that should reduce the amount of downloaded data [03:10] <kiko> right === ddaa workraves [03:11] <kiko> SteveA, lifeless: do you know anything about my suggestion for a dedicated importer box for the bzr team? === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad [03:23] <SteveA> kiko: I just read it in an email. That is all I know. [03:23] <kiko> ok. === static_ [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad [04:12] <ddaa> kiko-fud: you want lennie [04:12] <ddaa> it's got a big head, a big stomach and big balls === lotusleaf [n=lotuslea@kernel-panic/member/carne.asada.burrito] has left #launchpad ["trombone"] [04:14] <carlos> I need some help with timestamps in launchpad [04:14] <carlos> anyone with sometime to help me with this? [04:16] <carlos> BjornT, kiko-fud, jamesh, spiv? [04:17] <jamesh> carlos: what's the problem? [04:17] <kiko-fud> carlos, I'm out for a talk [04:18] <kiko-fud> ddaa, can you point j-a-meinel and poolie to it [04:18] <ddaa> just sent an email [04:18] <carlos> well, I'm getting CURRENT_TIMESTAMP AT TIME ZONE 'UTC' instead of dates [04:18] <carlos> even after commit [04:18] <carlos> and I need to do some date checks [04:18] <jamesh> you mean when reading back an SQLObject attribute? [04:19] <carlos> yes [04:19] <carlos> I think it's only an issue with tests === Ubugtu [n=bugbot@ubuntu/bot/ubugtu] has joined #launchpad [04:19] <jamesh> committing should invalidate all the cached attributes on an SQLObject [04:20] <carlos> I know, that's why I'm using: [04:20] <jamesh> however, you can manually resynchronise an object with its sync() method [04:20] <jamesh> which will flush any changes and get the field values from the db [04:20] <carlos> >>> transaction.commit() [04:20] <carlos> >>> flush_database_caches() [04:21] <carlos> isn't that what flush_database_caches does? [04:21] <jamesh> (as opposed to syncUpdate(), which just flushes changes to the db [04:21] <jamesh> are you holding a reference to the object over a commit? [04:21] <carlos> yes [04:22] <kiko-fud> that's "bad" [04:22] <jamesh> is this a ZopelessLayer test, or a LaunchpadFunctionalLayer test? [04:22] <carlos> pagetest [04:22] <carlos> it's not a broken transaction [04:22] <carlos> and I'm doing the commit just to get a valid date [04:22] <jamesh> okay. The webapp does some weird things with SQLObject caches (it blows them away on each request) [04:22] <carlos> I thought it's only a problem when the transaction is aborted... [04:23] <jamesh> don't hold references to SQLObjects over transaction boundaries in the webapp or tests that use the webapp environment [04:23] <jamesh> (such as page tests) [04:23] <jamesh> see if that helps [04:24] <carlos> ok [04:24] <carlos> that makes the test more complex... but if that's the only way to use it... === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [04:32] <salgado> mpt, around? [04:32] <kiko-fud> is launchpad off? [04:32] <salgado> wfm [04:32] <kiko-fud> odd, nfm [04:33] <salgado> kiko-fud, how heavy do you think is the need for batching on the 1.0 product/project/distro search page? [04:34] <kiko-fud> salgado, it's expendable. nice to have but won't hold release for it. [04:34] <salgado> I'm not sure we can get batching if using the raw query stub suggested [04:35] <salgado> since the only API I can find is cursor.fetchmany() which only takes a size argument, not a start one [04:36] <flacoste> salgado: you need to take care of it yourself using LIMIT OFFSET in the SQL [04:37] <kiko-fud> right [04:37] <kiko-fud> salgado, are you smoking the wrong crack? :) === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad [04:38] <salgado> yeah, the point is that I'm not sure it's worth [04:38] <salgado> I'd have to write a SelectResults-like class to feed the batch code [04:39] <salgado> and in there re-implement a bunch of stuff from sqlobject [04:39] <kiko-afk> ddaa, ping? [04:39] <kiko-afk> salgado, hmm, can't you just get an iterable... mmmm [04:39] <kiko-afk> salgado, if it's hard just leave it. [04:39] <ddaa> kiko-afk: pong [04:39] <salgado> a lazy iterable, it'd have to be [04:39] <ddaa> kiko-afk: your nick management sucks [04:40] <SteveA> salgado: I misread that as a lazy irritable [04:41] <SteveA> then I read "management" on ddaa's line afterwards [04:41] <SteveA> and all I got was "lazy irritable management" [04:41] <SteveA> I think I'll go get a cup of hot tea [04:41] <salgado> heh [04:42] <flacoste> salgado: you might want to nag stevea and niemeyer for launchpad storm support [04:42] <flacoste> should make that kind of stuff easier to implement [04:42] <salgado> I hope so [04:43] <salgado> but since this is a 1.0 spec, I think it'd be better to just use a hard limit and somehow display a warning to the user that we found too many results [04:43] <niemeyer> salgado: What's the issue? [04:43] <salgado> hey niemeyer [04:44] <salgado> https://launchpad.canonical.com/SearchingProjects [04:44] <salgado> we have this huge query on the bottom of that page === niemeyer checks [04:45] <salgado> and we can't use SQLObject for that, since we're selecting columns with the same name but from different tables [04:47] <salgado> and AFAIU, our IDBICursor doesn't give us a lazy SelectResults-like object as the return value [04:48] <niemeyer> Hmmm [04:49] <niemeyer> Ok.. the lazy results is solved in Storm.. [04:50] <niemeyer> Now, I'm not sure about what'd be the best way to turn that big union into an object. Is that what you're looking for? [04:50] <carlos> jamesh: same problem [04:51] <SteveA> flacoste: jamesh and niemeyer will be getting together early next year to work on storm in launchpad [04:52] <SteveA> niemeyer, jamesh: did you set a date for that yet? [04:52] <salgado> niemeyer, if I could feed that query into storm and get a lazy iterable back it should be all fine [04:52] <niemeyer> salgado: You can do it, of course [04:52] <carlos> jamesh: https://devpad.canonical.com/~andrew/paste/fileb9S823.html [04:52] <niemeyer> salgado: But isn't SQLObject able to do the same? [04:53] <carlos> that's the set of instructions executed [04:53] <niemeyer> salgado: I mean.. running a query by hand and getting results back should be feasible [04:53] <carlos> jamesh: pofile.importFromQueue modifies the pomsgset object [04:54] <niemeyer> SteveA: Nope.. no dates so far [04:54] <salgado> niemeyer, I can't use SQLObject for that since I'm not including all columns of all tables, so it can't generate an object from the data it gets from the DB [04:54] <niemeyer> SteveA: My suggestion is still first week of february [04:54] <salgado> I thought of using a view because then I could use an SQLObject to map that view [04:55] <carlos> jamesh: and pomsgset.isNewer has a couple of prints and one of those prints shows the SQL statement (it's not a direct field in pomsgset, but pomsgset.getSelection(index).date_reviewed) [04:55] <niemeyer> salgado: You can generate a query.. but isn't there a way to run the query straight into the connection (or close to it)? [04:55] <niemeyer> s/can/can't/ [04:56] <niemeyer> salgado: In that specific case, using an object doesn't offer many advantages over getting a tuple of values. [04:56] <salgado> niemeyer, yeah, but that returns a list of dictionaries and what I want is a SelectResults-like object [04:56] <SteveA> niemeyer, jamesh: please get some firm dates sorted and get visas / tickets etc. [04:57] <niemeyer> salgado: Ah.. I see.. the result isn't an interator you mean [04:57] <niemeyer> iterator [04:57] <salgado> niemeyer, I want this to feed our batching code. I could feed a list into it, but it would defeat the purpose of the batching since all the rows would have been fetched already [04:58] <carlos> jamesh: calling selection.sync() just before using the object is enough to fix it [04:58] <carlos> I hate cache problems :-( === Burgundavia [n=corey@S0106000fb085cc63.gv.shawcable.net] has joined #launchpad === kiko [n=kiko@200.18.99.75] has joined #launchpad [04:59] <niemeyer> salgado: Ok, got it [04:59] <niemeyer> salgado: Yeah, Storm allows you to do hand built queries in a more friendly way [05:02] <salgado> niemeyer, that's great. I think it's better for me to set a hard limit on the query now, and leave a note that this can be properly implemented once we get storm. :) [05:02] <niemeyer> carlos: Storm will fix that as well [05:03] <carlos> niemeyer: what's the roadmap for it? === niemeyer becomes a marketer.. [05:03] <carlos> at least, for it in launchpad... [05:03] <carlos> :-P [05:03] <niemeyer> carlos: For Storm, now - some months.. :) [05:03] <niemeyer> carlos: For Storm in Launchpad, we should get started in february [05:04] <carlos> is it already released or planned to be released outside the company? [05:04] <carlos> niemeyer: ok [05:04] <niemeyer> carlos: We were going to work on it in december, but we got caught on boring visa issues [05:04] <niemeyer> carlos: It is planned [05:04] <carlos> ok === carlos is pondering to play with it for other personal projects === joejaxx [i=jadaz87@ubuntu/member/joejaxx] has joined #launchpad === GSF [n=wasted@217.129.146.170] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad === dand [n=dand@gw.datagroup.ro] has joined #launchpad === giskard [n=giskard@213-140-22-74.fastres.net] has joined #launchpad [05:53] <giskard> hello * :) [05:53] <giskard> all translation made up on rosetta are copyright of? === dand [n=dand@gw.datagroup.ro] has joined #launchpad [05:57] <danilos> giskard: those who made them [05:57] <giskard> danilos, thank you! [05:58] <danilos> giskard: the only important bit is that canonical is allowed to redistribute them, and especially rosetta can put them as suggestions for any other project registered in launchpad [05:58] <sabdfl> good work in #ubuntu-classroom, kiko [05:58] <giskard> this is not a problem! [05:58] <kiko> thanks [06:00] <kiko> wow, that hurt [06:00] <kiko> my wrists are on fire! === static [n=emurphy@194.18.118.70.cfl.res.rr.com] has joined #launchpad === Neo|Laptop [n=NeoTherm@phpbb/support/pdpc.student.NeoThermic] has joined #launchpad [06:13] <Neo|Laptop> Hmm, exactly what is launchpad? === Spads [n=spacehob@host-87-74-89-151.bulldogdsl.com] has joined #launchpad [06:31] <ddaa> Neo|Laptop: it is a web site for collaboration of free software developers and users. === mholthaus_ [n=mholthau@johnny33.dersbach.ch] has joined #launchpad === jkakar [n=jkakar@204.174.36.228] has joined #launchpad [06:38] <Neo|Laptop> ddaa: Ah, thanks. I noted someone registered on launchpad our software, but the user who did so isn't part of our team. I'm just wondering if this could become a problem (i.e. the user might try to claim that they are us) [06:38] <ddaa> We actually encourage this sort of thing, because registered products are useful for various things. [06:39] <ddaa> Generally, if an actual upstream developer wants to get ownership of the project, and if the user who first registered it is unresponsive, you can just ask a launchpad admin (in this chan) and we'll reassign it for you. [06:40] <SteveA> Neo|Laptop: there are some notices in Launchpad that say whether a project officially uses launchpad for various purposes, or whether it is just listed in launchpad [06:40] <ddaa> But it's more important to have the product registered by an active launchpad user than by some inactive "legitimate" person. [06:41] <Neo|Laptop> I see. === a7p [n=Albrecht@p54AE1BAC.dip0.t-ipconnect.de] has joined #launchpad [06:44] <a7p> hello everyone, kiko had a talk @ #ubuntu-classroom an one of his examples was https://launchpad.net/distros/ubuntu/+source/libaio/+bug/27810 .. doesn't this bug have to be closed? [06:44] <Ubugtu> Malone bug 27810 in libaio "libaio: We can't compile programs using it" [Unknown,Fix released] === rpedro [n=rpedro@87-196-42-148.net.novis.pt] has joined #launchpad [06:50] <matsubara> a7p: that question is better answered in #ubuntu-bugs [06:50] <a7p> matsubara, okay, thanks, I will ask there. [06:51] <matsubara> a7p: you're welcome === salgado [n=salgado@200-171-140-32.dsl.telesp.net.br] has joined #launchpad === lbm [n=lbm@82.192.173.92] has joined #launchpad === Gwaihir [n=Gwaihir@ppp-27-110.25-151.libero.it] has joined #launchpad === somerville32 [i=somervil@fctnnbsc15w-156034064237.nb.aliant.net] has joined #launchpad [08:15] <kiko> hey flacoste [08:15] <kiko> how are you doing? [08:15] <kiko> ddaa, ping? [08:15] <kiko> BjornT, ping? [08:15] <kiko> carlos, ping? [08:15] <carlos> kiko: pong [08:15] <kiko> carlos! sorry for abandoning you yesterday, I was in dire straits [08:15] <flacoste> hey kiko, i'm doing fine, when you have time this week, i would probably like a 15mins chat on short-term priority [08:15] <ddaa> kiko: poing [08:16] <carlos> kiko: don't worry, I found an alternative UI easy to implement [08:16] <carlos> kiko: what I don't understand is how's that you said that TranslationReview will land today... [08:16] <carlos> kiko: I need to answer Bjorn's review first [08:16] <carlos> and then apply your UI comments [08:16] <carlos> so we can deploy it [08:17] <kiko> flacoste, I'm here -- wanna ring my vonage number? [08:17] <kiko> ddaa, I'm getting into the mindframe of trying to deal with deleting bzr branches [08:18] <ddaa> glad to hear that [08:18] <kiko> ddaa, what is the cheapest possible way we could solve that (beyond doing nothing) [08:18] <flacoste> kiko: what's a vonage number? we can do this on IRC if you like [08:18] <carlos> kiko: I need to leave now [08:18] <flacoste> but I can also use a real phone if you miss the sound of my voice... altough it's still rusty from that SF cold [08:18] <kiko> carlos, okay! [08:19] <kiko> carlos, well, I'm really concerned with the time TR is getting through landing. [08:19] <ddaa> kiko: check this https://blueprints.launchpad.net/products/launchpad-bazaar/+spec/delete-branches [08:19] <carlos> kiko: well, it's related to other tasks distracting me. I want to have everything done before leaving on Friday (I'm on holidays next week) [08:20] <kiko> carlos, I know. [08:20] <kiko> ddaa, thanks, looking into it. [08:20] <ddaa> kiko: once this spec is complete, the "cheapest way" is pretty much "everything except garbage collection" [08:21] <ddaa> arguably, it can be implemented and landed stepwise if the UI to actually delete branches is implemented last [08:21] <ddaa> but in terms of user experience, it just has to be a big chunk [08:46] <Ubugtu> New bug: #73637 in launchpad-support-tracker "Do not expire requests which are assigned to somebody" [High,Confirmed] http://launchpad.net/bugs/73637 [08:50] <Ubugtu> New bug: #73638 in launchpad-support-tracker "Add a reminder feature " [Low,Confirmed] http://launchpad.net/bugs/73638 [09:10] <kiko> so ddaa [09:10] <kiko> about delete branches [09:10] <kiko> can you modify the spec to be a "10CentBranchRemoval" sort of thing? [09:10] <kiko> you can: [09:10] <kiko> - omit handling of vcs-imports [09:10] <kiko> - omit garbage collection [09:11] <kiko> - omit any end-user UI (a button or script for an admin to run is fine for now) [09:11] <kiko> - omit undeletion [09:11] <kiko> ddaa, basically, making step 1 be the whole thing. [09:13] <ddaa> yes except, long as it is, it's not yet complete [09:13] <kiko> ddaa, can you elaborate? [09:13] <ddaa> Schema changes, UI changes, and To be determined [09:14] <ddaa> generally, deleting objects that may be used in foreign keys is pretty much unexplored territory in launchpad [09:14] <kiko> ddaa, maybe split the existing spec in two specs: basic and advanced removal? [09:15] <kiko> ddaa, but we're not suggesting deleting the objects [09:15] <kiko> just "hiding" them [09:15] <ddaa> same difference to the user [09:15] <kiko> it's the same thing indeed [09:15] <ddaa> if it's hidden an unaccessible is as good as deleted as far users can tell [09:15] <kiko> so I'm not sure what you're saying === somerville32 [i=somervil@fctnnbsc15w-156034082109.nb.aliant.net] has joined #launchpad [09:15] <kiko> you seem to be agreeing with me :) [09:15] <ddaa> Mh... so... right [09:17] <ddaa> if we can use introspection to assert that an object is referenced in no foreign key (except in some specific tables), we can split it into "simple deletion", "advanced deletion" and "garbage collection". [09:17] <ddaa> Where the dependency implementation looks like: simple -> advanced, simple -> garbage [09:17] <kiko> yeah [09:18] <kiko> I think that initially though we just want a way of saying "hide branch X" [09:18] <kiko> and the set of steps you outlined in 1. sounds good enough to me [09:19] <ddaa> if it's really hidden it also requires relaxing of the unique name constraint [09:20] <ddaa> and if we want to allow users to do it, we need some UI to undelete, which may be tricky because it cannot rely on unique names anymore... [09:20] <kiko> ddaa, we can just automatically rename it to foo-deleted [09:20] <kiko> ddaa, I don't care about users doing it for now [09:20] <kiko> I think unique names are the way to go [09:20] <ddaa> mh... [09:20] <kiko> just rename deleted ones [09:20] <kiko> like we do with merged people [09:21] <ddaa> SteveA suggested "foo--deleted[-N] " [09:21] <ddaa> yeah double dash [09:21] <kiko> that's fine by me [09:21] <kiko> arch pimp all you like [09:21] <kiko> ddaa, does that sound workable [09:21] <ddaa> double dash is fine because it's not something that people are likely to unintentionally conflict with [09:22] <ddaa> failing to register or rename a branch because of a name conflict with a deleted branch would be... very confusing. [09:22] <ddaa> kiko: so [09:22] <kiko> dude [09:22] <kiko> NOBODY will EVER register a -deleted branch [09:22] <kiko> this sort of confusion already exists today [09:22] <ddaa> kiko: you understimate your users [09:22] <kiko> with person names because if you use -merged you get toast [09:23] <kiko> and it has /never/ happened! === leonel [n=leonel@189.155.122.58] has joined #launchpad [09:23] <kiko> # Append a -merged suffix to the account's name. [09:23] <kiko> name = base = "%s-merged" % from_person.name.encode('ascii') [09:23] <kiko> cur.execute("SELECT id FROM Person WHERE name = %s" % sqlvalues(name)) [09:23] <kiko> ddaa, I don't. I am a realist. and in this case, it Really Doesn't Matter [09:24] <leonel> if launchpad is using python and postgresql what database driver uses Psycopg or Pygresql ? [09:24] <kiko> psycopg and sqlobject, leonel [09:24] <leonel> kiko: thanks . I'm starting a new development and was in doubt what to use [09:25] <ddaa> * database introspection to assert there are no foreign key to the branch except in the RevisionNumber table [09:25] <ddaa> * rename deleted branches to foo--deleted[-N] (-N in case of multiple deleted branches with the same initial name, it WILL happen) [09:25] <ddaa> * add Branch.deleted_date timestamp [09:25] <ddaa> * implement all of step 1 [09:25] <kiko> ddaa, that sounds good to me [09:25] <kiko> is this something you'd like to see solved for a 1.1? [09:25] <ddaa> well, that still lacks something [09:25] <ddaa> a good UI design [09:25] <kiko> just make a delete-branch script [09:25] <kiko> that I can ask stub to run on the server [09:25] <ddaa> Ah right [09:26] <ddaa> In this case, I'm keen to see it happen ASAP [09:26] <kiko> ddaa, okay. if you can modify that spec to be a BasicBranchDeletion and then add the other ideas to AdvancedBugDeletion I will add it to 1.1 and get you time to work on it [09:27] <ddaa> kiko: can you update the spec with the outcome of this discussion? With the three implementation steps (basic, advanced, collection). [09:27] <kiko> ddaa, how about you do it? :-) I am seriously blocking other people if I stop to do that and I fear my stack is so full.. === AlinuxOS [n=AlinuxOS@d83-190-224-39.cust.tele2.it] has joined #launchpad [09:28] <ddaa> kiko: oh well... send me an email with the highlight from this chat and I'll update the spec as soon as I get the round tuits. [09:29] <kiko> ddaa, okay [09:30] <ddaa> kiko: I think branch deletion is relatively low priority. If we fix the more important issues (hiding obsolete-merged branches, recovering from failure on first sftp push) we'll have covered 95% of the use cases. [09:31] <ddaa> But I agree it's important generally to evolve lp into circa 1984 user interface technology, you know, the garbage can... [09:31] <kiko> ddaa, right. I'm tackling sftp push issues with j-a-meinel, I'm now curious about obsolete-merged, and I think hiding branches would at least let me sleep soundly with no tickets on my back [09:32] <ddaa> kiko: https://launchpad.net/products/launchpad-bazaar/+bug/58889 [09:32] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [High,Confirmed] [09:33] <ddaa> combine this with a good naming convention for "branches that actually should be deleted" is good enough in the short term IMO. [09:34] <kiko> that's very easy to fix [09:40] <Ubugtu> New bug: #73644 in rosetta "provide language-support-sco" [Undecided,Needs info] http://launchpad.net/bugs/73644 [09:41] <elmo> is it unreasonable for me to expect "linux 2.6.17" to work as a search term and/or is there already a bug about this? [09:42] <kiko> elmo, not unreasonable, and I think there's already a bug open === cprov [n=cprov@monga.dorianet.com.br] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === dand [n=dand@dyn-85.186.137.18.tm.upcnet.ro] has joined #launchpad === WebMaven [n=webmaven@ip72-193-220-34.lv.lv.cox.net] has joined #launchpad === jorgp [n=jorgp@adsl-70-234-108-24.dsl.tul2ok.sbcglobal.net] has joined #launchpad === a7p [n=Albrecht@p54AE1BAC.dip0.t-ipconnect.de] has left #launchpad ["Ex-Chat"] === jml_ [n=jml@220-253-106-108.TAS.netspace.net.au] has joined #launchpad === jml_ is now known as jml === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad === leonel [n=leonel@189.155.128.233] has joined #launchpad === doko_ [n=doko@dslb-088-073-088-217.pools.arcor-ip.net] has joined #launchpad === jml [n=jml@ppp110-150.lns1.hba1.internode.on.net] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad === belito [n=user@201.230.49.33] has joined #launchpad