[00:00] mwhudson: Haha [00:06] StevenK: Ah, yes, you'll need the cast [00:08] wgrant: Yeah, it's working [00:08] Turns out my guess was right [00:08] mwhudson: This isn't particularly great [00:08] evil [00:08] I've done much worse :) [00:08] i'm sure [00:08] wgrant: did i show you http://voices.canonical.com/michael.hudson/2012/09/02/using-postgres-array_agg-from-django/ ? [00:09] I might need popcorn [00:10] Hah [00:10] So not too hacky [00:10] the bit with decimalfield was pretty awful [00:10] but otherwise, no [00:10] Yeah [00:11] aggregate.field = DecimalField() # vomit [00:11] Haha [02:01] how did lp upgrade from postgres 8 to 9? [02:01] can you slony between 8 and 9? [02:01] We dropped slony too [02:02] yes [02:02] but that was afterwards :-) [02:02] During, in fact [02:02] mwhudson: That's like saying Ubuntu 10 and Ubuntu 11 :) [02:02] hm [02:02] wgrant: heh well [02:02] We upgraded 8.4 to 9.1 with Slony [02:02] Then dropped slony for our internal replication [02:02] We will use slony again for the 9.1 -> 9.2 upgrade [02:03] Then drop it immediately afterwards [02:03] so you had a pg 8.4 master talking to a 9.1 slave, then rotated the 9.1 slave to be the master? [02:03] Right [02:03] ok [02:03] * mwhudson finally read http://www.postgresql.org/docs/9.1/static/pgupgrade.html properly and didn't like it much [02:03] If your system can go down for a while, it's better to just pg_upgrade during a bit of downtime [02:03] heh [02:03] I recall the master pivot being a little messy, but we worked out the issues with it and the second pivot back was cleaner [02:03] IIRC we pg_upgraded the slaves [02:04] StevenK: That was with native replication around the move -- unrelated. [02:04] mwhudson: So, if you can tolerate downtime and your DB is small then just pg_upgrade [02:04] And be done :) [02:04] i guess i should figure out how pg_upgrade works properly [02:04] wgrant: yeah [02:05] There are occasionally caveats, but it's usually the best way [02:06] If the 9.2 pg_upgrade is fast enough we might even just go RO for a couple of minutes and avoid slony entirely [02:06] i'm a little confused about clusters i guess [02:07] wgrant: With pivoting or without? [02:07] will pg_upgrade try to destroy my existing 9.1/main cluster? [02:08] mwhudson: It has two modes: copy and hardlink [02:08] The latter will destroy the original cluster [02:08] Copy will create a copy, which is probably OK unless your DB is LP-sized [02:09] wgrant: sure, i get that bit [02:09] wgrant: where will it put the copy though? [02:09] or do i get to decide that? [02:09] the db is small enough that i download copies of it for development ... [02:09] IIRC you specify the source and target paths [02:10] It doesn't manage the clusters itself [02:10] Yeah [02:10] ah yeah [02:10] You create the new cluster and then use pg_upgrade to replace its data [02:10] mwhudson: I have dreams about database's that small [02:12] argh [02:12] pg_upgrade is packaged as part of postgres-xc apparently [02:13] but postgres-xc appears to install its own version of everything [02:13] mwhudson@narsil:non-default-database$ sudo -u postgres initdb -D /var/lib/postgresql/9.1/upgrade [02:13] initdb: Postgres-XC node name is mandatory [02:13] pg_upgradecluster ? [02:13] mwhudson: /usr/lib/postgresql/9.1/bin/pg_upgrade [02:13] pg_upgradecluster is a Debian wrapper in PATH [02:13] /usr/lib/postgresql/9.1/bin/pg_upgrade is the real binary [02:14] ahh [02:16] oh ffs [02:17] now postgres-xc's maintainer scripts are failing and not letting me do anything [02:17] Hee hee [02:17] mwhudson: you're running clustered ? [02:17] mwhudson: sudo vi and 'exit 0' ? [02:17] * mwhudson should probably not have been allowed sudo today [02:17] StevenK: that's what i'm thinking [02:17] Hahaha [02:21] well this was a little adventure i wasn't in the mood for [02:23] mwhudson: how well does postgres-xc work? [02:23] lifeless: installing it appears to mess everything up completely [02:24] and haha of course postgres-8.4 isn't installable in quantal ;-) [02:24] mwhudson: lxc ftw [02:24] yeah [02:36] There were problems executing "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l "/dev/null" -D "/var/lib/postgresql/8.4/main" stop >> "/dev/null" 2>&1 [02:36] Failure, exiting [02:36] :( [02:37] :( [02:38] particularly nice to pipe any error messages away [02:42] oh [02:42] spethial [02:42] turns out -l fixes the errors go away problem [02:43] now i think it's that ubuntu puts the config not in the cluster but rather in /etc [04:46] wgrant: https://code.launchpad.net/~stevenk/launchpad/populate-searchables-for-pu/+merge/138906 is ready for another look [04:57] wgrant: And https://code.launchpad.net/~stevenk/launchpad/squash-archivesubscriptionerror/+merge/139382 [05:01] StevenK: What does set_archive_and_user do that can't be achieved by setting archive and user? [05:01] wgrant: I can't set self.user directly [05:02] You don't set self.user at all, because that's the request user [05:02] But can't you set self.current_user directly? [05:02] The helper seems pointless [05:02] Also, I'd perhaps say context_user [05:02] wgrant: If I try and set self.user = ... in the view, I get horrible errors [05:03] Sure [05:03] self.user is special [05:03] You shouldn't be setting it [05:03] Also, self.archive is a bit odd, as it's reasonable for some other view to use that name [05:03] Perhaps sources_list_archive and sources_list_user? [05:04] Also, on line 101 of that diff you use the request user's displayname, but the context user's name [05:04] Oh, hah, I missed one [05:07] wgrant: http://pastebin.ubuntu.com/1426820/ [05:08] context_archive and context_user are still sort of overly generic for a very specific widget [05:09] You suck, and I hate you. [05:09] Oh, it already used self.archive? [05:09] current_user needs to change, but if it's already using self.archive then it's probably safest not to change that [05:10] Because current_user is precisely not the current user :) [05:12] wgrant: http://pastebin.ubuntu.com/1426826/ [05:13] Much clearer :) [05:14] And less buggy, too boot [05:23] StevenK: I still don't see any value in set_archive_and_user over setting the archive and user [05:23] And the Nones might as well be defined in the class definition, rather than __init__ [05:23] Oh, I can do that in the views if you wish [05:25] wgrant: http://pastebin.ubuntu.com/1426839/ [05:25] Sorry, I didn't realise you were still pushing back [05:26] Great [05:30] what is he, a plane? [05:31] wgrant: Diff updated [06:11] wgrant: I wonder if we can forbid import cgi in the fascist [06:12] cgi.parse_qs and friends are still useful [06:12] And there's only one callsite of cgi.escape left in the entire tree [06:12] So there's no bad examples left for anybody to copy [06:12] \o/ [06:12] So I doubt any more will sneak in === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: ~150 [06:58] wgrant: You fail at buildbot bingo again. [07:00] wgrant: I thought sets were sorted? [07:01] wgrant: And there is no normal add mechanism for PCJ'd PU's. [07:01] StevenK: sets aren't sorted [07:01] StevenK: That function isn't just used for PCJs [07:02] It's used to create all PUs [07:02] >>> set(['b']) | set (['a']) [07:02] set(['a', 'b']) [07:04] >>> set(['c', 'd', 'b']) | set (['a']) [07:04] set(['a', 'c', 'b', 'd']) [07:04] Even [07:05] wgrant: Right, but there isn't a addPCJ method on PU [07:05] Either we have one, or we don't. [07:06] I can call setSearchable* in the constructor if package_copy_job [07:06] StevenK: Oh, I meant that you should call addSearchable*, yes [07:06] Not addPCJ [07:07] wgrant: In PU's constructor? [07:07] >>> list(set(['foo', 'bar', 'baz'])) [07:07] ['baz', 'foo', 'bar'] [07:07] Yes [07:07] Hmmm [07:07] I will add sorted() [07:07] sets are by definition unordered [07:07] they have a sort order. Its the internal datastructure iteration order [07:07] which is effectively random [07:08] wgrant: appendSearchable*? Since that's what it does. [07:08] Sure [07:08] in that you can't depend on it, in any regard [07:08] But it's undefined [07:08] So they're unordered :) [07:08] StevenK: It doesn't strictly append, but the order doesn't matter. So I'd say add [07:09] cjwatson: Do you want to retract https://code.launchpad.net/~cjwatson/launchpad/queue-filter-source/+merge/119225 now that we have a less disastrously unperformant solution? [07:09] wgrant: PackageUpload has no __init__ [07:10] And I don't want to step on SQLBase's toes [07:10] There's no __init__, no [07:10] But there is a factory method somewhere [07:11] That you edited in that branch already [07:11] That doesn't help code that creates PCJs [07:11] I am confused [07:12] What doesn't work for what and why? [07:12] wgrant: A PCJ may not require a PU. If it does, it calls createQueueEntry(). The factory methods for creating a PCJ don't touch that bit of the code, they have the job system do it [07:13] And I'm not sure how I can call addSearchables* if there is no __init__, and no add{Source,Build,Custom} variant. [07:15] Why not? [07:15] The method on DistroSeries creates the PackageUpload and returns it [07:15] It can, between creating and returning it, call addSearchable* [07:15] Oooh [07:15] Or the __init__ could, if you want to define an __init__ [07:15] (it's not uncommon to define an __init__ that just passes through the args and kwargs to super, then performs some operations afterwards) [07:18] wgrant: http://pastebin.ubuntu.com/1426974/ [07:19] StevenK: And now you can add a comment to __init__ about how they get added for other cases :) [07:19] Also, consider how this is going to work when the two columns are NOT NULL [07:19] They can not be. [07:19] You'll need to have a sensible default, and you might as well arrange that now [07:19] Why not? [07:19] They have logical defaults: '' and [] [07:20] Ah [07:22] wgrant: http://pastebin.ubuntu.com/1426981/ [07:27] That's wgrant Compliant™ [08:01] wgrant: in other wtf news, pg_upgradecluster appears to use pg_dump/pg_restore under the hood, not pg_upgrade [08:02] * mwhudson fumes [08:04] ah [08:04] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682938 === tasdomas is now known as domas === domas is now known as domasm === domasm is now known as tasdomas === buildslayer is now known as shadeslayer [11:20] wgrant: Sure, retracted now [11:21] and reassigned the bug to StevenK [11:34] Just need to wait for my DB patch. And fix my test failures. And then wait for the garbo job to populate on all four instances ... [11:35] And then two more DB patches. :-( [11:35] is that all :) [11:45] czajkowski: Nope. Then I have to land the branch that makes uses of the new columns. === matsubara-afk is now known as matsubara === matsubara is now known as matsubara-lunch === slank_away is now known as slank === slank is now known as slank_away === slank_away is now known as slank === Ursinha-afk is now known as Ursinha === matsubara-lunch is now known as matsubara === almaisan-away is now known as al-maisan === gary_poster is now known as gary_poster|away === gary_poster|away is now known as gary_poster === al-maisan is now known as almaisan-away === deryck is now known as deryck[lunch] === broder_ is now known as broder === deryck[lunch] is now known as deryck === yofel_ is now known as yofel [19:33] ha. keyboard navigation is broken in the bugs subscriptions widget because it stomps on the content of it's overlay widget. [19:33] Now the question is, can I fix this without spending a 2 days remaking it as a true widget. [19:37] * rick_h_ sends sinzui lots of luck [19:38] This module is a crime [19:38] yea, my general rule in JS stuff is rewrite first ask questions later === lifeless_ is now known as lifeless [21:36] Is there a way to correlate a build with package_upload? I'm trying to see if I can calculate various wait time statistics between upload and build for our ppas [22:05] A PackageUpload may link to a build, a source or a custom upload. I'm not certain if the property is exported. [22:30] StevenK, can you triage this: https://bugs.launchpad.net/launchpad/+bug/1089615 [22:30] <_mup_> Bug #1089615: Source builds fail for packages with "3.0 (quilt)" format and unapplied patches < https://launchpad.net/bugs/1089615 >