[00:01] lifeless: Foreign keys on trigger-maintained denorm tables -- any opinions? [00:01] Seems like they're basically just going to slow things down. [00:05] wgrant: https://devpad.canonical.com/~stevenk/query.log.gz [00:07] waitwhat [00:07] accesspolicy_pkey should be a serial [00:08] It can't conflict, unless you're not dirtying the DB properly. [00:11] I don't get it either. :-/ [01:17] wgrant: stub wants them [01:17] wgrant: I'm not strongly enough opinionated to debate either way yet. [01:17] wgrant: intel SSD+1 [01:19] lifeless: Well, we can't do them for array columns... [01:23] lifeless: http://pastebin.ubuntu.com/869213/ [01:24] The enterprise ID probably can't include the instance like that. [01:24] Since they're clones of production. [01:24] But that's rather awkward. [01:24] StevenK: might want a qualifier added - e.g. 'object_to_enterpriseid(bug, 'comments') [01:24] wgrant: I was following lifeless' mail on the subject [01:24] lifeless: Why? [01:25] StevenK: I sketched out some thoughts on the txlongpoll discussion last weekend or so [01:25] StevenK: can always add it later [01:25] StevenK: it looks fine to me in all other regards [01:26] I don't see the point. We're converting an object to a representation of one, *not* a method/property on an object. [01:27] lifeless: I have hit a roadblock for enterpriseid_to_object(), in that I can't seem to get it return the object [01:27] StevenK: there is a relatively low cost of change here if we're careful, so I'm fine leaving it out. [01:27] StevenK: it wasn't in my initial emails after all :) [01:27] IE, going from 'Person' to Person() [01:28] StevenK: sys.modules['Person'] isn't what you want [01:28] StevenK: you want sys.modules['lp.registry.model.person'].Person [01:28] Right, which is fine for Person, but not PackageUpload [01:28] StevenK: I think you'll probably need something a bit more directly connected to the LP code layout than what you have [01:29] e.g. it may not be possible to JustSupport everything. [01:29] also remember that type needs to be unique [01:29] and your current implementation would be broken if e.g. lp.services.email grew a Person class [01:29] so, I suggest having an explicit map of supported types to strings, and strings to factories [01:30] e.g. known_types = [ [01:30] (Person, 'Person'), [01:30] ] [01:30] types = dict(known_types) [01:31] factories = dict((label, klass) for klass, label in known_types) [01:31] # adjust for taste === stokachu is now known as battlemidget [03:18] wgrant: I've pushed my branch to lp:~stevenk/launchpad/accesspolicy-garbo if you can peer at it. [03:33] StevenK: Looking [03:34] Ah [03:34] There's the problem. [03:34] test_hourly_script doesn't dirty its DB [03:34] test_daily_script does [03:34] StevenK: Try fixing that. [03:44] AH HA [03:44] About time :-( [03:51] wgrant: 'psycopg2.ProgrammingError: syntax error at or near "." [03:51] LINE 3: ALTER TABLE BugJob RENAME TO todrop.BugJob; [03:52] ' [03:52] wgrant: I think your advice is wrong :) [03:52] Haha [03:52] lifeless: That wasn't my command. [03:52] ALTER SCHEMA todrop [03:52] SET SCHEMA todrop [03:52] wgrant: you cleverly preserved it :> [03:52] Er, that [03:52] lifeless: I didn't really read the first sentence. [03:53] It was there already :) [03:55] wallyworld: Are you up for reviewing a branch of mine? [03:55] ok [03:55] wallyworld: https://code.launchpad.net/~stevenk/launchpad/accesspolicy-garbo/+merge/95834 [04:03] StevenK: i think you mean embardgoessecurity, not proprietary [04:04] wgrant: ^ [04:05] The wallyworld is correct. [04:05] proprietary is only for products with commercial subscriptions [04:06] StevenK: i'd like the tests to check the data as well as just the count [04:06] StevenK: because i'm stupid, why did you need to make a call to DatabaseLayer.force_dirty_database() ? [04:07] wallyworld: Because test_hourly_script is broken [04:07] of course :-) [04:07] test_daily_script did it, but test_hourly_script did not. [04:07] and existing tests didn;t need this? [04:07] And it was causing test failures in unrealted tests [04:08] ok [04:08] thanks for explaining [04:08] It depended on ordering. [04:08] Depending on what the next test did, it would have worked even with the dirty DB [04:08] eg. if it was just deleting stuff [04:08] yuk [04:08] Or using a non-serial primary key. [04:09] wallyworld: I don't see the point of testing the APs themselves in the test. [04:09] I would. [04:09] And it's like 2 lines. [04:09] StevenK: it's not testing the api, but that you have told the garbo scrip tto insert the correct data [04:10] ah, can't read, i thought you said api [04:11] but my point stands :-) [04:11] wallyworld: Anything else? [04:12] StevenK: no, looks nice otherwise [04:16] wgrant: could I ask a favour? ec2 land https://code.launchpad.net/~lifeless/launchpad/bugjob/+merge/95837 ? [04:17] lifeless: Self-reviewing a DB patch? Dubious. [04:17] But OK :) [04:17] * lifeless shrugs [04:18] I don't require stub to block on me for his schema changes. [04:20] wallyworld: http://pastebin.ubuntu.com/869352/ [04:22] StevenK: i'd use assertContentEqual to ignore sorting differences and you don't need the .count() check if you are conparing the actual values [04:23] wallyworld: Good point. [04:28] wallyworld: http://pastebin.ubuntu.com/869357/ [04:29] StevenK: i had a thought. will the logic fail if we add a policy to a pillar by hand? i think it will [04:30] it will think the pillar is already processed [04:30] but there may not be the 2 required policy types [04:30] Not for the test data, but I can't see us doing so until the garbo jobs are done [04:31] Distribution I can see being done during the first run [04:31] yes :-) [04:31] Product will take a little longer [04:31] yes, i'm concerned though since the fflag will be on for select users [04:31] and they can use the gui [04:31] perhaps we delay the fflag being on till garbo kob done [04:33] Right [04:34] . [04:35] lifeless: Your DSL sucks. [04:35] wallyworld: I've commited and pushed those changes. [04:36] * wallyworld taps fingers [04:38] wallyworld: Diff is updated [04:38] yes [04:38] I was just pondering filing a bug or [no-qa] [04:41] StevenK: r=me. to not cut corners, you should probably do qa on it [04:46] wallyworld, wgrant: QA-Landing looks awesomely full -- is it the truth? [04:55] StevenK: yes, i have a 4 pipe landing [04:56] but 2 yui tests are failing on ec2 [04:56] so am trying to fix [05:00] Ah yes, QA-Landing really has been wallyworlded. === battlemidget is now known as stokachu [05:49] mmm [05:49] * lifeless forgets when implicit db user switches occur [05:50] wgrant: sanity check me - we can drop the calculate-bug-heat db user and permissions === almaisan-away is now known as al-maisan [06:12] Why does https://launchpad.net/oops-tools say "This project is currently inactive." ? [06:12] because it is [06:13] you want python-oops-tools [06:13] wgrant: On the +sharing page when you are selecting a team to share with, why are there options to grant access to public and public security... am I missing something? It seems like you don't need to grant access for those things. [06:13] wallyworld: ^ [06:14] huwshimi: for private projects [06:14] huwshimi: or projects with private-by-default artifacts [06:15] lifeless: I feel like I'm missing something. So "Public" for a private project is private? [06:15] I thought this was the whole point of the policies [06:16] to have this stuff make sense :) [06:16] oh I see, you're saying that any artifact covered by the public policy really should be public [06:16] I'd need to page a bit more in to answer that; so I'll let wallyworld / wgrant / StevenK do so ;) [06:18] :) [06:21] * StevenK is neck deep in Django [06:21] * StevenK glares at lifeless === jtv1 is now known as jtv [06:26] oop, gotta go === al-maisan is now known as almaisan-away [07:22] StevenK: should we send someone after you? :) === almaisan-away is now known as al-maisan [09:06] aloha [09:10] good morning [09:42] Errr, why did lifeless land a DB patch to devel? [09:50] StevenK: do you actually sleep ? [10:19] Whoopsies [10:29] czajkowski: Sometimes. [10:30] is it even sleep time in StevenK's TZ? [11:15] jtv: any reason why on the RT we get mails *to* rosetta@launhcpad.net on a daily basis? [11:15] czajkowski: we stopped using that address a while back (it generated more pain than gain), so I'd guess there's a "legacy" forwarding to RT. [11:16] jtv: aye on a daily basis at least 3-4 rts are created [11:16] So you may want to figure out why the email gets there. For instance, users may be replying to outgoing mail that accidentally still uses rosetta@. [11:17] jtv: MAILER-DAEMON" [11:34] lifeless: Yes, they can go. [11:34] lifeless: AFAIK I removed them from the codebase a while back. [11:34] lifeless: But they need to be manually dropped from prod. [11:34] (the bug heat users) === al-maisan is now known as almaisan-away [12:17] mrevell, hey there. sorry to keep nagging, but I was wondering if you'll have some time to work with us on that work-items help text today? we would like to land it together with the new UI, if possible :) [12:18] salgado: morning [12:18] hi czajkowski! === matsubara-afk is now known as matsubara [12:32] salgado, Email incoming! :) [12:35] mrevell, perfect timing, thanks a bunch! [12:36] My pleasure :) Let me know if you need to talk about it. I'll be afk for 40 mins or so. [12:39] mrevell, there was a typo and the list of states was incomplete. I guess you won't mind me fixing that :) [12:39] mrevell, and https://help.launchpad.net/WorkItems doesn't exist yet === almaisan-away is now known as al-maisan === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugtasks: 4*10 [13:50] benji, I've put a trivial one up for review (https://code.launchpad.net/~salgado/launchpad/workitems-widget-help-popup/+merge/95894), if you have a couple minutes :) [13:51] salgado: sure [13:53] benji, fwiw, mrevell gave me the text you see there and I've already told him the wiki page linked to from there doesn't exist yet. I suppose he plans to steal the one from wiki.u.c [13:53] salgado: ok [13:53] salgado, benji: Hey, back from lunch. I'll create the wiki page this afternoon. [13:53] salgado, Thanks for making the corrections :) [13:54] salgado: review done [13:57] thanks benji. do you know how I'd go about using CSS to format the

 block there?
