[00:29] just saw that steve jobs has died [00:29] * StevenK adds 1 to his internal number of channels that have mentioned it. [01:37] lifeless: did skype drop out or is it just me? [01:38] wgrant: Can haz another look at my MP? [01:46] thumper: ping! [01:46] wgrant: sinzui: did skype hiccup ? [01:49] Oh :( [01:49] So yeah, I think we know what we're doing. [01:49] Almost. [01:50] Multipillar bugs with disclosure views are still a bit of an issue. [01:50] But I think we have better ideas now. [01:50] Email probably works. [01:50] I need to experiment with how they interact with policies. [01:50] They may make it easier. [01:50] wgrant, yes. they do need more work, but I feel we have a path to solve the issue [01:50] I am tempted to go with policies now and then see how multipillar bugs fall out. [01:51] wgrant, I was thinking of adding a report task to the kanban. How many pillars share private bugs? [01:51] sinzui: I was running reports on Tuesday to work that out. [01:51] sinzui: Using all historical data, too. [01:52] sinzui: (any bug that is private now, or has ever had the visibility changed) [01:52] sinzui: I didn't end up finishing them, but I can finish the queries if you do want to know this. [01:52] oh, I had not considered that [01:52] I think we should know this because I am certain someone will ask us [01:54] sinzui: It is relevant because many security bugs end up public. [01:56] sinzui, lifeless: I have a set of scripts to populate an empty DB. [01:56] With celebrities. [01:56] And an initial user. [01:57] oh sweet [01:57] And then another one to create Ubuntu and set it up for Soyuz. [01:57] I wrote them around two years ago, but updated them a few months ago. [01:57] https://code.launchpad.net/~wgrant/launchpad/bootstrap-db-from-scratch\ [01:58] mailing lists require a script since it is not 100% in the db [01:59] http://bazaar.launchpad.net/~wgrant/launchpad/bootstrap-db-from-scratch/revision/10987 is the guts of it. [01:59] karma and celebrities are the ugly bits. [01:59] No. [02:00] That would be nice, but slow and require lots of test fixes. [02:00] right. [02:01] These create a minimal DB that you can use a harness on to create more stuff. [02:04] wallyworld_, lifeless, StevenK: eg. I have my base bootstrap-lp-db script which just creates minimal celebrities and a user for the caller, then make-ubuntu-sane to create sensible Ubuntu series. I imagine there would be lots of scripts like make-ubuntu-sane. [02:06] We use make initscript-start on production. [02:06] Not make run. [02:12] *Especially* using the factory. [02:18] wgrant: Can haz review? [02:51] wgrant: bootstrap-lp-db was what lifeless was talking about it, which sounds like a good idea to me. [02:51] Not quite what lifeless was talking about. [02:51] I believe lifeless was talking about a script to generate something like the current sampledata. [02:51] With bugs and projects. [02:51] But not with SQL. [02:52] yes [02:53] wgrant: I was hoping my refactoring could remove more lines than it added, but alas. [02:57] wallyworld_: pong [02:58] thumper: that utf-8 branch has a test failure on ec2 but not locally and my encoding foo is not that great https://pastebin.canonical.com/53926/ [02:58] * thumper looks [02:59] thumper: i'll paste the code snippet [02:59] thumper: https://pastebin.canonical.com/53927/ [03:00] and it works locally? [03:00] the string 'hello \xce\xa3' is the correct non-unicode representation of the unicode string [03:00] yes [03:01] in the debugger, both the unicode and non-unicode versions appear correctly as hello (sigma) [03:01] so i know the strings are correct [03:01] damn [03:01] * thumper has no idea [03:01] * wallyworld_ also has no idea [03:02] wallyworld_: ask someone who uses utf-8 more, like jtv or jelmer :) [03:02] will do [03:16] lifeless: http://paste.ubuntu.com/634326/ [03:23] * StevenK prods wgrant about his MP so he can land it [03:25] StevenK: Much better, thanks. [03:26] Hrm, no stub yet :( [03:26] stub has been awake for hours. [03:26] wgrant: Thanks! Tossing it at ec2. [03:27] StevenK: I managed to screw up my MP enough that I had to redo it :D [03:27] So, now I need approval again :( [03:28] nigelb: Been there, done that. [03:28] StevenK: That's comforting :) [03:35] nigelb: Where is the mp? [03:38] stub: Nevermind. I just noticed you approved it. [03:39] I must've lost the email :( [03:42] lifeless: ohai, I see that you're OCR today, could you land something for me? :) [03:42] nigelb: maybe; I'm EODish [03:43] Point me at it [03:46] lifeless: ah [03:46] StevenK: https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/78220 [03:46] lifeless: It Thu that you start really early and end early? [03:56] nigelb: Is there a bug for that work? [03:57] StevenK: ah, right. Let me link. [03:57] It's just a db patch, so it doesn't matter much [03:57] StevenK: (In case it isn't apparent 5283) [03:58] oh no. Someone removed that feature [03:58] Not quite. [03:58] when linking a bug it would suggest the number that's in the branch name [03:58] It only works with numbers of 5 or more digits. [03:58] bah! [03:58] To minimise false-positives. [03:58] lol [03:58] StevenK: linked :) [03:59] I'm going to change the dev wiki db patch page to say the right year. [04:02] nigelb: lp-landed to db-devel [04:03] r11051 of db-devel [04:03] StevenK: that was fast. [04:03] You didn't need a test run? [04:04] It's a DB patch! [04:04] heh [04:04] What could possibly go wrong, etc, etc [04:04] Famous last words etc [04:12] StevenK: i had a db-patch fail last week. it got picked up by ec2 luckily. it was a combination of not null column and a trigger processing issue. so it depends on the nature of the change whether it should go through ec2 [04:14] wallyworld_: Its a new column, probably less risk :) [04:14] nigelb: understood. i was just making a point about db patches sometimes needing ec2 :-) [04:15] nigelb: earlier , not really early atm [04:15] nigelb: but ye [04:15] s [04:16] wallyworld_: everything gets ec2 by default :) [04:16] lifeless: yes. i was trying to be gentle :-) [04:16] with my assertion that ec2 be used [04:23] wgrant: So, are you happy enough for populate-bprc to land, and if it starts being crap, we change the query? [04:28] StevenK: I'd prefer if we knew it wasn't crap, and that it was the way we wanted to go. [04:29] wgrant: My timing of the query was 'acceptable', TBH [04:29] And it didn't kill DF [04:36] wgrant: So given the two choices of "It will make me sad" or "I won't abide, and will revert it." is it? :-) [04:39] StevenK: Well, we need to decide whether we want it in our main DB right now. [04:39] And whether the query doesn't suck. [04:40] I thought we had these arguments already? [04:45] 51 polls have been created this year. I am disappoint. [04:46] StevenK: land [04:46] StevenK: Kill it :D [04:46] lifeless: land populate-bprc? [05:27] StevenK: :( [05:27] buildbot failed. [05:30] * StevenK waits for SSO [05:34] Huh, weird. [05:34] lifeless: land populate-bprc?6170 tests [05:34] 1334 passed [05:34] 76 failures [05:34] * StevenK waits for SSO[B[B [05:34] * StevenK glares at his mouse [05:34] * wgrant glares at StevenK. [05:35] Ah, I see the buildbot failure is noticed already. [05:35] * wgrant waits for SSO. [05:35] Heh, you broke all the triggers. [05:35] Ah. Shall I revert? [05:37] Yes. [05:37] And ec2 things in future... [05:37] Doing so. [05:42] What'd I break? [05:42] All of the triggers. [05:42] Ugh. [05:42] How? [05:42] Or rather, how do I fix. [05:43] wgrant: Reversion tossed at PQM. [05:45] * StevenK breaks PQM into tiny pieces and resubmits [05:46] nigelb: The lp_person table and the lp_mirror_person_* triggers in trusted.sql. You need to replace them in a patch, like you did with bugtask.statusexplanation's FTI trigger. [05:46] Wow. [05:46] They depend on column order. [05:46] stub: Make them go away :( [05:46] Haha [05:46] lp_person and lp_mirror_person_* are parasites. [05:47] Actually. [05:47] We rerun trusted.sql each time. [05:47] So you can probably just edit the functions in-place. [05:47] wgrant: Revert is r11053 [05:48] wgrant: It has CREATE OR REPLACE TRIGGER? [05:48] yes, they can be edited in place. But we can't alter the lp_* table definitions. [05:48] They will go away when ISD obtains that information through other channels, or decides it isn't needed at all. [05:50] But they've got no motivation to fix this :/ [05:50] nigelb: How is your PL/pgSQL? I might need to take over that patch. [05:50] They do, as their schema updates are a pain in the arse because their databases are tied into ours. [05:54] stub: I suck :) [05:55] stub: I'm glad to defer to you :) [05:55] Hrm, awkward timing for that quit. [05:55] :P [05:56] wgrant / StevenK - I seem to be opening quite a can of worms lately :) [05:56] bouncy bouncy [05:57] stub: In case you missed that, please take over :) [05:57] nigelb: ok [07:08] stub: hey, can you let me know once its done, so I can work on the follow up branches? :) === almaisan-away is now known as al-maisan === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 262 - 0:[#######=]:256 === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 262 - 0:[########BOOM [07:53] whats the status of lazr-js ? [07:56] Merged into LP and abandoned. [07:56] But I think launchpad-results still uses a tiny bit of it. [07:58] wondering whether to mass close its bugs [07:58] or move them to lp [07:58] or ... [07:58] Ignore them forever :) [07:59] jelmer: bug 515918 - do we close it ? [07:59] <_mup_> Bug #515918: package_name and suite not passed to dailydeb < https://launchpad.net/bugs/515918 > [07:59] wgrant: I think those numbers are lying. [08:00] nigelb: Which? [08:00] wgrant: /topic [08:00] Mainly because it doesn't account for the fact that new bugs are opened and old ones are closed. [08:01] Well, it depends what you want to measure. [08:01] nigelb: its not reporting rate [08:01] lifeless: shouldn't it? [08:02] Or should it be a fraction with closed numbers as well to give a comparison. [08:02] Now it looks like nothing's happening :P [08:02] nigelb: its not, and never has been, a fraction [08:02] nigelb: perhaps I'm missing your point [08:03] Hm, only 57 launchpad-project criticals from before this year. [08:03] lifeless: Well, wht I'm trying to say is, well, it looks like work isn't being done. Which is wrong. [08:03] Work is being done, but progress is not being made. [08:03] The intention is to drive the critical queue to 0. [08:03] That's what that graph measures. [08:04] Ok, that explains it :) [08:04] (it was ~250 when it started) [08:04] Actually, started at 210. [08:05] I should agree to take a pie to the face at spring UDS. [08:05] Seeing the pace at which its going I may never have to :D [08:06] Yep :) [08:06] Also, Launchpadders aren't really at UDS any more, so there'll hardly be anyone to pie you :P [08:06] I thought there's always a small representation? [08:06] Anyway, there's ex-launchpadders in plenty. [08:07] I'm sure joey or kiko or jml would be happy to have the pleasure :P [08:08] wgrant: that's great (the only 57) [08:08] wgrant: although, huh, we're good at adding critical bugs, it seems [08:09] jml: I thought it would be well over 100. [08:09] But apparently not. [08:09] jml: Note that lots are old bugs, like timeouts that only appeared as we dropped the timeout. [08:10] There are 81 timeout bugs, and I would be surprised if even 10 of them were actually new bugs. [08:11] ahh right. [08:11] what's the problem with those? are they unusually hard to fix? [08:11] But I believe flacoste is currently analysing this sort of thing. [08:11] No. [08:12] I think the maintenance squads are suffering from a combination of taking too many big tasks at once, and possibly having too many people leaving :) [08:12] leaving? === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugs: 262 - 0:[########BOOM [08:15] jml: wgrant: the remaining old timeouts are hard to fix [08:15] we nabbed most of the low hanging fruit already [08:16] lifeless: Some of them are, yes. But lots are not. [08:59] wgrant: can you parse bug 397165 for me [08:59] <_mup_> Bug #397165: Upload queue changes should be more restricted

< https://launchpad.net/bugs/397165 > [09:06] lifeless: The web UI is pretty good (I think everything matches what's there, except possibly that Rejected->Accepted might not be exposed), but the internal API and command-line tools allow many transitions that should not be permitted. [09:12] bug 405805 might qualify as critical even [09:12] <_mup_> Bug #405805: Upload processing may reach a transaction deadlock when closing bugs

< https://launchpad.net/bugs/405805 > [09:14] lifeless: The upload processor doesn't really do transactions. [09:15] For example, it's the reason "zopeless" mail isn't queued until the end of the transaction. [09:26] * StevenK tries to figure out the xx-ppa-workflow.txt error [09:30] I think the test is amusing the buggy case of team renaming. [09:49] Does a branch rolling back a rollback get a rollback= stanza in the commit message? [09:50] no [09:50] the rollback stanza is for the qa tagger [09:50] to tell it that it fixes the bad-revision-xxxx [09:51] so the range of revisions that can't be deployed is known [09:55] We really need to fix the branch scanner. [09:56] Needs to be faster, probably needs to do partial progressive scans of fresh branches (like we do with codeimports), and needs to destroy branchrevision :( [10:13] wgrant: progressive scans would be a good start [10:14] It can fortunately be done manually, but it's awkward and slow. === al-maisan is now known as almaisan-away [11:35] jelmer: are you free to help me with a unicode/utf-8 problem? [11:36] wallyworld_: hi [11:36] wallyworld_: sure, what's up? [11:37] hi. i'm not an expert sadly [11:37] here's the issue - i have changed mp and branch emails to utf-8 encode the diff [11:37] a test fails on ec2 but passes locally [11:37] i'll pastebin the test, just a sec [11:38] the test: https://pastebin.canonical.com/53927/, the failure: https://pastebin.canonical.com/53926/ [11:38] i'm not sure why is passes locally and fails on ec2 [11:39] the strings are correct - in my debugger, both the unicode and utf-8 versions are correctly represented [11:40] wallyworld_: have you tried running locally with LC_ALL=C ? [11:40] jelmer: what does that option do? [11:43] wallyworld_: It's an environment variable [11:43] sure :-) what does it affect? [11:44] wallyworld_: It's the variable with the current language and encoding [11:45] ok. and i assume that's what ec2 uses? [11:45] wallyworld_: it influences, among other things, how bzr will encode things for the terminal [11:45] the environment we run under ec2 i mean [11:45] ok [11:45] wallyworld_: We've seen some issues related to this when bzr is run with LC_ALL=C (ascii only) versus LC_ALL=en_AU.UTF-8 (UTF-8) [11:46] ok. i'm trying it now [11:51] jelmer: it still passes locally [11:52] wallyworld_: the odd thing appears to be that you specify decode=True (which I assume means "return unicode") but you're getting back a plain string [11:53] jelmer: decode=True tells the Python email library to reverse any encoding used when the message was constructed [11:53] yes, wonder why a plain string is returned [11:54] i'll have to dig around the email libs a bit i guess [11:55] jelmer: btw, i only modified that test. the test used to only use non-unicode strings and i added the u'hello ...' to test the utf-8 encoding [11:56] thanks for the help btw [12:00] wallyworld_: Sorry, still digging.. [12:01] oh ok. thanks!. i've fired up the debugger and am looking to see if i missed anything [12:01] wallyworld_: do you understand what the :3 comes from? [12:02] I mean, not that the result is different, but why does it come up with ":3" ? [12:02] jelmer: the unicode string i used is u'hello (sigma)' where (sigma) is the greek letter [12:02] i guess that's what the decoded string comes out as on ec2 [12:03] but why would sigma become :3 ? [12:03] i wish i knew [12:03] It would be more understandable if it replaced it with \uffff or something [12:03] yeah. locally, both strings print as the correct thing [12:04] by "print", the debugger does a str() on them any they display correctly === almaisan-away is now known as al-maisan [12:15] anyone want to comment on the thoughts I posted in bug 572128? [12:15] <_mup_> Bug #572128: Ubuntu Archive translations are missing Index metadata file < https://launchpad.net/bugs/572128 > [12:18] jelmer, wallyworld_: locale stuff can also support transcription to ASCII, though you usually have to explicitely ask for it [12:19] danilos: i can't correlate what's happening here though. why would it pass locally and fail on ec2? [12:19] though, this doesn't sound like a reasonable transcription [12:20] wallyworld_, I would attribute it to ec2 developing feelings towards you (iow, sounds weird, yes :)) [12:20] i have a unicode string u'hello Σ' which is converted to utf-8, encoded as quoted-principal, decoded, and compared [12:20] all the encoding etc happens in the python email libs [12:21] i'm at a loss [12:21] danilos: i have feelings for ec2 as well but it's not love [12:21] heh [12:22] wallyworld_, judging from how it's working out for you, I'd say it's mutual :P anyway, I did see some differences between python on ec2 image and recent releases; have you had someone try it out locally on lucid as well? [12:23] danilos: ah no. but that's a good idea, thanks. something environmental sounds like a reasonable culprit. and if it is, i wonder how to solve it [12:24] wallyworld_, "unset LANG LC_ALL" locally? [12:24] i guess get it to fail first and go from there :-) [12:24] danilos: jelmer suggested LC_ALL=C which i tried [12:25] i'll try unset [12:25] wallyworld_, check with "locale" what the resulting settings are (sometimes LANG can override stuff on GNU systems) [12:25] LANG never overrides LC_ALL with GNU software [12:25] some crappy non-GNU software gets it wrong though :) [12:26] I can never remember the order [12:26] LANG=en_AU.UTF-8 for me [12:26] LC_ALL LANG LANGUAGE ? [12:26] cjwatson, ah, ok, so how about LANGUAGE? I know there's a specific GNU extension [12:26] LANGUAGE > LC_ALL > LC_* > LANG [12:26] although only for the purposes of message categories; for all other locale categories, LC_ALL > LC_* > LANG [12:27] with all those unset, it still works locally [12:27] wallyworld_, just trying out your test gives me https://pastebin.canonical.com/53948/, but I guess that's a bug you are fixing :) [12:27] * wallyworld_ cries [12:27] perhaps EC2 has a non-existent locale set in its environment or something [12:28] could be, i'll have to look at how our images are generated [12:28] ec2test calls os.environ.pop() on LANG, LC_ALL and LC_TIME [12:28] StevenK: danilos suggested it may be a lucid thing [12:29] * wallyworld_ needs to reinstall lxc again === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap), jcsackett | Critical bugs: 262 - 0:[########BOOM [13:01] Morning, all. [13:01] Hi jcsackett! [13:01] Morning deryck. [13:02] morning rbva. :-) [13:02] er, rvba. :-P === al-maisan is now known as almaisan-away [13:53] sinzui: we're good to land the branch that kills the privacy banner feature flag now, right? [13:53] yes [13:53] excellent. [13:54] out it goes. [14:15] gary_poster, benji: (not urgent) can one of you have a look at https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 [14:16] flacoste: I will momentarily. [14:16] thanks benji [14:16] np [14:16] jcsackett I am finished with my regular morning calls, and can talk when you are ready. [14:17] no rush [14:17] gary_poster: awesome. i am actually free now, if you like. potentially this will be a short conversation. :-P [14:17] mumble work for you? [14:17] heh ok cool jcsackett. skype usually works better, but I can do the mumble thing. 1 sec and I'll get on [14:39] mrevell, btw, any idea how did this break: bug 826634? [14:43] bug 826634 [14:43] Come on robot, give me a link [14:44] danilos, Crumbs. I've no idea [14:46] mrevell: amazing that nobody asked for wikis on your survey [14:46] mrevell, oh, so the help files are on translations.launchpad.net and the links point to launchpad.net [14:50] danilos, Oh, strange [14:51] bigjools, Yeah, well, it was only a handful of people replied. I bet if we asked more people then wikis would come up. [14:53] is there a way to stop /var/tmp/archive/ from being cleaned up after failing archivepublisher tests? [14:55] cjwatson: post-mortem debug [14:55] as in pdb? ok [14:55] yeah, there's a test runner option [14:55] or you can remove the cleanup code [15:35] jcsackett, mumble? [15:37] sinzui: sure, one moment. [15:39] flacoste: I don't know if you want to engage further but FYI: I just added a comment to https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 (didn't feel good about approving it, so I just commented) [15:40] benji: ok, thanks === beuno is now known as beuno-lunch === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 262 - 0:[########BOOM [16:03] bigjools, if you have a moment to look at https://bugs.launchpad.net/launchpad/+bug/869185 I'd appreciate it. Please triage it, or if it is faster to tell me what to do about it, do that instead and I'll follow up. [16:03] <_mup_> Bug #869185: P-a-s file ignored (even on cocoplum) < https://launchpad.net/bugs/869185 > [16:05] gary_poster: ok [16:05] thank you much [16:05] gary_poster: gah it's a mix of more than one bug [16:05] oh :-/ [16:06] gary_poster: I can explain for your delectation and delight if you like [16:06] bigjools, I'm happy to listen, sure :-) [16:06] do you know about the P-a-s file? [16:06] and learn even [16:06] no [16:06] ok, it's used when creating builds for sources and acts as an override to whatever the source thinks it should build on [16:07] so it can say !armel to exclude armel for example [16:07] ok [16:07] the ubuntu guys rely on it so that they can take packages from Debian with no changes [16:07] I figured it was somehinng like that from context [16:08] so bug #1 is that when we sync files from Debian using the new derived distros stuff, it doesn't use the P-a-s file at all [16:08] <_mup_> Bug #1: Microsoft has a majority market share argh go away mup [16:08] heh === salgado is now known as salgado-lunch [16:08] :-) [16:09] I se [16:09] e [16:09] bug two (ha! screw you mup) is that it also didn't appear to work for a regular upload of the libx86 package [16:09] :-) [16:09] ah ok. So the first is a non-critical feature bug (?) and the second is a critical regression? [16:09] he's talking about cocoplum since that's where the ubuntu uploads go [16:09] gotcha [16:10] so I need to split this into two [16:10] bear with me [16:10] cool [16:15] gary_poster: ok I updated the original bug a bit and reference the new one in it [16:16] * gary_poster looks [16:17] bigjools, why is first one (869185) not regression/critical? [16:17] gary_poster: I was just thinking about that [16:17] it's only a single package, hence my hesitation [16:17] right [16:17] * gary_poster leaves the decision to you :-D [16:18] thanks :) [16:18] fwiw, based on your explanation, if you had left it to me I would have said critical [16:19] (on the basis of "the rules") [16:19] rules are there to bend [16:19] :-) fair enough [16:20] I am just finding out if it's more widespread, if so it's a critical regression [16:20] ok [16:20]