[00:42] <kb9vqf> wgrant: ping
[01:58]  * kb9vqf found some of the custom upgrade python...sitting in the garbage collector....
[02:24] <wgrant> kb9vqf: You're running an old version of garbo?
[02:25] <wgrant> All the post-2209 bits should *probably* be there, if you can get them to run.
[02:27] <kb9vqf> wgrant: hi there!
[02:27] <kb9vqf> any chance of getting the SQL or should I just plow ahead?  I'm waiting at 2209-40 looking at the garbo code to proceed
[02:28] <kb9vqf> (and yes I pulled an old rev from bzr for 2209-40)
[02:28] <wgrant> Which garbo jobs have you run so far?
[02:29] <wgrant> And what SQL have you run for 2209-00-1 and 2209-01-1?
[02:31] <kb9vqf> wgrant: No garbo yet, you popped on just as I was setting up the run
[02:31] <kb9vqf> Let me grab the SQL I ran...
[02:31] <kb9vqf> (this is all on a test system so I can blow it away and start over if needed)
[02:32] <kb9vqf> UPDATE sourcepackagepublishinghistory set sourcepackagename = (SELECT sourcepackagename FROM sourcepackagerelease WHERE sourcepackagerelease.id = sourcepac$ DELETE FROM sourcepackagepublishinghistory WHERE sourcepackagepublishinghistory.sourcepackagename IS NULL; UPDATE binarypackagepublishinghistory set binarypackagename = (SELECT binarypackagename FROM binarypackagerelease WHERE binarypackagerelease.id = binarypac$ DELETE FR
[02:33] <kb9vqf> Hmm IRC ate that
[02:33] <kb9vqf> let me try again....
[02:33] <kb9vqf> UPDATE sourcepackagepublishinghistory set sourcepackagename = (SELECT sourcepackagename FROM sourcepackagerelease WHERE sourcepackagerelease.id = sourcepackagepublishinghistory.id);
[02:33] <kb9vqf> DELETE FROM sourcepackagepublishinghistory WHERE sourcepackagepublishinghistory.sourcepackagename IS NULL;
[02:33] <kb9vqf> UPDATE binarypackagepublishinghistory set binarypackagename = (SELECT binarypackagename FROM binarypackagerelease WHERE binarypackagerelease.id = binarypackagepublishinghistory.id);
[02:33] <kb9vqf> DELETE FROM binarypackagepublishinghistory WHERE binarypackagepublishinghistory.binarypackagename IS NULL;
[02:34] <kb9vqf> wgrant: ^^
[02:34] <kb9vqf> The database is currently sitting at 2209-40-12
[02:34] <kb9vqf> *2209-40-2
[02:34] <wgrant> kb9vqf: Why are those DELETEs there?
[02:34] <wgrant> Every SPPH has a BPR, so they should never delete anything.
[02:35] <kb9vqf> wgrant: Over time some orphan rows crept in, probably during one of the numerous crashes
[02:35] <wgrant> Oh, no, your query is totally wrong :)
[02:35] <wgrant> UPDATE sourcepackagepublishinghistory set sourcepackagename = (SELECT sourcepackagename FROM sourcepackagerelease  WHERE sourcepackagerelease.id = sourcepackagepublishinghistory.id);
[02:35] <kb9vqf> ok :)
[02:35] <wgrant> SPR.id != SPPH.id
[02:35] <wgrant> The condition should be 'WHERE sourcepackagerelease.id = sourcepackagepublishinghistory.sourcepackagerelease'
[02:35] <wgrant> And similar with BPPH.
[02:36] <kb9vqf> OK, well I did what I could with my limited knowledge of Launchpad :-P
[02:36] <kb9vqf> Looks like I'll be reloading the test DB then
[02:37] <kb9vqf> I can bring it back up to schema 2208 pretty quickly...having the proper SQL to execute would save lots of time ;-)
[02:37] <kb9vqf> that is, time going forward applying 2209-00- etc.
[02:38] <kb9vqf> wgrant: wait a minute, the SQL you posted is identical to mine
[02:39] <kb9vqf> nvm
[02:39] <kb9vqf> I can't read
[02:39] <kb9vqf> :-P
[02:39]  * kb9vqf is juggling two tasks ATM...be back in 10 mins when I can concentrate soeley on this
[02:58] <kb9vqf> wgrant: I got to thinking...I don't need to dump/reload the DB on the test system; I'll worry about fixing up those two columns tomorrow.  How should we proceed on the rest of the migration?
[03:01] <kb9vqf> wgrant: I'm back; if you want to work on this now give me a poke :-)
[03:02] <wgrant> kb9vqf: http://paste.ubuntu.com/8741031/
[03:02] <kb9vqf> Thanks!  That'll save a bunch of time
[03:03] <kb9vqf> wgrant: I notice you set searchable* to empty.  Will this impact the system with regard to the old published packages?
[03:03]  * kb9vqf is not sure what the searchable fields are used for
[03:04] <wgrant> They're used for two things: https://launchpad.net/ubuntu/vivid/+queue (only for the primary and partner archives), and the getPackageUploads API call when using text search terms.
[03:05] <wgrant> Neither of which are likely to affect you.
[03:06] <kb9vqf> Right, OK.  I ask because I had the modified garbage collector ready to run, so if there's any advantage I'll just fire it off during the migration process
[03:06] <wgrant> If you can get it to run, then by all means.
[03:06] <wgrant> You should see no negative effects from either approach for this patch. This is the only one where I took a shortcut, as it was somewhat difficult to implement it properly in pure SQL.
[03:07] <kb9vqf> Yeah I was looking at that and aborted real fast as soon as I saw the python
[03:08] <kb9vqf> I think I can get it to run, so I'll use that approach
[03:08] <kb9vqf> Thanks again; I'll apply these patches and should know sometime tomorrow if it all worked
[03:08] <wgrant> :)
[03:09]  * kb9vqf goes off to redo the sourcepackagename column
=== mpt__ is now known as mpt