[13:59]  salgado: only with inline styles, but I suspect there's a CSS class already in existance for that
[13:59]  benji, ah, that'd be nice. I'll see if I can find it
[14:08]  benji, can't seem to find anything that would do it. is it ok if I just inline a margin-top: there?
[14:09]  salgado: you'd better ask someone more font-endy than me, we generally frown on inline style, but I don't know where the line is drawn, precisely
[14:12]  benji, ok, will do. anyone you'd recommend?
[14:12]  (don't really know who to ask for that these days)
[14:12]  deryck, maybe? ;)
[14:13]  salgado, hi. what's up?
[14:13]  salgado: Huw (huwshimi) would be a good start, but mrevell probably knows too
[14:13]  deryck, hi there.  we're discussing how to avoid a blank line in a  block: https://code.launchpad.net/~salgado/launchpad/workitems-widget-help-popup/+merge/95894
[14:13]  salgado, Yeah, it's best if you ask for a review from huwshimi.
[14:14]  and benji asked me to check with somebody more frontend-y than him, right when you joined
[14:14]  salgado, He'll help with the CSS side of things.
[14:14]  deryck, looks like you don't need to worry, though; I'll bug huw :)
[14:14]  salgado, ah, ok. cool :)
[14:14]  mrevell, cool, will do that
[14:14]  salgado, Huw's in Tasmania, so he won't be around for a few hours yet.
[14:32]  adeuring, abentley -- I'm coming, just taking a bit for the hangout to start for me.
[14:33]  rick_h_, could you have another look at the review since I fixed the info message for the whiteboard? I used your javascript
[14:34]  mabac, rick_h_ is unavailable until wed. maybe jcsackett could take it, since he's the mentor of rick_h_
[14:34]  * jcsackett perks up, goes to take a look
[14:35]  deryck, ok thanks
[14:36]  jcsackett, great thanks!
[14:37]  mabac: oh wow, this branch has had a lot happen since i last looked at it.
[14:39]  jcsackett, oh I hoped it wasn't too bad. it should just be changing the order of the text fields and then the js for displaying an info message when editing the whiteboard.
[14:39]  mabac: no, it's not bad. just a case of me sorting out all the activity so i know what i'm looking at. :-P
[14:39]  jcsackett, hehe ok. note that two revisions where backed out entirely
[14:40]  jcsackett, 14855 and 14856 are reverted in 14857
[14:48]  benji, do you have time to review my branches listed on https://code.launchpad.net/launchpad/+activereviews
[14:48]  sinzui: sure
[14:54]  sinzui: morning I think this one is a you question, as I remember I can't change a projects licience. https://answers.launchpad.net/launchpad/+question/189488
[14:55]  czajkowski, we do not own the project.
[14:55]  czajkowski, reactivate the project, then explain to the user that he can use the Change details link to update the license
[14:56]  sinzui: thank you.
[14:59]  jcsackett: I'm in/out (snack time for the boy) let me know if you need anything from me. Sorry it ran over until I was out
[14:59]  salgado, https://help.launchpad.net/WorkItems now redirects to a draft page that I'll flesh out and make live when we're ready.
[15:00]  mrevell, cool!
[15:08]  deryck: allenap what is the max apport attachment that can be uploaded to a bug ?
[15:09]  czajkowski, hmmm, not sure actually.  I can poke at code to see if allenap doesn't know off the top of his head.
[15:09]  rick_h_, geez, man, we're going to have to start calling you lifeless2
[15:09]  deryck: asking as someone reported a bug at the weekend, but just wondering was things crashing as lotta folks submitting things due to UGJ
[15:09]  deryck: https://bugs.launchpad.net/launchpad/+bug/945629
[15:09] <_mup_> Bug #945629: Launchpad chokes on tiny package, deeper throat required?  < https://launchpad.net/bugs/945629 >
[15:11]  czajkowski, ah, this is a known bug.
[15:11]  czajkowski, it's not attachment limits, am looking for the bug.
[15:15]  adeuring: are you up for a chat?
[15:19]  sinzui: I just finished your two reviews.
[15:21]  czajkowski: Comments (or at least bug descriptions) have a limit of 50,000 characters. I don't know of a limit for attachments, so... what deryck said :)
[15:21]  czajkowski, this is bug 194558.  I'll dupe against it.
[15:21] <_mup_> Bug #194558: Project file upload timeout (and often do not OOPS)     < https://launchpad.net/bugs/194558 >
[15:22]  allenap: deryck thank you
[15:22]  thank you benji
[15:22]  my pleasure
[15:23]  allenap, yeah, I guess we have no limits for how many attachments.
[15:24]  abentley: sure. mumbleß
[15:24]  =
[15:24]  adeuring: sure.
[15:24]  deryck: heh, love my job and all that right? Can't be too far from the laptop.
[15:24]  rick_h_, heh, fair enough. Just don't love it so much that you hate it in 6 months from burnout. ;)
[15:27]  sinzui: Gary points out that my code in the reviews isn't syntacticly correct, but I bet you'll get the gist
[15:28]  benji, thank. Your point is correct and I am playing with it now
=== al-maisan is now known as almaisan-away
=== matsubara is now known as matsubara-lunch
[15:56]  adeuring: celery does indeed implement soft timeouts via a signal handler: celery/concurrency/processes/pool.py:188
[15:56]  abentley: cool.
[15:58]  adeuring: However, I was wrong about soft timeouts being configurable from the apply_async invocation.  They are only configurable on a task-type basis.  We may need RunFastJob, RunSlowJob, RunReallySlowJob tasks.
[15:59]  abentley: ok, sounds good
[16:27]  jcsackett, do you have a few minutes to discuss a bug I am working on http://pastebin.ubuntu.com/870095/
=== Ursinha is now known as Ursinha-lunch
=== matsubara-lunch is now known as matsubara
[16:55]  sinzui: sure, i'm free.
[16:59]  jcsackett, fab. mumble or hangout
[17:00]  sinzui: i can do either. hangouts worked well last time.
[17:00]  okay hangout.
=== Ursinha-lunch is now known as Ursinha
[17:03]  jcsackett, https://plus.google.com/hangouts/c264c08394aabf490ee4492d4bc30adeb7741e97?authuser=0&hl=en#
[17:10]  abentley: lp:~adeuring/launchpad/lazr.jobrunner-oops
[17:11]  adeuring: thanks!
[17:12]  abentley: I think we should add a class BaseJob to runjob.py / jobrunner.py, just to document which methods and properties are required
[17:13]  adeuring: That makes sense.  We could extract it from FakeJob
[17:14]  abentley: yes, that's what I basically meant ;)
[17:25]  adeuring: I've put some changes in trunk, so it's a good idea to merge trunk.
[17:25]  abentley: right
[17:26]  adeuring: It looks interesting-- so we just build up an oops report and publish.
[17:27]  abentley: basically, yes. We still need to properly configure the OOPS reporting -- but that should not be done in lazr.jobrunner
[17:27]  (where "configure" means to pull in things like including a timeline, for exmaple)
[17:27]  adeuring: On the launchpad side, can we re-use the existing oops configuration?
[17:28]  abentley: I think we need to refactor the ErrorReportingUtility
[17:28]  adeuring: Oh, I see.
[17:29]  abentley: but generally my dea is that we can use the same, or at least a similar, oops_config in ErrorReportingUtility and in lazr.jobrunner
[17:29]  adeuring: Sounds good.
=== deryck is now known as deryck[lunch]
=== danhg_ is now known as danhg
=== deryck[lunch] is now known as deryck
[18:48]  benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/commercial-project-picker/+merge/95970
[19:11]  hi there, I'm trying to run the workitems branch but can't run it locally. I keep getting this error:  https://pastebin.canonical.com/61627/ when I make schema. Anyone have ideas how to fix that?
[19:20]  matsubara, if nobody has any ideas you might want to run ./utilities/launchpad-database-setup again
[19:20]  salgado, I did that already
[19:21]  hmm
[19:23]  are you running with postgresql8.4 or 9.1?
[19:27]  salgado, I think I have both installed. this last time I ran lp-db-deps it ran against the 9.1 db
[19:27]  do you have a debversion in your tree somewhere?
[19:28]  lib/lp/archivepublisher/debversion.py
[19:28]  right, same here
[19:28]  psql:launchpad-2209-00-0.sql:1230: ERROR:  could not access file "$libdir/debversion": No such file or directory
[19:28]  this is the error I'm getting
[19:28]  but that's not it
[19:28]  what's the libdir variable?
[19:29]   /usr/lib/postgresql/8.4/lib/debversion.so
[19:29]  that's the one
[19:29]  you seem to lack
[19:30]  I'd say get rid of 9.1 and try with 8.4. that works for me, on oneiric
[19:30]  there's a postgresql-8.4-debversion package, btw
[19:30]  but launchpad-database-dependencies depends on it
[19:33]  salgado, right, for 8.4 I had the debversion file, but not for 9.1
[19:33]  salgado, I stopped 9.1 and left only 8.4 running and am trying again
[19:33]  (I'm precise btw)
[19:33]  (I'm on precise btw)
[19:34]  good luck, then :)
[19:34]  :-)
[19:34]  I tried to set it up on precise about a month ago and gave up; ended up setting up an Oneiric container
[19:36]  salgado, it's applying the db patches now, so I think it's fixed. thanks salgado
[19:36]  salgado, I believe 9.1 can be used. I think we are switching to it soon
=== almaisan-away is now known as al-maisan
[19:38]    File "/home/matsubara/devel/canonical/lp-sourcedeps/eggs/txlongpollfixture-0.1.3-py2.7.egg/txlongpollfixture/server.py", line 131, in _start
[19:38]      raise Exception("Timeout waiting for txlongpoll to start.")
[19:38]  Exception: Timeout waiting for txlongpoll to start.
[19:38]  now I got that error when I make run
=== al-maisan is now known as almaisan-away
[19:38]  and it looks like it's running: 25320 pts/9    Sl     0:02 txlongpoll: accepting connections on 22435
[19:40]  ok, trying again worked.
=== matsubara is now known as matsubara-afk
=== danhg_ is now known as danhg
[20:48]  sinzui: to support the move of ec2 scripts from lp:launchpad to lp-dev-tools, I am thinking of copying the lastest bzr-pqm packages from the bzr daily PPA to the launchpad PPA.  Does that make sense?
[20:50]  abentley, could be. I run my own hacked version though since pqm-submit does not work on precise
[20:50]  abentley: that would be easier for folk w/out the bzr ppa
[20:50]  It would be nice to get the fix when someone actually applies my patch
[20:51]  Or discovered why I needed to write such am atrocious patch to make pqm-submit worl
[20:52]  sinzui: Where is your patch?
[20:53]  https://bugs.launchpad.net/bzr-pqm/+bug/922741
[20:53]  lifeless: Yes, that was my thinking.  I assume not everyone is on the dailies.
[20:53]  abentley, ^
[20:53] <_mup_> Bug #922741: AttributeError: 'BzrBranch7' object has no attribute 'get_config_stack'       < https://launchpad.net/bugs/922741 >
[20:54]  sinzui: Just going by the title, that may have been fixed in r86
[20:55]  well. I think I can test that in a few minutes. I am about submit a branch
[20:55]  sinzui: which bzr are you running?
[20:55]  o/
[20:56]  poolie: \o
[20:56]  abentley, 1.4.0~bzr83-1
[20:56]  * sinzui looks at his own branch
[20:56]  sinzui: which bzr, not which bzr-pqm?
[20:57]  oh duh
[20:57]  though from the traceback, I'd guess 2.5
[20:57]  2.5.0-1ubuntu1
[20:59]  sinzui: This is wacky, because in 2.5, BzrBranch7 does provide get_config_stack.
[20:59]  abentley, wacky indeed
[21:00]  I really don't think I should have needed that patch
[21:01]  abentley, I pulled tip (bzr-pqm) and submitted.
[21:02]  Look like it did its part correctly
[21:02]  sinzui: I'm glad of that.
[21:02]  abentley, and It was a success.
[21:03]  I think I can mark my patch invalid now
[21:04]  sinzui: I don't really get what happened there, though I'll mention ec2 is using the egg version of bzr, not the system version.
[21:05]  abentley, given the oddness of my patch (wallyworld ran it too), I think there were version inconsistencies for about 6 weeks
[21:08]  sinzui: It appears that the egg version of bzr did not support get_config_stack-- it landed in r6157.
[21:09]  sinzui: So we could chalk this up to launchpad running a beta bzr.
[21:10]  fab
[21:10]  I will tell my team
[21:11]  sinzui: I don't understand how a direct pqm-submit would be broken, unless you ran "bin/bzr".
[21:11]  sinzui: Or were also running a similar beta version.
[21:12]  abentley, ec2  and pqm-submit were all broken for me at the time I reported the bug
[21:13]  sinzui: Are you certain ec2 test was broken?  It shouldn't be using pqm-submit at all.
[21:13]  abentley, yes it was. I had to use a different computer for a week
[21:13]  until I decided to add the hack
[21:15]  sinzui: Okay.  I guess you were using "ec2 test -s" or similar?
[21:16]  yes, that is right
[21:16]  sinzui: forgive my confusion about ec2 test.  I don't use it, so I didn't realize it can land branches.
[21:26]  huwshimi, hi there. I've proposed a trivial branch (https://code.launchpad.net/~salgado/launchpad/workitems-widget-help-popup/+merge/95894) and my reviewer had some CSS-related questions so I was pointed at you :)
[21:26]  it'd be great if you could have a look and tell me how I should proceed there :)
[21:27]  salgado: Sure! Let me take a look
[21:28]  salgado: Would you like me to comment here or on the mp?
[21:29]  huwshimi, either way is fine with me
[21:33]  salgado: I just replied on the mp
[21:34]  oh, of course!
[21:34]  thanks huwshimi!
[21:35]  salgado: Hopefully that will give you proper spacing, but if not we can look at some CSS
[21:37]  yep, confirming that now
[21:39]  salgado: you should steal my greasemonkey work items editor at some point :)
[21:45]  mwhudson, we considered that but in the name of simplicity we decided to use a textarea for now
[21:45]  fair enough
[21:46]  it will be trivial to adapt the greasemonkey to that i assume
[21:46]  although the parsing/unparsing/parsing thing will be a bit strange
[21:46]  salgado: you are exposing the work items on the api i assume?
[21:47]  mwhudson, yes, for now only as a text field, using the same format as before. so you just have to change .whiteboard to .workitems_text, hopefully
[21:48]  salgado: oh, the api representation is as text as well?
[21:49]  mwhudson, yep
[21:49]  ok
[21:50]  salgado: how does this help status.l.o then?  you just know that it's formatted correctly?
[21:52]  mwhudson, yes, and we catch/fix errors when users enter them so they won't have to be nagged by status to go back and fix it later.  our actual goal is not really to help status though -- we want to implement work item reports in LP: https://dev.launchpad.net/Projects/WorkItems
[21:52]  ah ok
=== matsubara-afk is now known as matsubara
=== benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10
[22:28]  lifeless: So why did your DB patch branch hit devel?
[22:29]  hahhaa bad defaults.
[22:29]  fortunately it will do no harm
[22:30]  What? We had db-devel as the default for YEARS
[22:30]  And it caused no end of issues
[22:33]  StevenK, regardless of future sharing and past legacy rules, user should be permitted to see public bugs. https://bugs.launchpad.net/launchpad/+bug/872870
[22:33] <_mup_> Bug #872870: Public bug cannot be viewed when linked to a private branch <403>       < https://launchpad.net/bugs/872870 >
[22:58]  wallyworld_, your can pull https://code.launchpad.net/html5-browser I tested the env using
[22:58]  HTML5BROWSER_USE_PYGTK='true' ./test.py
[23:05]  wallyworld_, see https://code.launchpad.net/~sinzui/+recipe/html5-browser-daily
[23:12]  morning
[23:12]  * StevenK 's world crashes down
[23:12]  wallyworld_, have you run this yet
[23:12]  apt-add-repository ppa:sinzui/ppa
[23:12]  sinzui: sure have
[23:13]  just waiting for build now :-)
[23:20]  wgrant: do youi know of a way to say 'fuk it everything will need [SELECT|UPDATE|DELETE] on table Y' ?
=== matsubara is now known as matsubara-afk
[23:21]  lifeless: public
[23:21]  lifeless: But please don't.
[23:21]  THe only things that really belong there are...
[23:21]  hmm
[23:21]  SELECT on featureflag
[23:21]  And nothing else.
[23:22]  Ah, that's there already.
[23:22]  And pillarname
[23:33]  huwshimi: hi, sorry i missed you yesterday - was buying food for dinner. with your question, the +sharing page is wip. those options are being fixed and other stuff also being sorted out
[23:33]  wallyworld: No problems
[23:33]  wallyworld: So will the public options still be there?
[23:34]  huwshimi: nope. only embargoes security and userdata, and for commercial projects, proprietrary
[23:34]  wallyworld: OK great, thanks for that!
[23:35]  huwshimi:  np. i have a branch that i'm about to land with those changes, plus there are now checkboxes so you can select more than one
[23:35]  wallyworld: Ah great
[23:36]  wallyworld: The new packages should be published.
[23:45]  wgrant: thanks, that was fast
[23:47]  wgrant: mail sending
[23:48]  wallyworld: Queue-jumping is handy :)
[23:48]  indeed
[23:48]  lifeless: I await it in fear.
[23:49]   /win goto mbarnett
[23:49]  bah
[23:49]  That makes me even more concerned.
[23:49]  lifeless: that was more like a summon!
[23:49]  mbarnett: My fingers apologise to you.
[23:50]  lifeless: I see no mail.
[23:50]  Did it go via forster?
[23:50]  lifeless: you suck
[23:50]  2012-03-05 23:50:25 WARNING Bad object name 'public.bugjob'
[23:51]  wgrant: you suck too. But enough of the compliments.
[23:51]  wgrant: you're talking about bugjob landing on the wrong branch? Has it caused a buildbot failure ?
[23:51]  lifeless: No, but you forgot to remove DB permissions.
[23:51]  So security.py whinges.
[23:52]  The mislanding won't cause any problems.
[23:52]  yeah
[23:52]  It just makes you the first violator of your policy :)
[23:52]  Haha
[23:52]  wgrant: does anything need calculate-bug-heat, talking of security.cfg ?
[23:52]  lifeless: No.
[23:52]  I apparently forgot to remove it from security.cfg
[23:52]  In my cleanup a few months back.
[23:52]  (and from prod)
[23:53]  And then it needs to be manually dropped from prod
[23:53]  yeah
[23:53]  And cleaned up from pgpass etc
[23:53]  I will leave that to you, enough WIP as it is
[23:53]  I may demolish it along with bugjob permissions in a few seconds.
[23:54]  lifeless: Oh, by "mail sending" you meant you were talking about permissions for sending mail, rather than that you were sending a mail about the permissions?
[23:54]  right
[23:54]  That explains why I see no email.
[23:54]  and notifications more generally.
[23:54]  I shall stop looking for the problem with forster.
[23:55]  wgrant: hah! indeed.
[23:58]  poolie: sat here chuckling at your tweet
[23:58]  Is that a replacement for "lol"?
[23:59]  lolling is not chuckling
[23:59]  lol is for when people want you to think they liked something your said but are not really laughing at all
[23:59]  you* said, even
[23:59]  True, true.