[12:25] <stub> I don't think it is an absolute requirement that Ubuntu becomes a profit centre itself - a free open source platform is required for other projects. I suspect that Ubuntu would not exist except that Red Hat changed its licencing model.
[12:31] <TD> i highly doubt that
[12:31] <TD> i think mark had a lot of money and time, and wanted to do something cool
[12:33] <ddaa> ha... nice to see roomba humming again :)
[12:33] <ddaa> stub: I guess the right person to ask is spiv, but since it's db related you might have heard of it. Did you hear of an thread-safety issue in sqlos?
[12:34] <ddaa> I get a ton of very strange sqlos errors in hoover...
[12:34] <stub> ddaa: No. Haven't heard of one.
[12:34] <stub> ddaa: Such as?
[12:35] <ddaa> stuff like "TypeError: already prepared" when committing.
[12:35] <ddaa> or "ProductRelease ID=39 has been deleted"
[12:35] <ddaa> or "Changeset 35935 has been deleted"
[12:36] <ddaa> out of memory, so it's not very accurate
[12:36] <stub> Rosetta is triggering something like the second one (The initZopeless import script, I believe, so it might be an SQLObject issue)
[12:36] <stub> Never seen anything like the first one
[12:37] <ddaa> Bah... I'll check with lifeless next week. I have plenty of non-buildbot related stuff to keep busy until then.
[12:38] <stub> Email me some tracebacks if you come across them
[12:40] <ddaa> okay... I'll think about it.
[12:40] <ddaa> gnight folks
[12:50] <TD> you guys realise that rosetta is hopelessly unreliable, right?
[12:50] <TD> it keeps giving my translators errors
=== TD is now known as TD[gone] 
=== elmo [~james@83.216.141.215]  has joined #launchpad
[03:18] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Milestone table and soyuz indexes. Humanify sourcepackagename selection and improve bugactivity (patch-1143, stuart.bishop@canonical.com)
=== debonzi [~debonzi@201.13.140.2]  has joined #launchpad
[03:43] <debonzi> Chegou
[03:44] <debonzi> ops.. :)
[03:54] <stub> TD: Some errors they may be aware of, others not. Bug reports are good (as are bug reports about the bug tracker...)
=== debonzi [~debonzi@201.13.140.2]  has left #launchpad [] 
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk]  has left #launchpad [] 
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk]  has joined #launchpad
=== mdz [~mdz@69-167-148-207.vnnyca.adelphia.net]  has joined #launchpad
=== fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk]  has left #launchpad [] 
[09:06] <jblack> Does anybody have a sane keysigning script? keybuk's breaks on me
[09:08] <lifeless> kinnison claims to
[09:09] <jblack> I looked at his. Overly complicated.
[09:09] <jblack> its also a nag. if you you don't accept the signature, it keeps trying again and again and again.
=== jblack considers writing one
[09:11] <lifeless> whats wrong with keybuks ?
[09:12] <jblack> It breaks for me on some keys.
[09:12] <jblack> Remember when it broke on me on your key, and it sent your key to everyone on my keyring? 
[09:12] <lifeless> well we think thats what it did :)
[09:12] <jblack> That happened to me again, this time tefleo after mataro
[09:12] <lifeless> as we haven't decrypted any of those emails...
[09:12] <jblack> Yeah. Hard to tell, since it was encrypted to you. :) 
=== stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au]  has joined #launchpad
[10:17] <lifeless> stub: I think we do need a db update
[10:18] <stub> we do?
[10:18] <lifeless> the rosetta daemon is dying with 'no id field' tracebacks from sql
[10:19] <lifeless> I'm guessing here...
[10:19] <stub> Do you have the traceback? It might have been a skipped patch
=== stub checks the logs on macquarie
[10:26] <stub> lifeless: It isn't a database schema issue (POMsgID missing id). It is SQLObject or SQLOS wierdness.
[10:28] <ddaa> lifeless: buildbot has similar errors in hoover
[10:28] <ddaa> lifeless: I'd like if you could have a look at it. I'm keen on maintaining buildbot, providing you hand over something that _sorta works_....
[10:28] <stub> ddaa: If you are talking about the exceptions you mentioned before, I think it is a seperate issue
[10:29] <ddaa> stub: there are also "no id fields" errors in the lot.
=== ddaa -> breakfast
=== morgs [~morganc@wblv-146-212-199.telkomadsl.co.za]  has joined #launchpad
[11:31] <lifeless> ddaa: worked fine for me.
[11:32] <ddaa> hu... there must be a misunderstanding
[11:33] <ddaa> https://macquarie.warthogs.hbd.com/hoover/status/w3m/events/172/log
[11:34] <ddaa> all the sync jobs in hoover fail
[11:35] <ddaa> with various errors
[11:35] <ddaa> most of them seems related to sqlos
[11:35] <ddaa> any insightL
[11:35] <ddaa> ?
[11:36] <lifeless> taxi is probably calling commit() too often, or sqlobject has been changed again
[11:37] <lifeless> buildbot was out of date
[11:38] <ddaa> Hu? Since there is no official "production buildbot" it's hard for me to make sense of this statement.
[11:39] <ddaa> You mean "devel buildbot has useful fixes for production"?
[11:39] <lifeless> ddaa: there is to a production buildbot. 'configs/canonical.com/launchpad/proudcition-X'
[11:40] <lifeless> ok, taxi looks fully up to date 
[11:40] <lifeless> so thats not it.
[11:40] <lifeless> https://macquarie.warthogs.hbd.com/hoover/status/w3m/events/172/log <- can you mail that to spiv & stub ?
[11:40] <lifeless> that certainly doesn't look like a buildbot problem
[11:41] <stub> I suspect SQLOS or SQLObject is swallowing the real exception :-(
[11:41] <lifeless> any db errors ?
[11:41] <lifeless> (that exception is from sqlobject)
[11:41] <ddaa> lifeless: the launchpad config is useless for buildbot sinc it specifies devel for buildbot cscvs, etc.
[11:42] <lifeless> ddaa: thats deliberate.
[11:43] <ddaa> I can accept that. But that also means that there is no "production builldbot". Out of the 4 buildbot configs in production there were not two remotely similar configs.
[11:43] <lifeless> I'm happy for you to have separate buildbot production snapshots, as you've done, but you must keep them in lockstep with the launchpad ones for the launchpad, sqlobject, sqlos, pscyopgda, and zope categories
=== SteveA [~steve@adsl-213-190-44-43.takas.lt]  has joined #launchpad
[11:44] <ddaa> launchpad seems not to make snapshots for those infrastructures btw...
[11:44] <lifeless> ddaa: again, thats deliberate. the bits that are changing are branched, the others aren't.
[11:49] <stub> daf: ping
[11:49] <ddaa> that statemest seems not to be true. zope, sqlos and sqlobject have changes, but none has production branches.
[11:50] <ddaa> Apparently, there seems to be no attributed value in being able to restore the exact snapshot of a past production config.
[11:50] <lifeless> ddaa: their changes have all been immediately pushed to production. they are not being actively developed on by us might be a better expression that the literal minded will be less inclined to poke holes in.
[11:51] <lifeless> ddaa: thats not what I created production configs for.
[11:51] <ddaa> you tell me
[11:52] <lifeless> ?
[11:52] <ddaa> what did you create production configs for?
[11:52] <stub> I think I'm using the procedure ddaa wants for the dogfood server. I'm happy to document this procedure for production too (once we get a mesh-merge baz being used by PQM)
[11:52] <lifeless> to allow backporting of specific fixes without pulling the latest code, in a robust fashion.
[11:53] <lifeless> stub: snapping full tree configs is trivial.
[11:54] <ddaa> okay... so that is "version control for the present", not "for the past". You are only interested in the latest prod and the latest devel. Historical production configs are irrelevent. Right?
[11:54] <lifeless> right
[11:54] <ddaa> Then why are there lanchpad/production-1.* configs?
[11:55] <lifeless> I've no objection for them being used for recording the past as well.
[11:55] <lifeless> ddaa: I make a new one when I create new branches.
[11:56] <lifeless> until recently we didn't have baz on the servers, so I couldn't switch between branches trivially, I used a little shell foo to do cross-file apply-delta magic.
[11:56] <ddaa> my point is that by not making snapshot (only using fqver and not fqrev in the config) they cannot record the past accurately. I understand that is not a goal. So it's just that those multiple launchpad-1.* did not fit in the picture.
[11:57] <ddaa> Okay, so no deep reason. It was handy at a point, it does not hurt. It's just a little misleading but nobody in charge cares.
=== ddaa feels more comfortable with the idea now
[11:59] <lifeless> I'll probably do a script to do precise snapping at some point, as we do have switch now.
[11:59] <ddaa> hu... done...
[11:59] <lifeless> oh the other reason for production-X files is to line up with database schema rollouts.
[12:00] <lifeless> (in fact that is the primary reason for different production configs).
[12:00] <lifeless> w.r.t. historical versions, you need to see that we cannot roll back to arbitrary versions - the database schema has to lock-step with the code.
[12:01] <ddaa> there are "snapshot" and "update-config" scripts in david.allouche@canonical.com--2004/utils--devel--0. I used them on roomba yesterday.
[12:01] <lifeless> put them in dists please
[12:02] <ddaa> duh... those are ugly ugly dangerous hacks
[12:02] <lifeless> then don't point me at them :)
[12:02] <ddaa> "update-config" should probably be renamed "switch-config" btw.
[12:02] <ddaa> I point them at you so you can audit them.
[12:02] <lifeless> why don't you code up switch-config for baz :)
[12:03] <ddaa> because I already have significantly more work than I can do.
[12:03] <stub> The makefile in stuart.bishop@canonical.com/dists--stub--0 does snapshots for dogfood
[12:03] <ddaa> I'll make a compilation of the various interesting error message in hoover, and send them to you, stub and spiv.
[12:04] <lifeless> K
[12:04] <lifeless> that one you showed me is bizarre, and I know of no reason for it.
[12:04] <ddaa> lifeless: that's the rarest one
=== abelli [~abelli@84.222.38.206]  has joined #launchpad
[12:05] <jordi> q
[12:05] <abelli> ciao
[12:05] <abelli> will bazaar be compatible with gforge?
[12:12] <ddaa> lifeless: about hoover, another weird one (and unique) upx-ucl-beta has been stuck in mirrorTarget for 22 hours now. https://macquarie.warthogs.hbd.com/hoover/status/waterfall?criteria=%5Eupx-ucl-beta%24
[12:12] <ddaa> No log.
=== lifeless_ [~robertc@dsl-43.6.240.220.rns01-kent-syd.dsl.comindico.com.au]  has joined #launchpad
=== lifeless_ is now known as lifeless
[12:36] <lifeless> abelli: what d you mean ?
[12:37] <abelli> will i be able to use it with gforge...which actually supports svn
[01:02] <lifeless> bazaar is currently compatible with Gnu Arch.
[01:03] <lifeless> interoperating with svn isn't a high priority - but providing data migration tools is.
[01:03] <abelli> ok thank you..
=== morgs [~morganc@wblv-146-212-199.telkomadsl.co.za]  has joined #launchpad
=== carlos_ [~carlos@69.Red-80-33-181.pooles.rima-tde.net]  has joined #launchpad
=== TD[gone]  is now known as TD
=== carlos_ is now known as carlos
=== mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== mvo__ [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== mvo__ is now known as mvo
=== mvo__ [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== mvo__ is now known as mvo
=== TD is now known as TD[gone] 
=== ddaa [~ddaa@deep-thought.xlii.org]  has joined #launchpad
=== mvo__ [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== TD[gone]  is now known as TD
=== mvo__ [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== mvo [~egon@ip181.135.1511I-CUD12K-01.ish.de]  has joined #launchpad
=== ..[topic/#launchpad:SteveA] : Welcome to the lunch-pad.
=== kiko [~kiko@200-206-134-238.async.com.br]  has joined #launchpad
=== stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au]  has joined #launchpad