[01:13] so [01:13] all quite in the land of pret. [01:13] quiEt [01:13] sabdfl, house empty once again? === elmo_ [~james@george.kkhotels.co.uk] has joined #launchpad === kiko is now known as kiko-afk === cprov [~cprov@george.kkhotels.co.uk] has joined #launchpad [02:19] elmo_: ping [02:22] hey [02:22] elmo_: does changes@db.warthogs.hbd.com works now ? [02:22] should do? [02:23] elmo_: I regenerated my ssh key and and I trying to send it there without success .. [02:23] elmo_: do you have already data about the bandwidth requirements to be an ubuntu mirror? [02:24] carlos: no [02:24] ok [02:25] SSH Auth Keys : ssh-dss AAAAB3Nz..Ag/B2w== cprov@rebecca [02:25] cprov: that's the key right? [02:26] elmo_: yes, looks like my one [02:27] cprov: but I didn't receive the email with the results, is it normal ? [02:27] elmo_: as the same as is happining with PQM [02:27] elmo_: can you see any strange relation amoung this things ? [02:28] meh, I'll be up in a sec [02:28] elmo_: ok === carlos is downgrading his SID server into warty. Don't do it in home!!! [02:45] cprov: nothing in postfix logs for 'cprov' or 'async', so please ask lifeless ... [02:58] elmo_: ok, thank you for your help [03:39] PQM rejects email if your envelope from address doesn't resolve [03:40] learned that the hard way setting up my laptop the last time. [03:40] gotta make sure /etc/mailname is a domain that exists [04:04] !lilo:*! For those of you who are interested in the US presidential debates: #debates and #debatesdiscuss .... thanks. [04:05] !lilo:*! oops, #debates and #debatediscuss [08:56] lifeless: around? === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad === BradB [~bradb@george.kkhotels.co.uk] has joined #launchpad [12:32] sabdfl: sortof [12:32] wassup ? === BradB hacks up a unit test for SQLMethod, which may be a cool way to 1. vastly speed up database operations by attaching bare SQL to methods and 2. allow you to specify a class name that can act as the SelectResults for the results this thing returns (so that, as long as you define an __iter__, the behaviour of the results returned is limited only by your imagination.) [12:33] lifeless: i had a bad pqm experience last night [12:33] my merge sent pqm into an infinite loop [12:33] you hadn't mirrored ? [12:33] not the usual one, a new one [12:33] i'd mirrored all right [12:33] ok. [12:33] eek. [12:33] please could you check its logs to see what happened [12:34] and I'm about to do anoter pqm message, let's see if it blows up in the same way [12:34] you got james to kill it ? [12:37] lifeless: yes [12:37] it ran about 10 times before we just killed it [12:37] ok I've found the failed patch [12:37] ok, new one is on the wire [12:37] request that is.. [12:37] simulating it now. [12:39] simulated it fine on my laptop last night [12:39] simulating it on chinstrap :) [12:39] which still has occasional random segfaults and weirdness. [12:47] I think its the same bug - the one in my tla branch that I haven't tracked down yet. === lifeless raises the priority on that even higher. [12:55] 20 minutes and still no sign of success / failure. lifeless, is it spinning? [01:00] sabdfl: not afaict === elmo_ [~james@82.211.81.249] has joined #launchpad [01:02] I just tested it there on chinstrap and it worked for me [01:03] its building the config again though, which is not a good thing [01:04] lifeless: any chance you can quiesce buildbot on chinstrap at some point in the next 8 hours or so, so I can reboot chinstrap? [01:04] elmo_: when coreutils finishes, sure. [01:04] I'll put it in offline mode now [01:04] lifeless: excellent, thanks [01:04] actually, its quiet now. [01:05] 16680 patches in coreutils [01:05] :) [01:05] that'll be kicking it off monday morning on galapagos [01:06] oh, galapagos too, pls, if it's running [01:07] elmo_: macquarie too ? [01:07] lifeless: yeah - tho that isn't running persisent jobs like chinstrap is it? [01:07] lifeless: pqm situation? [01:07] sabdfl: watching it [01:08] elmo_: yes macquarie + galapagos run jobs all the time, automatically. [01:08] I'm taking them both offline now, as they happened to be idle. [01:08] let me know when I can restart them, [01:09] elmo_: done [01:10] sabdfl: you should have had email, [01:10] it finished its run, and it didn't abort or hang [01:11] sabdfl: ah, my bad. [01:11] I'll correct the error you got [01:11] yowser, never seen that before [01:11] and you never should [01:12] ok resubmit the merge please. [01:12] I'll hang around for it to finish. [01:32] lifeless: galapagos is back up [01:33] lifeless: btw, arch-pqm.log is full of whining about the lockfile - dunno if that's normal or not [01:38] lifeless: still no result [01:40] elmo_: its normal, just means that a run took more than one minute. [01:49] sabdfl: its failing on the commit. [01:49] I'm correcting it now [01:50] whats the error caused by? [01:53] These explicit ids have no corresponding file: [01:53] lib/canonical/launchpad/database/.arch-ids/archarchive.pyc.id [01:53] lib/canonical/launchpad/database/.arch-ids/archbranch.pyc.id [01:53] lib/canonical/launchpad/database/.arch-ids/archchangeset.pyc.id [01:53] I think. [01:54] yes, definately. [01:55] you've hit a bug that has (IIRC) been corrected in the release james was working on before toms 'new process'. [01:55] in your launchpad, run tla delete for each of those files. [01:55] the commit, and submit the merge again. [01:55] I'll add a TODO to have pqm more clearly tell you about this. [01:57] ok, bug added against me for that. [01:59] can you guys shout when you're done and I'll "quickly" reboot chinstrap [02:02] lifeless: ok, pqm incoming [02:05] let me know when yoiu get a result, so I can go home :) [02:11] lifeless: still no result [02:21] lifeless: STILL not result [02:24] lifeless: any sign of life? [02:32] sorry, had laptop closed here [02:33] no further assertions raised, digging now [02:34] so did it fail? [02:36] I've done it by hand [02:37] the lock file was held from the run I'd aborted. [02:37] adding another todo to detect stale locks [02:38] ok, you should be fine now. [02:39] I'm off home.. gnight all. [02:52] night lifeless [02:52] does that mean it completed successfully? === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [03:14] hey there [03:14] lol [03:14] where are there sandwich sprinters [03:16] on their way home [03:16] and the datacenter? [03:18] hmm, was going okay until I hit a "/dev/hahasucker has gone 210 days without being checked, check forced" [03:22] how long has it been? [03:22] since it's started running I mean. [03:23] hmm? [03:24] the fsck? [03:27] oh, dunno, 20 minutes or so now, I think [03:29] jesus. [03:29] how was this week, then? any interesting news? [04:31] duh... looks like the infoImporter was broken by the launchpad reorganisations... [04:38] Where is the the sql-object-ish thing for SoyuzProduct now? [04:38] Have to do something like "query = SoyuzProduct.select(SoyuzProduct.q.name == 'unassigned')" [05:02] ddaa: user Product [05:02] use Product, sorry === ddaa greps "class Product" [05:04] canonical.soyuz.importd.ProductMapper? [05:04] Sorry if I'm asking silly question, I'm completely behind in soyuz evolutions... [05:06] or canonical.database.product.Product? [05:07] all sqlobjects should come from database [05:08] Okay. But I got the impression that database classes should only be used as back-ends by very specific classes. [05:09] Back in London, it was something along the lines of database--mapper--domain--restOfTheWorld [05:10] And I did not find the domain objects again, yet I found some mappers, in the same module which previously contained the SoyuzProduct class used by infoImporter. [05:10] So I'm wondering, what are the Mapper class for? === ddaa greps for ProductMapper [05:11] there were multiple independent implementations of Product [05:11] they should all have been merged to Product now [05:12] canonical.launchpad.database.Product [05:12] if thatdoesn't do what you need, please let me know and I'll find and merge in old code [05:12] from the above code, looks like Product will work perfectly [05:12] from canonical.launchpad.database import Product [05:13] query = Product.... [05:13] etc [05:14] Yeah. But it does not mean the above code was Right, the info importer stuff was one-off code written not to last but to answere a quick need... But that also means it's only needed for testing now, so there is no point in making non-trivial cleanups... [05:14] so, c.l.d.Product it will be. [05:14] Thanks. === limi [~limi@212.80-202-72.nextgentel.com] has joined #launchpad === limi [~limi@212.80-202-72.nextgentel.com] has left #launchpad [] [06:43] Duh... now imported products do not show up in launchpad... === ddaa checks the db [06:45] Mh actually that's the sourcesource for project "unassigned" [06:51] Yeah, the database contains a bunch of sourcesource for the project "unassigned", but none show up in http://localhost:8085/doap/projects/do-not-use-info-imports/unassigned === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === cprov [~cprov@george.kkhotels.co.uk] has joined #launchpad