[07:31] <noodles775> Hi jtv - do you know if anyone's working on the current buildbot failure? lp/translations/doc/gettext-check-messages.txt
[07:31] <jtv> noodles775: no idea; let me check my irc backlog
[07:32] <jtv> noodles775: nothing in my backlog... was late logging in.
[07:32] <noodles775> jtv: thanks - I can't see a failure email either... do you? If not, I'll check why the email didn't get sent.
[07:33] <jtv> I'm checking my mailbox, but I may already have deleted it if I got it.
[07:33] <jtv> failure on jscheck...
[07:33] <noodles775> yeah, saw that one.
[07:35] <jtv> checking trash now
[07:35] <noodles775> jtv: do you mind doing the testfix? It looks like it was danilos r8643... we need to get it fixed asap in case the other later changes have issues too :/
[07:36] <jtv> noodles775: oh, it's a real test breakage?  Been a while since we saw one of those...
[07:37] <noodles775> yep
[07:37] <jtv> on db-devel?
[07:37] <noodles775> https://lpbuildbot.canonical.com/waterfall
[07:41] <jtv> noodles775: a sucky one, but definitely one in my neck of the woods
[07:41] <noodles775> Thanks jtv!
[07:49] <jtv> noodles775: bug 476218
[07:49] <mup> Bug #476218: Buildbot failure on db-devel: unique violation on POTranslation <Launchpad Translations:In Progress> <https://launchpad.net/bugs/476218>
[07:49] <noodles775> Thanks jtatum
[07:49] <noodles775> jtv (sorry)
[07:50] <jtv> jtatum: if I were you I'd figure out what IRC client(s) these folks are using, and file a bug for over-aggressive nick completion!
[07:53] <jtv> noodles775: bad news.  The unique constraint that's being violated is on the primary key.
[07:53] <noodles775> :/
[07:53] <jtv> In other words, somehow it became possible to create objects with ids that were already taken.
[07:54] <noodles775> Where's stub when you need him ;)
[07:55]  * noodles775 pulls db-devel
[08:02] <noodles775> jtv: running `bin/test -vv -t fix_translation_credits.txt -t gettext-check-messages.txt` gives a different error again.
[08:03] <noodles775> as if these tests are dependent on being run in some order.
[08:03] <jtv> as if they forget to mark the database as dirty maybe?
[08:04] <noodles775> al-maisan: I just noticed this is a branch that you reviewed (not that that implies anything other than you might be familiar with it... do you mind taking a look too? It's very urgent that we get this fixed).
[08:05] <al-maisan> noodles775: where's the branch you are alluding to?
[08:06] <noodles775> al-maisan: r8643 db-devel
[08:06] <noodles775> for bug 474874
[08:06] <mup> Bug #474874: Missing DB permissions in fix_translations_credits script <current-rollout-blocker> <qa-needstesting> <Launchpad Translations:Fix Committed by danilo> <https://launchpad.net/bugs/474874>
[08:06] <al-maisan> ah, OK.
[08:08] <jtv> noodles775: I get exactly the same error when I run that combination
[08:08] <noodles775> jtv: I just realised why though... I assume we should be running make schema (as there is a db schema security change).
[08:09] <jtv> ah, that's what I did, yes
[08:10] <noodles775> yep, my bad.
[08:10] <jtv> I texted stub
[08:10] <noodles775> Thanks.
[08:11] <al-maisan> jtv: this is very funny .. danilo's branch merely changes schema security settings..
[08:11] <jtv> I haven't spotted any recent changes so far that might've caused this
[08:11] <jtv> al-maisan: I don't think there's any particular reason to suspect that branch in particular, apart from the fact that this happens to be rosetta
[08:12] <al-maisan> hmm..
[08:12] <noodles775> jtv: but it's 100% reproducible isn't it? which means it *has* to be that branch... or did I miss something?
[08:12] <jtv> stub has an idea
[08:13] <noodles775> yay
[08:13] <jtv> there was a zcml branch from a community member that he saw a review pass by for few days ago
[08:13] <jtv> sorry, a branch that affects zcml
[08:14] <jtv> ah, he saw a patch fixing a problem like this (which may still not have gone in!)
[08:14] <jtv> the problem seemed to be something along the lines of objects being created twice
[08:14] <wgrant> I did a ZCML-related duplicate primary key thingy.
[08:14] <wgrant> But it only affects "make harness".
[08:14] <jtv> wgrant: that sounds like the one!
[08:14] <noodles775> wgrant! tell us more...
[08:15] <noodles775> wgrant: now it's affecting our test-run...
[08:15] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/fix-duplicate-harness-zcml/+merge/14464 is the one.
[08:15]  * noodles775 gets a patch
[08:15] <noodles775> paste
[08:15] <jtv> may be same cause
[08:15] <wgrant> It's unlikely to be the same.
[08:15] <wgrant> Hmm.
[08:15] <noodles775> wgrant: http://pastebin.ubuntu.com/311315/
[08:16] <noodles775> You can see it with db-devel r8643 by doing:
[08:16] <wgrant> Ew.
[08:16] <noodles775> bin/test -vv -t fix_translation_credits.txt -t gettext-check-messages.txt
[08:16] <wgrant> Hm, it's not in a script, though.
[08:16] <wgrant> What was the diff that killed it?
[08:18]  * wgrant narrowly avoids swap-death.
[08:18] <jtv> wgrant: we don't know... looks like the last build that _succeeded_ was triggered by a branch of yours, on Wednesday around 18:xx UTC
[08:18] <wgrant> OK, pull nearly done.
[08:18] <noodles775> wgrant: it's turned up on a buildbot run of r8643 - diff http://pastebin.ubuntu.com/311319/
[08:19] <jtv> so looks like everything >8640 is suspect
[08:19] <al-maisan> hmm .. running gettext-check-messages.txt alone passes
[08:19] <jtv> I went through all of those though and saw nothing that might cause this.  :-(
[08:19] <noodles775> al-maisan: yep.
[08:19] <noodles775> wgrant: notice that the diff has a new doctest which *does* run a script.
[08:20] <wgrant> Ah.
[08:20] <wgrant> I wondered what gettext-check-messages.txt had to do with anything.
[08:20] <al-maisan> so, something in fix_translation_credits.txt is breaking things, no?
[08:20] <wgrant> Does fix_translation_credits.txt itself fail?
[08:20] <wgrant> Or does it just break tests run after it?
[08:20]  * al-maisan checks
[08:20] <al-maisan> wgrant: no, it does not fail.
[08:21]  * noodles775 applies wgrant's diff.
[08:21] <wgrant> Probably not related, then.
[08:21] <noodles775> oh, that's for harness.
[08:23]  * jtv tries forcing a dirty database
[08:24] <al-maisan> yeah .. it would seem fix_translation_credits.txt only updates existing records
[08:24] <noodles775> but why does running it together with gettext-check-messages.txt cause the exact failure?
[08:25] <jtv> noodles775: probably because something updates the database in a way that our test framework doesn't notice, but without calling force_dirty_database either
[08:25] <jtv> Known, nasty problem.  Thing is, that shouldn't get us into this particular situation.
[08:25] <wgrant> As long as the test runs in DatabaseLayer, it should be reset every time, right?
[08:25] <jtv> Because this particular situation smacks of an id sequence being reset,
[08:26] <jtv> but the objects that have been created not being cleaned up
[08:26] <wgrant> I don't see code in DatabaseLayer that checks if the DB is dirty.
[08:26] <wgrant> Hm, but it does run in DatabaseLayer.
[08:26] <wgrant> Damn.
[08:26] <adeuring> good morning
[08:26] <jtv> hi adeuring
[08:26] <al-maisan> oh, wait, I see `TranslationMessage` instances being created in potmsgset.updateTranslation()
[08:26] <noodles775> hi adeuring
[08:26] <adeuring> hi jtv!
[08:27] <adeuring> hi noodles775!
[08:27] <jtv> al-maisan: yes, that's what it does
[08:27] <jtv> and that in turn will create a POTranslation (unless one for the exact same string already exists)
[08:27] <al-maisan> i.e. this is not an update-only action
[08:28] <jtv> but we should be looking at fix_translation_credits.txt
[08:28] <al-maisan> jtv: does run_script() flush the db after completion?
[08:28] <jtv> It runs a script.
[08:28] <al-maisan> yes
[08:28] <al-maisan> right.
[08:28] <jtv> It flushes the db, but that's not the issue.  The issue is, there's no way for anyone to know that that script just modified the database.
[08:29] <jtv> So what I'm trying right now is to mark that test as dirtying the db
[08:29] <jtv> (I was a bit slow about this earlier because I was also still on the phone with stub :-)
[08:30] <jtv> yup, that fixes it
[08:30] <al-maisan> jtv: hmm .. sounds promising.
[08:30] <wgrant> I don't see other tests that *just* run_script.
[08:30] <al-maisan> Ah.
[08:30] <jtv> wgrant: we may have them here or there... but they should tell the test setup that the db is dirty
[08:30] <jtv> al-maisan: yes, more than just "promising." :)
[08:30] <al-maisan> jtv: :)
[08:31] <noodles775> Thankyou jtv, wgrant and al-maisan!
[08:31] <jtv> and stub
[08:31] <al-maisan> de nada
[08:31]  * noodles775 's blood pressure drops drastically
[08:31] <noodles775> (yes, and stub of course!)
[08:34] <wgrant> When's the reroll?
[08:34] <noodles775> wgrant: tentatively scheduled for 16:00UTC today
[08:36] <wgrant> Ah.
[08:39] <jtv> who wants to review the fix?
[08:39] <jtv> (still working on the mp)
[08:40] <noodles775> I'll r-c it :)
[08:40] <jtv> noodles775: that was my next question—"are you authorised to RC?"
[08:40] <noodles775> adeuring is todays OCR, but it might be quicker for al-maisan given that he's already familiar with the situation?
[08:40] <noodles775> jtv: yep.
[08:41] <jtv> Do I request a "release-critical" review for that?
[08:41] <noodles775> yes please.
[08:42] <jtv> noodles775: requested
[08:42] <jtv> turns out searching for "noodles" gives 3 little pages of results
[08:42] <jtv> none of which seems to be you
[08:43] <jtv> still, if I did that on google it'd probably be a whole lot worse :)
[08:43] <noodles775> yep, I've only started using that as a nick since starting here (although it was a nickname in high school).
[08:44] <wgrant> Why the 775?
[08:45] <noodles775> noodles is already in use, needed a number
[08:45] <wgrant> Ah.
[08:45] <noodles775> (and i was born in 75 which is probably why a 'random' number ended up being 775 ;) ).
[08:48] <jtv> noodles775: maybe run_script (and equivalents, I think we have 2 of that name already) should just force a dirty db?
[08:49] <noodles775> jtv: yeah, might be worth chatting with BjornT about a longer term solution.
[08:49] <jtv> noodles775: I can think of some... I suspect it's mainly a matter of minimizing performance cost
[08:50] <jtv> also, nowadays, postgres doesn't allocate an xid until you've made changes.  So that could be a way to keep track as well.
[08:50] <jtv> Or maybe the existing mechanisms should have been enough to prevent this particular failure, and there's a bug in that somewhere.
[08:51] <jtv> AIUI the id sequences should be reset to whatever is the highest that's still seen in the table, + 1
[08:51] <jtv> in which case this problem _should_ never have happened.
[08:52] <noodles775> yep.
[09:02] <jtv> noodles775: ec2 instance is setting up
[09:04] <noodles775> jtv: um, for a test-fix, I assumed you'd land it directly on db-devel?
[09:04] <noodles775> jtv: in fact, I think time-wise, we have no option but to do so?
[09:04] <jtv> noodles775: ah, of course.
[09:05] <jtv> noodles775: blame the 'flu or my total inexperience with [testfix], your choice
[09:05] <noodles775> yes, please submit to pqm to land on db-devel.
[09:07] <jtv> the [testfix] comes before the [release-critical=], right?
[09:09] <noodles775> Looking at the log, it seems so:  [testfix][release-critical][r=kiko][ui=rs] Reverting the exposure of
[09:09] <noodles775>         Request and rc from kiko. Using testfix as there was a db init
[09:09] <noodles775>   [testfix][release-critical][r=edwin][ui=none] [bug 320889] Fixed a
[09:09] <mup> Bug #320889: Can't retarget a blueprint <Launchpad Blueprints:Fix Released by sinzui> <https://launchpad.net/bugs/320889>
[09:09] <noodles775> woops, sorry for pasting there.
[09:09] <jtv> hmm... got a regex error nonetheless.  :(
[09:09] <jtv> Now to find why "[testfix][release-critical=noodles][r=adeuring][bug=476218] Fix\n\tbuildbot failure: test failed to force dirty db."
[09:09] <jtv> does not match "(?is)^\\s*\\[testfix\\]\\s*\\[(?:release-critical|rs?=[^\\]]+)\\]"
[09:10] <mrevell> Morning
[09:10] <jtv> hi mrevell, had a chance to look at my scribblings?
[09:10] <jtv> (that's his morning ruined in a hurry :-)
[09:11] <mrevell> will do this morning jtv :)
[09:11] <jtv> :)
[09:11] <noodles775> jtv: it looks like that regex (ie. for testfix when in rc) doesn't want the =noodles bit.
[09:11] <noodles775> that would also fit with the examples I pasted above too.
[09:11] <jtv> noodles775: it says =[^\\]+ before the closing brackets though...
[09:11] <jtv> oh, that's for rs only
[09:11] <mrevell> I have to reboot, back in a sec
[09:11] <noodles775> yep.
[09:12]  * jtv resubmits
[09:12] <jtv> ...and PQM accepts!
[09:16] <noodles775> 3-points - thanks jtv!
[10:43] <wgrant> bigjools: Is your bug #476316 not a dupe of bug #475172 which is also probably a dupe of bug #464161 which already has bug #475566 as a dupe?
[10:43] <mup> Bug #476316: Slony-I: Table emailaddress is replicated and cannot be modified on a subscriber node <current-rollout-blocker> <oops> <Soyuz:In Progress by julian-edwards> <https://launchpad.net/bugs/476316>
[10:43] <mup> Bug #475172: EnsurePerson fails for new maintainers during upload processing <Soyuz:Triaged> <https://launchpad.net/bugs/475172>
[10:43] <mup> Bug #464161: authdb Store for scripts connecting to incorrect database <Launchpad Foundations:Confirmed for stub> <https://launchpad.net/bugs/464161>
[10:43] <mup> Bug #475566: Slony-I: Table account is replicated and cannot be modified on a subscriber node <Launchpad Translations:Triaged> <https://launchpad.net/bugs/475566>
[10:45] <bigjools> wgrant: sort of, but I still need a local fix
[10:45] <wgrant> Ah.
[10:46] <bigjools> file first, dupe later I say
[10:59] <deryck> Morning, all.
[12:37] <sidnei> salgado: ping
[12:37] <salgado> hi sidnei
[12:37] <sidnei> salgado: found the problem. thankfully i've been bitten by this before.
[12:38] <sidnei> salgado: take a look at _bindUIPicker in picker.js
[12:38] <salgado> sidnei, yay!  will do in a minute
[12:38] <sidnei> salgado: there's a handler for the focus event that's doing e.halt() if e.target !== this._search_input
[12:39] <sidnei> salgado: i think the order that the handlers get dispatched changed, so that handler, which is for the bounding box gets triggered before the more specific handler for the extra-input
[12:40] <salgado> and that handler is to make the focus go to the search input whenever I click on the bounding box?
[12:41] <sidnei> salgado: apparently yeah. i think it should also check if the target isn't an input or some other control. that should fix your issue.
[12:42] <salgado> sidnei, cool, I'll give that a try.  at least now I know where the problem is. :)
[12:42] <salgado> sidnei, thanks a lot!
[12:42] <sidnei> iirc, all this mess is because firefox gets focus events wrong. there are lots of threads out there about it.
[12:53] <Ursinha> bigjools, oi :)
[12:54] <bigjools> Ursinha: oi
[12:54] <Ursinha> bigjools, there's one oops that only  happens to one team, easily reproducible: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1405K1314
[12:55] <Ursinha> bigjools, but only you may know the cause :)
[12:56] <bigjools> Ursinha: I am looking
[12:57] <bigjools> Ursinha: it's a data inconsistency issue, I've no idea why it would get like that
[12:58] <bigjools> basically the build state says it's building but there's no buildqueue record
[12:58] <bigjools> we need to reset the build state
[12:59] <Ursinha> bigjools, yes, then it shows in the list and when you click, boom
[12:59] <Ursinha> bigjools, resetting it is easy to do?
[12:59] <bigjools> needs LOSA + SQL
[13:00] <Ursinha> right
[13:00] <Ursinha> bigjools, I'll file a bug just to keep track
[13:03] <bigjools> BjornT: can you approve the DB query I just added to LPS please
[13:40] <jtatum> lol jtv :)
[13:44] <ursula> oh, I lost a joke from jtv :/
[13:47] <noodles775> for Ursinha : <jtv> jtatum: if I were you I'd figure out what IRC client(s) these folks are using, and file a bug for over-aggressive nick completion!
[13:47] <Ursinha> lol
[13:47] <Ursinha> thanks noodles775 :)
[13:48] <noodles775> :)
[13:48] <jtatum> don't feel bad, Ursinha, it was ~6 hours ago ;)
[13:48] <Ursinha> jtatum, oh! I thought that it happened in the moment I lost connection here :)
[13:50] <bigjools> Ursinha: we didn't say anything bad about you, honest
[13:50] <Ursinha> bigjools, oh, that I don't mind, kinda used to it
[13:50] <Ursinha> :P
[13:51] <bigjools> surely not :)
[13:53] <jtv> jtatum: so... you still think I'm joking?  Make a note to read it again a few months later.  :-)
[13:57] <jtatum> lol
[13:57] <jtatum> jtv, noted ;)
[14:23] <salgado> barry, when you encountered that different rich-root problem, I assume you fixed it by creating a new repo?  if so, what format did you use for it?  I used pack-0.92 but that doesn't support stacking AFAICT
[14:24] <barry> salgado: i used pack-0.92.  i didn't notice if it stacked or not (i /think/ it did but i'm not positive)
[14:24] <barry> salgado: yes, i created a new repo, and used diff/patch to get the change across.  kinda sucked ;)
[14:25] <salgado> barry, indeed, I've just did that.  I think the first format that supports stacking is 1.6, though
[14:29] <barry> salgado: yeah.  stacking's a lp optimization though.  when the format bug is fixed i'll happily let lp consume less disk space ;)
[14:30] <salgado> barry, well, not just that, if you don't use stacking you'll have to push the whole history every time you push a new branch
[14:30] <barry> salgado: true.  lp-dev-utils is small though and i have a fat pipe
[15:15] <Ursinha> danilos, what's the difference between product and project?
[15:17] <gary_poster> barry: do you know the procedure for adding a dependency to launchpad-dependencies (as in, python2.5-devel :-) )
[15:18] <barry> gary_poster: i don't, but salgado-lunch does
[15:18] <gary_poster> barry: I thought he did, and pinged him elsewhere, but was excited enough to ask you just in case while he is at lunch :-)
[15:19] <gary_poster> thx
[15:19] <barry> gary_poster: ;)
[15:24] <Ursinha> I wish I could ask wgrant, he's a walking grep :)
[15:38] <matsubara> Ursinha, product is a project and project is a project group. those are the old names
[15:40] <Ursinha> danilos, sure :)
[15:40] <Ursinha> matsubara, thanks!
[15:41] <Ursinha> danilos, so, what's the difference between primary_translatable and translation_focus?
[15:42] <danilos> Ursinha, translation_focus is explicitely set (or not) and primary_translatable can be defined even if translation_focus is not set (it's calculated otherwise)
[15:42] <danilos> Ursinha, basically, translation_focus mirrors the DB value, and primary_translatable provides with a good default if translation_focus is not defined
[15:42] <Ursinha> danilos, right, that leads to the second question
[15:42] <Ursinha> danilos, if translation_focus is none, what should it be, development_focus?
[15:43] <danilos> Ursinha, well, what do you think it should be? (a serious question)
[15:43] <Ursinha> errr sorry
[15:43] <Ursinha> hm, no, that's right
[15:43] <Ursinha> danilos, I think it should be the dev focus
[15:43] <danilos> Ursinha, the situation is this: project maintainer has not defined any release as the focus for translations
[15:44] <danilos> Ursinha, and I agree, it makes most sense :)
[15:44] <Ursinha> danilos, and after that, keep the same as it was
[15:44] <danilos> Ursinha, and if that's not defined either, I'd pick the latest series
[15:44] <danilos> Ursinha, well, it should default to development_focus already
[15:45] <danilos> Ursinha, so, the change you are making should be "if there's translation_focus, then that, otherwise keep the same as it was" :)
[15:46] <Ursinha> danilos, that's what I thought was the right thing to do :)
[15:46] <Ursinha> danilos, other question
[15:47] <Ursinha> danilos, what's the secondary_translatable_serieses?
[15:47] <danilos> Ursinha, I don't know
[15:47] <Ursinha> danilos, :)
[15:48] <danilos> Ursinha,         """Return a list of IDistroSeries that aren't the translation_focus.
[15:48] <danilos>         It only includes the ones that are still supported.
[15:48] <Ursinha> danilos, just want to be sure that's what I imagine it to be, a list of translatable series that not the translation focus
[15:49] <Ursinha> danilos, I see the comment, boss :P
[15:49] <danilos> Ursinha, well, it seems pretty clear to me :)
[15:54] <EdwinGrubbs2> deryck: ping
[15:55] <deryck> EdwinGrubbs, pong
[15:56] <EdwinGrubbs> deryck: I just sent you an email that I hope you can respond to now, so that I can land the branch today before I go to the lazr-js sprint.
[15:57] <deryck> EdwinGrubbs, will look now.
[15:58] <deryck> EdwinGrubbs, the design is fine that you sent.  I have no qualms at all. :)  I actually like that better than what I proposed.
[15:59] <EdwinGrubbs> thanks
[16:24] <sinzui> EdwinGrubbs: I sent you a reply to the design
[16:25] <sinzui> EdwinGrubbs: If you don't was to fix the CSS, I'll do it right now to fix bug 465524. I know the problem affects more than the two portlets we are discussin
[16:25] <mup> Bug #465524: ~name Latest Memberships portlet joined date is rendered in the incorrect style <post-3-ui-cleanup> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/465524>
[16:50] <bigjools> Ursinha: attagirl for your reply to danilos :)
[16:51] <Ursinha> bigjools, is that good? :)
[16:51] <bigjools> yes very :)
[17:03] <EdwinGrubbs> sinzui: I'm fixing the registered CSS class not to use italics. Can you look at https://edge.launchpad.net/ubuntu/+mirror/ftp.iinet.net.au-archive ? It seems like the "registered by" info should go in the top right corner even though it is really long on this page.
[17:04] <sinzui> EdwinGrubbs: does that registration info *look* like it is correct? Where should that information be on the page?
[17:05] <EdwinGrubbs> sinzui: I have no idea if it is correct. Normally, we put "registered by" just above the sidebar.
[17:05] <sinzui> EdwinGrubbs: Yes it goes in the registration slot. Official belongs in the Archive information portlet
[17:05] <sinzui> EdwinGrubbs: you should have an idea. Any time you want to know when an object was created and by whom, look to the right under the logout button
[17:06] <sinzui> EdwinGrubbs: You do not need to fix this issue. I'll report and bug and get it fixed. There are several cases of these.
[17:10] <danilos> Ursinha, you'll know who to ask any questions from now on, now that you hurt my feelings ;)
[17:10] <Ursinha> danilos, lol, sorry boss
[17:10] <Ursinha> danilos, you're emacs, gnome guy, but I love you anyway
[17:10]  * Ursinha pets danilos
[17:10] <danilos> Ursinha, :)
[17:10] <Ursinha> :P
[17:19] <Ursinha> danilos, how do I find out the currentseries of a project?
[17:19] <Ursinha> err product
[17:24] <danilos> Ursinha, 'currentseries'?
[17:24] <danilos> Ursinha, do you mean development_focus series? :)
[17:24] <Ursinha> oh, wait
[17:25] <Ursinha> danilos, apparently product.currentseries is related to distros
[17:27] <danilos> Ursinha, I don't see product.currentseries
[17:27] <danilos> Ursinha, I only see distribution.currentseries
[17:28] <Ursinha> danilos, sorry, I see targetseries = ubuntu.currentseries
[17:29] <danilos> Ursinha, right... is there any reason why do you worry about the rest of that method? :)
[17:30] <Ursinha> danilos, no, I'm just trying to understand how it works :)
[17:32] <danilos> Ursinha, well... it's quite simple :) it returns either the development_focus productseries or the latest productseries which has translatable templates; if none of those exist, it returns any linked ubuntu sourcepackage instead, or if there's no ubuntu sourcepackage, any other sourcepackage
[17:33] <danilos> Ursinha, btw, did you get the DB patch reviewed?
[17:34] <Ursinha> danilos, nope :(
[17:34] <Ursinha> guess people are busy this weel
[17:34] <Ursinha> week
[18:00] <mrevell> good weekend all
[18:47] <maxb> abentley: around? I don't understand your assertion that "undecided" repositories would encourage pack-0.92?
[19:11] <mars> flacoste, do you have a forecast as to when we will be dropping r-c?
[19:15] <beuno> mars, how's the yui3ification?
[19:21] <mars> beuno, moving along.  Everything works well, we've only had a few small changes to deal with.
[19:21] <mars> beuno, I just fixed a bug that was preventing the production config from loading.  With that fix we are one big step closer to being able to land the branch.
[19:22] <beuno> mars, that's great news
[19:22] <beuno> and most widgets work with 3.0.0 and the updated lazr-js
[19:22] <mars> beuno, we will at minimum have an integration branch to build off of for the sprint
[19:22] <mars> beuno, most do
[19:23] <beuno> mars, that's awesome, thank you
[19:36] <flacoste> mars: it's already dropped, since ~4h ago
[19:37] <mars> flacoste, ok, thanks
[19:38] <mars> sidnei, ^ it should be ok to start landing lazr-js branches, if you dare tempt the wrath of Friday :)
[19:40] <sidnei> mars: i would prefer waiting until monday :)
[19:40] <mars> hehe
[19:40] <mars> sidnei, ok, we will get everything straightened out monday morning during the sprint opener
[19:41] <beuno> sidnei, could you add the branch URL to the sprint page?
[19:42] <mars> beuno, we'll have to land on trunk.  salgado and I have made a number of fixes on top of sidnei's and Bjorn's work
[19:43] <beuno> mars, can we have the latest there?  it will take a while to get it into trunk, and it would be ideal not to stall on it
[19:43] <mars> beuno, we can.  I can push my integration branch with everyone's changes rolled into it.
[19:44] <beuno> mars, that would rock. Add it to the agenda wiki and we're set!
[21:29]  * wgrant dislikes the new c-i-p UI.
[21:40] <beuno> wgrant, c-i-p?
[21:42] <wgrant> beuno: canonical-identity-provider
[21:42] <beuno> wgrant, the one with the launchpad UI, or the ubuntu UI?
[21:43] <wgrant> beuno: The Ubuntu one doesn't seem to be serving anything yet. Does that UI exist?
[21:43] <wgrant> Maybe that one is less utterly sucky...
[21:43] <wgrant> But I presume not, since 3.1.10 brought some changes to the Launchpad UI.
[21:43] <beuno> wgrant, it's completely different
[21:43] <beuno> and should stop sucking
[21:44] <wgrant> beuno: Will it supplant the Launchpad UI entirely?
[21:45] <beuno> wgrant, it will be a separate instance with the same db
[21:45] <beuno> so it will be used for all ubuntu-related stuff
[21:45] <beuno> at some point, we will either re-work the launchpad one, or replace it with the ubuntu one
[21:46] <wgrant> Ahh.
[21:50] <wgrant> Bug #476963, anyway.
[21:50] <mup> Bug #476963: UI is pretty awful <Canonical SSO provider:New> <https://launchpad.net/bugs/476963>
[21:53] <beuno> :)
[22:26]  * thumper is at kiwipycon
[22:26] <thumper> even has web access :)
[22:28] <wgrant> Not once everyone else gets there.
[22:28]  * wgrant has bad memories of UDS Jaunty.
[22:29] <ajmitch> wgrant: it's not that bad, honest
[22:30] <ajmitch> (yet)
[22:30] <wgrant> Until 128 people get into the hotel, and the DHCP range fills up.
[22:30] <ajmitch> we're not all at a hotel, thankfully
[22:31] <mwhudson> yes, hotels insisting on doing the networking are the bane of conferences
[22:41] <EdwinGrubbs> sinzui: so, do you just want me to move the milestone badge to be first, since it is the most often present?
[22:42] <sinzui> EdwinGrubbs: I expect it to have the same order as this: https://edge.launchpad.net/launchpad-registry/+milestone/3.1.11
[22:42] <EdwinGrubbs> sinzui: I'm also wondering if I should implement beuno's 0.5em padding on the <tr> or on the .registered stylesheet.
[22:43] <sinzui> EdwinGrubbs: I think right-aligned is all that is needed.
[22:44] <sinzui> EdwinGrubbs: I need to find my children. I'll be back in a bit.
[22:44] <EdwinGrubbs> sinzui: huh, beuno asked for 0.5em padding below each item.
[23:44] <maxb> I want to use bazaar to track source packages with modifications in the launchpad ppa. Would it make sense to register a launchpad-ppa project?
[23:46] <wgrant> maxb: People use distro branches for that.
[23:46] <maxb> for packages in a ppa?
[23:46] <wgrant> Yes.
[23:46] <wgrant> Not exactly semantically correct.
[23:46] <maxb> hmm
[23:46] <wgrant> But probably better than a project.
[23:47] <wgrant> After all, they are (in most cases) branches of an Ubuntu package.
[23:47] <maxb> lp:~maxb/ubuntu/karmic/python-defaults/launchpad-ppa ?
[23:47] <wgrant> Right.
[23:55] <maxb> mm, neat
[23:56] <wgrant> Hm?
[23:57] <maxb> oh, I'm just sitting here grinning that having twigged that package branches are the right way to do it, I can just push and all is happy :-)
[23:57] <wgrant> Yup.
[23:58] <wgrant> I'm not sure if you can manually stack on LP without playing with bzrlib.
[23:58]  * wgrant tries.