[00:00] <wallyworld__> it works locally without doing that
[00:00] <wgrant> 2.7's set_charset (called by set_payload) encodes it if it's a unicode.
[00:00] <wgrant> 2.6 doesn't have that check.
[00:02] <wallyworld__> huh? my 2.6 does
[00:02] <wallyworld__>         if isinstance(self._payload, unicode):
[00:02] <wallyworld__>             self._payload = self._payload.encode(charset.output_charset)
[00:02] <wgrant> Ahhh.
[00:02] <wgrant> Lucid's does not.
[00:02] <wgrant> I don't think I have 2.6 installed on oneiric... let me check.
[00:03] <wallyworld__> it's all thumper's fault
[00:03] <thumper> it must be
[00:03] <wallyworld__> it was going to be a quick patch to help out my old kiwi mate and look what it's turned into
[00:04] <StevenK> wallyworld__: Welcome to Soyuz.
[00:04] <StevenK> Oh. Wait.
[00:04] <wallyworld__> :-)
[00:05] <wgrant> wallyworld__: See the latest rev on http://bazaar.launchpad.net/~python-dev/python/2.6/changes?filter_file_id=43136%406015fed2-1504-0410-9fe1-9d1591cc4771%3Apython%252Ftrunk%252FLib%252Femail%252Fmessage.py
[00:05]  * wallyworld__ looks
[00:05] <wgrant> http://bazaar.launchpad.net/~python-dev/python/2.6/revision/42357
[00:06] <wgrant> Crucially, from the old email.message docs:
[00:06] <wgrant> 139
[00:06] <wgrant>
[00:06] <wgrant>       The message will be assumed to be of type :mimetype:`text/\*` encoded with
[00:06] <wgrant> 140
[00:06] <wgrant>
[00:06] <wgrant>       *charset.input_charset*.
[00:06] <wgrant> The new:
[00:06] <wgrant> 139
[00:06] <wgrant>       The message will be assumed to be of type :mimetype:`text/\*`, with the
[00:06] <wgrant>
[00:06] <wgrant> 140
[00:06] <wgrant>       payload either in unicode or encoded with *charset.input_charset*.
[00:07] <wallyworld__> wgrant: well, the only thing to do then is to assume it's broken and code around it in our stuff
[00:08] <wallyworld__> what's the policy with upgrading python on our prod environments? i think it will just be easier to hack around it in our code?
[00:08] <wgrant> Not hack around it.
[00:08] <wgrant> The old Python behaviour is not buggy.
[00:09] <wallyworld__> you sure? "Also makes the way in  which unicode gets encoded to quoted printable for other charsets more  sane (it only worked by accident previously)"
[00:09] <wallyworld__> seems like they made some changes to fix broken/unintuitive behaviour
[00:10] <wgrant> Right, but set_payload taking Unicode is behaviour that is new in 2.6.6 or 2.6.7
[00:10] <wgrant> Passing Unicode into Lucid's version violates expectations set out in the docstring.
[00:10] <wgrant> It's certainly an unintuitive response to interface abuse, but it's still interface abuse :)
[00:11] <wallyworld__> which means i need to encode outside of set_payload, which is hacking around it
[00:11] <wgrant> It's not hacking around it.
[00:11] <wgrant> It's using set_payload properly.
[00:12] <wgrant> set_payload, until a year ago, was intended to be given encoded data.
[00:12] <wallyworld__> except that it accepts a charset parameter which implies it will be doing the encoding based on that charset
[00:12] <wgrant> The only reason unicode sometimes worked is because Python 2.x's Unicode support is terrible.
[00:12] <wgrant> How does it imply that?
[00:12] <wgrant> It
[00:13] <wgrant> indicates the encoding of the message.
[00:13] <wgrant> But the docstring is pretty clear.
[00:13] <wgrant> It expects the message to be in text/*, encoded in the given encoding.
[00:13] <wallyworld__> sure.
[00:13] <StevenK> So it wants UTF-8, not unicode
[00:13] <wallyworld__> perhaps i was misusing the term "hacking"
[00:14] <wallyworld__> i was being loose with my definition
[00:14] <wgrant> Perhaps.
[00:14] <wallyworld__> i just meant i have to make changes to accommodate the old interface
[00:14] <wgrant> Right.
[00:14] <wallyworld__> even though the new one supports what we want
[00:14] <wallyworld__> is was using hacking the the sense of "code hacking" ie code writing
[00:15] <wallyworld__> anyways
[00:15] <wgrant> Anyway, easy fix, hopefully.
[00:15] <wallyworld__> yep
[00:15] <wallyworld__> so long as my system stays up
[00:18]  * wallyworld__ wishes he had an SSD
[00:26] <wallyworld__> wgrant: can you try it now?
[00:28] <wallyworld__> wgrant: i wasn't sure whether to use content.encode(charset) or content.encode(charset.output_charset). i used the first one
[00:50] <wgrant>   Running:
[00:50] <wgrant>  lp.code.mail.tests.test_branch.TestBranchMailerDiff.test_generateEmail_with_diff
[00:50] <wgrant>   Ran 1 tests with 0 failures and 0 errors in 0.537 seconds.
[00:50] <wgrant> wallyworld__: ^^
[00:50] <wallyworld__> wgrant: excellent! thanks for your help
[00:51] <wgrant> wallyworld__: How does this work with non-UTF-8 files?
[00:52] <wallyworld__> wgrant: it works fine. there's other tests which use plain ascii diffs
[00:54] <wgrant> ASCII diffs are also UTF-8.
[00:54] <wallyworld__> perhaps i misunderstood your question
[00:55] <wgrant> What happens if I try to diff a UTF-16 file?
[00:55] <wallyworld__> the charset parameter to addAttachment() is optional
[00:56] <wgrant> Yes, but BranchMailer always uses utf-8.
[00:56] <wallyworld__> the check is isinstance(payload, unicode)
[00:57] <lifeless> bzr treats all files as bytestreams for diff
[00:57] <poolie> mm kinda
[00:57] <poolie> i'm pretty sure a utf-16 file will be reported as 'binary files differ'
[00:58] <lifeless> right, but we don't do the diff as unicode
[00:58] <lifeless> so diffing a slavic codepage file against the same text in utf8 will show the encoded difference, not the decoded difference.
[00:59] <lifeless> Unless that has changed?
[00:59] <poolie> that's correct
[01:00] <poolie> it could usefully be changed, perhaps, but that's true at the moment
[01:00] <lifeless> and will include slavic codepage + utf8 in the output
[01:00] <lifeless> so the output of diff, today, doesn't have a 'safe correct' encoding. File paths we encoded to the supplied encoding, but thats the only bit of user data we have a clear content type for
[01:00] <wgrant> That is my concern.
[01:01] <wallyworld__> wgrant: so the isinstance(xxx, unicode) check prevents utf-16 strings from being touched by any utf-8 stuff
[01:02] <wgrant> Perhaps, but how does it get a unicode in the first place?
[01:02] <wgrant> There's no unicode-safe way to handle diffs. They have to be treated as bytestreams.
[01:02] <lifeless> erm, it stops unicode strings being processed, but the intputs are not decoded, so utf16 would still be there as utf16 (if it doesn't trip the binary check poolie mentioned)
[01:02] <wallyworld__> not sure. maybe thumper knows since he raised the bug
[01:02] <wgrant> And yes, we're probably still going to be declaring UTF-16 as UTF-8, which would be Bad.
[01:02] <lifeless> I think he was hoping it was easy; its not.
[01:03] <wgrant> It's easy unless you've dealt with encodings before :)
[01:03] <lifeless> personally, I'd triage it low, add a task asking for a way to get *a* defined content coding out of bzr diff, and then let the discussion happen.
[01:04] <wallyworld__> wgrant: why would we be declaring utf-16 as utf-8?
[01:04] <wallyworld__> actually, we are, but that's a bug i will fix
[01:05] <wgrant> Fix how?
[01:05] <wgrant> We need to investigate how we are getting decoded Unicode diffs in the first place.
[01:05] <wgrant> Since that doesn't really make sense.
[01:06] <wallyworld__> wgrant: the utf-8 encoding only occurs if the payload is a unicode instance
[01:07] <wallyworld__> and since utf-16 is not a unicode instance, we are not declaring the payload to be utf-8
[01:07] <wallyworld__> via the content type header
[01:08] <wgrant> Yes, but there's no way that can correctly be a unicode instance.
[01:08] <wgrant> So the special case will either never be used, or there is another bug creating "unicode" diffs.
[01:10] <wallyworld__> i'm not sure how the diffs get generated etc. the request was "when we attach diffs to outgoing code review and branch emails can we please utf-8 encode"
[01:11] <wallyworld__> so if the diffs are never unicode in the first place, that's a separate issue to solve i guess
[01:11] <wgrant> I presume he wants them *declared* as UTF-8.
[01:11] <wgrant> They were probably already mostly encoded in it.
[01:11] <lifeless> the committer and paths will be utf8
[01:12] <lifeless> whats probably happening is that we have a TEXT column note a BYTEA column.
[01:12] <wgrant> Diffs are in the librarian, or not stored at all.
[01:12] <wgrant> Not in the DB.
[01:12] <lifeless> or we're treating the text from the librarian as utf8 and decoding it, we'll be getting punning (and sporadic failures when smeone has garbage in their tree
[01:12] <wallyworld__> the last part of the request was "we have people with weird names committing or .po file stuff et al"
[01:13] <wgrant> Storm will generally correctly kick you in the face if you try to do bad Unicode stuff.
[01:13] <wallyworld__> so yes, it's to do with the committer etc
[01:13] <wgrant> Sounds like file content: PO headers.
[01:13] <wallyworld__> yes
[01:14] <wallyworld__> and such stuff would be in the diffs. but if the diffs never arrive at the send mail method as unicode.....
[01:14] <poolie> lifeless, on the command line you do get a defined decoding out of bzr diff
[01:14] <lifeless> poolie: ah, good. I though it was still a bit hairy.
[01:14] <poolie> i'm 90% sure if you have a utf-8 locale and you diff from utf8 to cpwhatever, the + lines will have questionmarks
[01:15] <poolie> mm
[01:15] <poolie> i have seen the bug traffic but i'm not sure what the actual motivating case is
[01:15] <wgrant> poolie: Hm, that's pretty unpleasant.
[01:15] <wgrant> The diff not being a diff.
[01:15] <lifeless> wgrant: it has the great advantage of not turning peoples terminals into mojibake
[01:15] <wallyworld__> poolie: you mean for bug 861979?
[01:16] <_mup_> Bug #861979: utf-8 encode diffs attached to outgoing email <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/861979 >
[01:16] <poolie> well, i think you can choose between "accurate but not in the right encoding" and "in the right encoding but not complete"
[01:16] <poolie> at the api level you can
[01:16] <wgrant> lifeless: That's true, but it has the disadvantage of being wrong.
[01:16] <lifeless> wgrant: given there is no right answer for a unicode terminal, I find asserting its wrong to be...interesting :)
[01:16] <poolie> lifeless, thanks, i have seen that but it's not very complete
[01:16] <wgrant> lifeless: It is not a correct diff.
[01:17] <poolie> if the actual thing is that they have validly encoded file names
[01:17] <poolie> then utf-8 encoding the output diff would be a reasonable improvement
[01:17] <poolie> it's a simpler case than having arbitrary binary transforms
[01:17] <poolie> wgrant, the question is whether you are generating the diff to feed to patch (to apply it as a binary diff) or to look at it
[01:18] <poolie> the two things need different results
[01:18] <wgrant> Yes.
[01:20] <wallyworld__> so, given all this, am i correct in thinking lp is not given a unicode diff to attach to its emails?
[01:25] <wgrant> lifeless: Shouldn't bug #869064 be High? It's not a released feature yet.
[01:25] <_mup_> Bug #869064: Batched comment loading should update the page URL to include ?comments=all <story-batched-comment-loading> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/869064 >
[01:26] <wgrant> Bug #867529, too.
[01:26] <_mup_> Bug #867529: Dynamic loading comments load on top of page content <regression> <story-batched-comment-loading> <Launchpad itself:Triaged> < https://launchpad.net/bugs/867529 >
[01:26] <wgrant> Or do they inherit criticality?
[01:28] <poolie> wallyworld__, didn't you already land a fix for this?
[01:28] <wallyworld__> poolie: it failed ec2 due to python differences on lucid vs oneiric
[01:28] <wallyworld__> so it's still not landed
[01:28] <wallyworld__> those issues are now fixed
[01:28] <wallyworld__> but is there any point?
[01:29] <wallyworld__> if the diffs passed to lp are never unicode?
[01:31] <poolie> 1- you need to be more precise about 'unicode'
[01:31] <poolie> 2- it depends on how it's calling bzr (external 'bzr diff', through the api, etc) and what locale it is in
[01:32] <wallyworld__> poolie: unicode as in a python string u'xxxxx' ie isinstance(diff, unicode). i'm not sure what the underlying encoding details would be
[01:32] <lifeless> wgrant: its behind a feature flag? I thought the flag was toggled ?
[01:32] <poolie> it's called inprocess?
[01:33] <wgrant> lifeless: I hope it's only released for betatesters...
[01:33] <wgrant> bugs.batched_comment_loading.enabled	team:launchpad-beta-testers	1	on
[01:33] <wgrant> bugs.batched_comment_loading.enabled	team:launchpad	0	on
[01:34] <lifeless> fixed
[01:34] <wallyworld__> poolie: 2. i'm not sure how it's being called, will have to check. it's for when lp sends out codereview and branch emails. po files have committer info in the header and we want these to come through properly for international names
[01:34] <wgrant> lifeless: However, it could possibly be priority inheritance.
[01:35] <lifeless> wgrant: possibly; if so gmb can and (hopefully will) say 'its critical cause I'm using it to fix bug ABCDE'
[01:44] <poolie> wallyworld__, i think if you call the right api you will get unicode diff results
[01:44] <poolie> if there is now way to get them file a bzr bug and we'll help
[01:44] <poolie> but i would be surprised, because it works from the command line
[01:44] <wallyworld__> poolie: i think the show_diff_trees api is being used
[02:08] <poolie> hm apparently that returns a byte stream, probably utf8 encoded
[02:08] <poolie> the way it is handled in lp seems to suggest it's expected to be a byte stream too
[02:19] <wallyworld__> poolie: so the change in lp is to essentially make the Content-Type header say "text/x-diff; charset="utf-8""
[02:19] <wallyworld__> i think based on what you said that will be ok?
[02:32] <poolie> i think so
[02:32] <poolie> does it work?
[02:41] <poolie> out for a bit
[03:13] <nigelb> Morning!
[03:15] <spm> o/ nigelb
[03:17] <nigelb> ohai spm :)
[03:17] <nigelb> wallyworld__: How's your love affair with ec2 going? :P
[03:22] <wallyworld__> nigelb: well, the problem is fixed. it was a python 2.6 version issue. python email encoding on lucid behaves differently to on oneiric
[03:25] <nigelb> wallyworld__: Oh.
[03:25] <nigelb> In a good way or bad way?
[03:27] <wallyworld__> nigelb: different. here a link to the diff http://bazaar.launchpad.net/~python-dev/python/2.6/revision/42357
[03:28] <wallyworld__> it now accepts unicode payloads and checks that a payload is unicode before it encodes it using the supplied charset
[03:29] <nigelb> \o/
[03:29] <nigelb> Nice find :)
[03:33] <wallyworld__> nigelb: wgrant looked at his copy of python 2.6 on lucid to discover the difference in behaviour and provided me the diff
[03:33] <nigelb> Neat
[04:19] <lifeless> aieieeeeeee
[04:19] <lifeless> https://bugs.launchpad.net/launchpad/+bug/869631/comments/6
[04:19] <_mup_> Bug #869631: BugTask:+editstatus timeout closing bug 353126 due to bug subscription lookups <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/869631 >
[04:21] <wgrant> lifeless: So the query is returning unrelated mutes?
[04:21] <lifeless> yes
[04:21] <lifeless> muting any bug will mute you for all notifications via duplicates
[04:21] <wgrant> That's the production query that's insane?
[04:21] <wgrant> Oh.
[04:21] <wgrant> Isn't that intended?
[04:21] <lifeless> *all*
[04:21] <lifeless> mute bug 1.
[04:21] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS P
[04:22] <lifeless> then for 12134 a dupe of 456678 you won't get notified *if you would have previously*
[04:22] <wgrant> Oh!
[04:22] <wgrant> Unrelated duplicates.
[04:22] <wgrant> I see.
[04:25] <lifeless> constraining the subquery makes it a 2ms query
[04:25] <wgrant> Heh
[04:25] <wgrant> What if you just s/Bug,//?
[04:26] <wgrant> That should fix it too, though it'll still be a subquery.
[04:27] <lifeless> 3ms
[04:32] <lifeless> all in the bug
[04:32] <lifeless> but - wow
[04:32] <wgrant> Yes.
[04:32] <lifeless> its also worrying that its doing this multiple times
[04:32] <wgrant> Most of the advanced subscriptions work is like that.
[04:32] <wgrant> Repetitious.
[04:32] <lifeless> all dupes are handled by one of these queries, why does it need to do it more than once
[06:58] <huwshimi> Have a good weekend all
[08:01] <mrevell> Hey there
[08:58] <lifeless> poolie: wow, silentghost, wow.
[08:58] <lifeless> allenap: the reason its slow to kill the machine is that its a infinite loop
[08:59] <lifeless> allenap: but failure in err() isn't the same as failure in a deferred
[08:59] <bigjools> lifeless: yeah we figured that out just now in our call
[08:59] <lifeless> allenap: so when it fails after an oops, thats in a deferred. It has no errback()
[09:00] <lifeless> allenap: so that triggers a __del__ failure, and round it goes.
[09:00] <lifeless> bigjools: cool
[09:00] <bigjools> lifeless: Python dynamic typing sucks :)
[09:00] <poolie> lifeless, oh in the python bug?
[09:01] <lifeless> poolie: yeah
[09:01] <poolie> i agree it's not the nicest part of python
[09:01] <lifeless> bigjools: s/Python// and then yes, sure ;)
[09:02] <poolie> also by analogy to other things, you might think that 'callable(x)' *coerces* x to be callable
[09:02] <lifeless> bigjools: a friend of mine, erik de casto lopo, *loathes* dynamic typed languages.
[09:02] <poolie> as for dict, int, etc
[09:02] <bigjools> it also is the best thing since sliced bread
[09:02] <lifeless> poolie: I believe thats one of the criticisms of callable
[09:02] <bigjools> yeah, it requires a different mindset
[09:02] <bigjools> was hard for me to adjust coming from C++
[09:03] <lifeless> bigjools: he loathes c++ too :P [like most of us, he is opinionated ;P]
[09:03] <bigjools> :)
[09:03] <StevenK> Erik is a good guy
[09:03] <bigjools> what does he use, $obscure_language?
[09:03] <StevenK> OCaml
[09:03] <poolie> yes, ocaml
[09:03] <StevenK> And Haskell
[09:04] <lifeless> and C :)
[09:04] <lifeless> http://mstation.org/erikdecl.php
[09:04] <poolie> i was writing some python just now and thinking how much better it would be in a functional language, up to the point i needed a library
[09:04] <lifeless> a little dated interview, before his functional phase AFAICT, but still gets him about right ;)
[09:04] <poolie> oh i thought that was meant to convey that he liked php :)
[09:05] <bigjools> I remember using proof by induction with functional languages.  Head fuck.
[09:05] <bigjools> php is right up there with perl
[09:05] <bigjools> or is that down there... :)
[09:06] <lifeless> bigjools: btw, buikld status 6 + log -> what does that mean ?
[09:06] <bigjools> lifeless: need a bit more context than that!
[09:06] <StevenK> Build Status 6 == BUILDING
[09:06] <StevenK> But it has a log set
[09:06] <StevenK> And date_finished
[09:06] <lifeless> bigjools: there was a bug filed by spm yesterday
[09:07] <bigjools> it's bug 717969
[09:07] <_mup_> Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <qa-untestable> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/717969 >
[09:07] <lifeless> bigjools: cause nagios etc
[09:07] <lifeless> StevenK: thanks
[09:07] <bigjools> lifeless: dupe it to that one then
[09:07] <bigjools> jtv is working on it
[09:07] <lifeless> bigjools: I figured jtv would want to look at it, but I was also curious about what it means
[09:07] <bigjools> it's a transaction issue across Deferreds
[09:07] <StevenK> But how? storeBuildInfo() sets the log and so on, doesn't it?
[09:07] <lifeless> bigjools: well, I think the bug is about data cleanup - or will you sort them all out at once once root cause is fixed ?
[09:08] <bigjools> what's spm's bug?
[09:08] <lifeless> bug 868917
[09:08] <bigjools> StevenK: we found a load of places where a commit() in one callback was committing more than it should
[09:08] <_mup_> Bug #868917: broken build alert <canonical-losa-lp> <ops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/868917 >
[09:09] <bigjools> lifeless: I say dupe it for now unless proven otherwise, 717969 is the most likely cause.  /me dupes
[09:10] <lifeless> bigjools: do we need to do the data cleanup for it ?
[09:10] <bigjools> yes
[09:10] <allenap> lifeless: Cheers for the explanation. I thought it was probably something like that, but it's good to know exactly what.
[09:10] <lifeless> allenap: (thats a theory, but it fits all the facts I know about this)
[09:11] <bigjools> lifeless: I believe the losas have a script
[10:02] <cjwatson> bigjools: are you up for a chat about bug 572128 nowish?
[10:02] <_mup_> Bug #572128: Ubuntu Archive translations are missing Index metadata file <regression> <Launchpad itself:Triaged by cjwatson> <debmirror (Ubuntu):Confirmed> < https://launchpad.net/bugs/572128 >
[10:04] <bigjools> cjwatson: sure, good timing
[10:04] <bigjools> cjwatson: want to jump on voip/skype?
[11:19] <wgrant> bigjools, cjwatson: Did you get that sorted out? I guess it's pretty urgent.
[11:26] <bigjools> yes
[11:31] <cjwatson> bigjools: there's an XXX from cprov suggesting using a generic Release parser, and I really don't want to perpetrate even more similar horrible code - would it be OK to use debian.deb822.Release to test the contents of Release files?
[11:31] <bigjools> cjwatson: hell yes
[11:32] <cjwatson> then I might fix the existing code while I'm here, too
[11:32] <bigjools> champion :)
[11:33] <bigjools> AttributeError: type object 'ZopelessDatabaseLayer' has no attribute 'switchDbUser'
[11:33] <bigjools> waaaaaa
[11:34] <wgrant> bigjools: You need to use LaunchpadZopelessLayer for switchDbUser
[11:34] <wgrant> bigjools: BUT
[11:34] <wgrant> bigjools: As of two weeks ago that's a deprecated API.
[11:34] <wgrant> Use lp.testing.dbuser instead.
[11:34] <wgrant> Works in any layer.
[11:34] <bigjools> I am not using it, my parent test class is
[11:34] <bigjools> deep in the publisher
[11:34] <wgrant> Use LaunchpadZopelessLayer, or fix your parent to use lp.testing.dbuser directly.
[11:35] <wgrant> switchDbUser is now just a trivial wrapper.
[11:35] <bigjools> going former for now, although startup time PAIN
[11:36] <wgrant> The Zopeless layers will soon be abolished, but I need to sort out different security policies and blah.
[11:36] <bigjools> why?
[11:36] <wgrant> Because there's nothing special about them any more.
[11:36] <wgrant> Basically, they run in PermissiveSecurityPolicy instead of LaunchpadSecurityPolicy, and they don't have WSGI interceptors installed.
[11:36] <wgrant> Apart from that they are interchangeable.
[11:36] <bigjools> so I can just have a DatabaseLayer?
[11:37] <wgrant> You probably actually want DatabaseFunctionalLayer, but yes.
[11:37] <wgrant> Watch out for the security policy difference, though.
[11:37] <bigjools> I probably don't
[11:37] <wgrant> You don't need the CA at all?
[11:37] <bigjools> CA?
[11:37] <wgrant> Component Architecture
[11:38] <bigjools> yes, but I don't want the bloody librarian
[11:38] <wgrant> DatabaseFunctionalLayer.
[11:38] <wgrant> Unless the layer says "Launchpad" or "Librarian", there's no librarian.
[11:38] <bigjools> good
[11:39] <bigjools> wfm
[11:39] <wgrant> DatabaseFunctionalLayer is basically the same as ZopelessDatabaseLayer, except that the order of the name is inexplicably different and the security policy is different.
[11:39] <wgrant> And, until two weeks ago, stuff needed to use *Zopeless* if it wanted to change DB users.
[11:39] <wgrant> But that was all BS historical crap.
[11:39] <wgrant> Which I deleted.
[11:39] <bigjools> yeah
[11:40] <bigjools> man, storm is really frustrating sometimes
[11:40] <wgrant> Oh?
[11:41] <bigjools> "expected int, found Reference"
[11:41] <wgrant> Ah.
[11:41] <wgrant> Well, that's sort of reasonable.
[11:41] <wgrant> What's unfortunate is that you can't do Reference == Reference
[11:41] <bigjools> nonetheless frustrating
[11:41] <wgrant> s/unfortunate/pointless/
[12:04] <jml> wgrant: fwiw, ZDL came after DFL
[12:05] <jml> wgrant: so now the only difference between "zopeless" and "functional" is default security policy, right?
[14:35] <danilos> jcsackett, hi, I have a feeling that bug 627631 was not really fully solved, and bugtasks for other applications have gone (like translations) in our reorg: can you confirm that suspicion I have? :)
[14:35] <_mup_> Bug #627631: Queries need to be updated to use usage enums, where possible <bridging-the-gap> <lp-registry> <qa-ok> <Launchpad itself:Fix Released by jcsackett> < https://launchpad.net/bugs/627631 >
[14:40] <sinzui> danilos, many were reintroduced after the branch landed.
[14:42] <danilos> sinzui, fwiw, I only saw one for official_rosetta with an XXX from jcsackett pointing to the bug above (other usages of official_rosetta seem to be in tests)
[14:43] <sinzui> I added two official_malone recently. I was reading the schema. I think we need to change the schema to make it obvious that official_* is not always correct
[14:44] <danilos> sinzui, I think we can remove the official_rosetta with that one fix if that was the ultimate goal
[14:44] <sinzui> yes I think so to
[14:45] <sinzui> jcsackett, pointed out my mistake and said we might be able to fix everything on in a single branch
[15:12] <cjwatson> bigjools: https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618 for your delectation and delight
[15:15] <bac> sinzui: do you know how the mechanism for automatically hiding the notification box works?
[15:16] <sinzui> bac: no. I do not think I have ever seen a notification hide
[15:17] <sinzui> bac: do you mean the click to hide that benji had worked on?
[15:17] <bac> sinzui: or maybe it hid so fast you didn't notice!
[15:17] <bac> sinzui: no, it is autohiding now, at least for the bug_acknowledgement_message
[15:17] <bac> sinzui: i've searched for the JS that is doing it but haven't found it yet
[15:18] <sinzui> I am clueless
[15:18] <bac> sinzui: as described in bug 846163
[15:18] <_mup_> Bug #846163: bug filing notice is removed before the user can read it <regression> <ubuntu-qa> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/846163 >
[15:18] <bac> sinzui: thanks anyway
[15:18] <bac> i thought it would be somewhere like client.js...
[15:18] <benji> sinzui: unfortunately I was never able to get the click-to-hide stuff just right, so I took it out
[15:18] <bac> now it is blink-to-hide
[15:19]  * danilos blinks
[15:19] <sinzui> benji, yes, I recall that. I assumed that bac was talking about a replacement implementation
[15:19] <benji> ah
[15:29] <abentley> flacoste: would it be terrible if CanonicalConfig.process_name was None when sys.argv is unavailable?
[15:36] <cjwatson> bigjools: incidentally, I've run the soyuz tests now, as expected no problems there
[15:39] <bigjools> cjwatson: excellent
[15:40] <bigjools> I wish mine would pass
[16:21] <dobey> is there any way you guys can get oops logs synced faster? like on-demand? :)
[16:22] <dobey> or on-crash as it were
[16:22] <deryck> abentley, hey…. I have to take a long lunch today to help Wendy with something shop related.  But I'll be around longer this afternoon.
[16:23] <cjwatson> bigjools: is that merge looking plausible?  sorry to rush, I just really want to get this into ec2 today if possible so that there's some chance of deploying it on Monday ...
[16:23] <abentley> deryck: okay.  I'll be taking lunch later than usual, so we may still miss :-)
[16:23] <deryck> ah, ok :)
[16:24] <bigjools> cjwatson: yeah, nearly done reviewing it
[16:25] <bigjools> cjwatson: if you want to start making changes now, you need to fix the tests to make sure all the uses of open() close the file
[16:25] <bigjools> so lots of with: :)
[16:25] <cjwatson> hm, right
[16:26] <cjwatson> can I get away with just changing the ones I was touching anyway?  it's an endemic problem in that test file
[16:28] <bigjools> yeah I see :/
[16:28] <bigjools> yeah fix those
[16:29] <bigjools> cjwatson: also, we generally use assertEqual(expected, observed) so that the matcher debug output is correct
[16:29] <cjwatson> aha, ok, I couldn't see docs of which way round it went
[16:29] <cjwatson> cool
[16:29] <bigjools> pycharm tells me :)
[16:32] <bigjools> cjwatson: let me know when you make the changes and I'll land it
[16:33] <cjwatson> ok, working on those now
[16:35] <dobey> eww
[16:35] <dobey> AttributeError: 'LaunchpadTimeoutError' object has no attribute '__traceback__'
[16:37] <bigjools> cjwatson: I need to dash, either get someone else to ec2 land it or leave me an email
[17:12] <cjwatson> I've made the changes bigjools requested to https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618; could somebody send it to ec2 land for me?
[17:43] <flacoste> abentley: no, it wouldn't be perfectly fine, it's only used to find a config file and defaults to launchpad-lazr.conf if the conf file doesn't exist
[17:43] <flacoste> abentley: i'm curious though, what can make sys.argv not available?
[17:48] <bac> hi flacoste, do you know of any work recently to make request.response.notifications hide themselves?  i'm trying to find the JS that does it but can't locate it.
[17:49] <flacoste> bac: you mean the code that allows you to dismiss notifications?
[17:49] <bac> flacoste: no, the blue box shows up but disappears after 1/2 second or so
[17:49] <bac> on its own
[17:49] <flacoste> bac: hmm, no, i'm not aware of anything that might have introduced this
[17:49] <cjwatson> bac: can I have a quick review of https://code.launchpad.net/~cjwatson/launchpad/precise-sync-testing/+merge/78646 ?
[17:49] <bac> cjwatson: sure
[17:50] <bac> flacoste: ok, maybe it is an unintended consequence of something else, like maybe the privacy notifications
[17:54] <bac> cjwatson: approved.  do you need me to land it for you?
[18:10] <cjwatson> bac: yes please (sorry for delay, was sorting out dinner)
[18:10] <bac> cjwatson: will do
[18:10] <cjwatson> bac: if you could also land https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618 (already approved by Julian) that would be marvellous
[18:10] <bac> cjwatson: man, now you're getting pushy!  :)
[18:11] <bac> cjwatson: could you please set commit messages on both merge proposals, if not done already?
[18:13] <cjwatson> already done on i18n-index, will do so on precise-sync-testing now
[18:14] <cjwatson> done; don't know if the latter needs [no-qa] or similar
[18:14] <cjwatson> or if that gets added by tools
[18:40] <bac> cjwatson: i've sent them both off to ec2.  i forgot to mark the one [no-qa] but you can tag the bug after it gets deployed to qastaging
[18:41] <bac> cjwatson: after today i'm gone for a while, so you'll have to get someone else to follow up with these branches if they don't land
[19:19] <cjwatson> bac: thanks!
[19:19] <bac> np
[19:40] <abentley> flacoste: When run under mailman, apparently.  If anything in lp_sitecustomize.py imports canonical.config, mailman starts spewing errors.  AIUI, this is expected behaviour for embedded interpreters: http://bugs.python.org/issue839151
[19:41] <flacoste> abentley: ah ok, so yes, guarding the assignment of process_name based on sys.argv is the right thing to do
[19:41] <flacoste> everything should still work if self._process_name is None
[20:00] <benji> I have an open question which is about changing the maintainer of a project.  Any hints as to how to do that?
[20:02] <lifeless> bac: flacoste: its the ajax notification support added by wallyworld
[20:02] <lifeless> bac: the first ajax request completes, has no notifications in it, and so the existing ones are nuked
[20:02] <benji> I suspect I need a registry team member.
[20:02] <flacoste> benji: click on the maintainer and select somebody else?
[20:02] <flacoste> benji: you are one
[20:03] <flacoste> by virtue of ~launchpad
[20:03] <lifeless> bac: I think I suggested in the bug, to put a X button on the notifications and have the ajax embedded notifications only ever *add* to them.
[20:03] <sinzui> benji, click on the edit icon next to the maintainer name
[20:03] <benji> flacoste: the maintainer is a link to the user's page and there isn't an edit icon for maintainer
[20:04]  * sinzui looks
[20:04] <flacoste> benji: on https://launchpad.net/launchpad-project, do you see the edit icon on the maintainer?
[20:04] <sinzui> benji, sorry. I was thinking team
[20:04] <sinzui> benji, only a LOSA can change a project maintainer
[20:05] <flacoste> or if you already the maintainer
[20:05] <flacoste> which explains why i see it on launchpad-project
[20:05] <bac> lifeless: do you know when that change landed?
[20:05] <benji> flacoste: I do there but not on https://launchpad.net/fusionforge
[20:05] <flacoste> yep, what sinzui says: ask a losa
[20:05] <lifeless> bac: end of the recipes project
[20:05] <benji> sinzui: awesome, thanks
[20:06] <lifeless> bac: they were doing ajax build queueing or something like that and needed to show a warning / notification as a result of the call
[20:06] <bac> lifeless: so that was a good while ago
[20:06] <lifeless> yes; we have a deluge of bugs ;)
[20:07] <bac> lifeless: i've been going through our JS code but cannot find the relevant code.
[20:07] <lifeless> bac: wallyworld__ tried to fix it at the time, and I think he did, but something unfixed it shortly after and we didn't notice immediately
[20:07] <lifeless> bac: huh.
[20:07] <bac> there is a section in client.js that deals with notifications
[20:08] <sinzui> benji, I do not know why I advised you badly the first time. I was thinking a few hours earlier that If I could temporarily change project maintainer, I could fix 777 licenses
[20:08] <benji> sinzui: heh :)
[20:08] <lifeless> bac: rev 12779
[20:09] <bac> lifeless: thanks!
[20:09] <lifeless> bac: is the most recent thing - I remember now. wallyworld__ made it so that choosing to reset the notifications is explicit (rather than them always resetting)
[20:09] <bac> wow, april
[20:10] <lifeless> bac: this implies that the reset that is happening is explicit (and wrong) - it may be right other times, which means we have an unreconcilable situation and will need to find some way to cut the knot
[20:10] <lifeless> bac: I found it by doing bzr log and looking for 'notification' until I saw one that looked relevant ;)
[20:25] <sinzui> statement_timeout I should use when suggesting queries to in production? 2 seconds
[20:30] <lifeless> yes
[20:30] <lifeless> 2000 ms
[20:36] <sinzui> thank
[20:37] <sinzui> s
[20:37] <lifeless> n
[20:37] <lifeless> o probs
[20:37] <lifeless> I'm reminded of captain kirks speech patterns
[20:37] <sinzui> :)
[20:42] <timrc> sinzui, Did cody-somerville point you at our automated PPA creation code yet?
[20:42] <cody-somerville> timrc, No.
[20:43] <timrc> :(
[20:44] <lifeless> flacoste: bug 757298 - I've just commented - it was critical by inheritance
[20:44] <_mup_> Bug #757298: database bloat report ordering needs tuning <critical-analysis> <qa-ok> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/757298 >
[20:45] <flacoste> lifeless: ack
[20:46] <lifeless> flacoste: I've commented to that effect (via email so not there yet) but not changed the status
[20:46] <lifeless> flacoste: I think it could go either way
[20:46] <flacoste> lifeless: i'll change the status (and the category in my analysis) if I'm swayed by your argument :-)
[20:47] <lifeless> flacoste: :)
[20:47] <lifeless> flacoste: so the argument is that index bloat had caused timeout storms twice already by april
[20:47] <lifeless> flacoste: and that the report helps us get on top of it earlier
[20:48] <flacoste> that's fair
[20:54] <sinzui> lifeless, I wanted to run this in production, but it timesout under cold cache: http://pastebin.ubuntu.com/704176/ Do you have thoughts about making this faster? Should I take the extra pain of writing a garbo job, land, released, revert?
[20:54] <lifeless> garbo please
[20:54] <sinzui> okay
[20:54] <lifeless> or
[20:55] <lifeless> and this is a little radical
[20:55] <lifeless> could an API script do it ?
[20:55] <lifeless> sinzui: the second half - the 77 rows - that should be totally fine on prod
[20:55] <sinzui> well interesting proposal. I the the first part that is fine under cold cache is doable over api
[20:56] <sinzui> I do not think the second part that is slow is doable. But I have yet to think about all the cases that those 77 packages are missing
[20:56] <lifeless> sinzui: ah I see your times in -ops
[20:56] <lifeless> sinzui: your methodology has a hole in it :)
[20:56] <sinzui> yep
[20:57] <lifeless> sinzui: try this: set the statement timeout to 15 seconds; run the *select clauses only* for both queries outside a transaction; set the statement timeout to 2000; BEGIN; do the INSERT queries; ROLLBACK;
[20:58] <sinzui> ah, build a hot cache
[20:58] <lifeless> we care about the duration of locks, not the overall load [well we care about both, but you see what I mean]
[20:58] <sinzui> I do
[20:59] <lifeless> there is some overhead you can't pre-load when inserting into the table, because indices have to be updated (which means reading them in)
[20:59] <lifeless> so to test this a second time, use a different slave
[20:59] <lifeless> as long as we rollback, testing something like this on a slave is fine
[21:00] <sinzui> okay thank is very helpful to know
[21:34] <lifeless> sinzui: another strategy is to run the exact query in a loop with rollback and low timeout until it works
[21:35] <lifeless> we'll release any locks every (say) 1 second [the timeout] and thus won't cause timeouts
[21:48] <flacoste> lifeless: should yuo be assigned to bug 788518?
[21:48] <_mup_> Bug #788518: staging services share OOPS prefix <Launchpad itself:Triaged> < https://launchpad.net/bugs/788518 >
[21:48] <flacoste> lifeless: as your current work will fix this
[21:50] <lifeless> flacoste: it won't really; it will just mean we get the reports.
[21:51] <lifeless> flacoste: we will still want to identify each script properly, which means a different set of work to auto-assign reports for scripts by the script name
[21:51] <lifeless> flacoste: which my work will enable but not itself do.
[21:51] <flacoste> ok
[21:51] <lifeless> flacoste: I may, later, do that
[21:51] <flacoste> but the fact that we get the report means that the priorit drop at least
[21:51] <lifeless> yes, I agree - once my work lands :)
[21:53] <flacoste> lifeless: well, now it's on your radar ;-)
[21:54] <cjwatson> hmm.  lp:~cjwatson/launchpad/i18n-index failed EC2.  The end of the log goes:
[21:54] <cjwatson> successful: lp.archivepublisher.tests.test_publisher.TestPublisher.testReleaseFile
[21:54] <cjwatson> WARNING: A test appears to be hung. There has been no output for 600 seconds.
[21:55] <cjwatson> but I've run the next test along locally (testReleaseFileForPPA) and it succeeds - can anyone suggest a possible gotcha I might be running into?
[22:01] <lifeless> might be a later transition, or a layer test teardown - they run after tests complete
[22:01] <lifeless> (also layers are evil, this is one of the data points for why)
[22:50] <wgrant> sinzui: I think we are nearly getting somewhere!
[22:52] <wgrant> cjwatson: Could you forward me the output?
[22:53] <wgrant> cjwatson: Is it possibly the apt-ftparchive hang in mvo1? I don't think the ec2 images have mvo2.
[22:54] <wgrant> But I'm not sure if you've changed the test to actually exhibit the hang...
[22:55] <cjwatson> I think the test is testReleaseFileForPPA, which would not be a-f
[22:55] <wgrant> testReleaseFileForI18n will probably hang.
[22:56] <wgrant> It sets include_long_descriptions = False, and then calls a-f.
[22:56] <cjwatson> forwarded to you
[22:56] <wgrant> Thanks.
[22:56] <cjwatson> oh
[22:56] <cjwatson> that would indeed be next alphabetically
[22:56] <cjwatson> yep, in a local run it's
[22:56] <cjwatson> successful: lp.archivepublisher.tests.test_publisher.TestPublisher.testReleaseFile
[22:57] <cjwatson> test: lp.archivepublisher.tests.test_publisher.TestPublisher.testReleaseFileForI18n
[22:57] <wgrant> Great.
[22:57] <cjwatson> so this is artificial and we need to get ec2 images upgraded
[22:57] <wgrant> I'll get the fixed version onto buildbot while we have a LOSA, and sort of buildbot images today.
[22:57] <cjwatson> thanks; does that indicate bypassing ec2 then, or do you want to upgrade the ec2 images too?
[22:58] <wgrant> Er.
[22:58] <wgrant> s/sort of buildbot/sort out ec2/
[23:03] <cjwatson> aha
[23:04] <wgrant> We're in a fairly good position QA-wise, so as long as I can get buildbot sorted out before thedac disappears, we should be able to deploy this at 0830 on Monday :)
[23:05] <cjwatson> Awesome
[23:05] <cjwatson> That will make my next week suck a bit less
[23:05] <wgrant> That's the hope.
[23:09] <wgrant> KeyboardInterrupt lp.archivepublisher.tests.test_publisher.TestPublisher.testReleaseFileForI18n
[23:09]  * wgrant upgrades apt-utils to lucid-proposed
[23:11] <wgrant>   Ran 30 tests with 0 failures and 0 errors in 27.679 seconds.
[23:11] <wgrant> Success.


[15:29] <scott_ev> sorry my extremely minor contgribution came so late:  I was in bed all weekend
[18:02]  * PaulW2U calls it a day with about 10 summaries to go - unplugs laptop and throws it out of the window :(


[04:55]  * SpamapS_ just made his first real upload.. :-D
[04:59] <TheMuso`> SpamapS: Awesome!
[05:08] <c2tarun> is there any tutorial available for how to create a plugin for any application?
[05:12] <TheMuso`> c2tarun: It depends on the application, and whether that application supports plugins.
[05:12] <c2tarun> TheMuso`: its kontact.
[05:12] <TheMuso`> c2tarun: Then you will have to find the developer documentation to look up the plugin API.
[05:13] <c2tarun> TheMuso`: actually I am trying to look into this http://community.kde.org/GSoC/2011/Ideas#Project:_VOIP_Plugin_for_Kontact I thought to do my side research first, but failed to find on google how to create a plugin
[05:14] <c2tarun> isn't there any basic steps for writing a plugin? :/
[05:14] <RAOF> c2tarun: It's entirely application-specific; there's no guarantee that kontact even supports plugins.
[05:15] <RAOF> (Although the GSoC idea suggests that it does ☺)
[05:15] <c2tarun> RAOF: yup. ok, so I'll ask in #kontact channel then :)
[05:15] <c2tarun> anyone here is participating in GSoC?
[05:15] <c2tarun> not as mentor.
[07:30] <dholbach> good morning
[07:51] <didrocks> good morning
[08:17] <pitti> Good morning
[09:03] <abhinav-> dholbach, thanks for your email reply :)
[09:03] <dholbach> abhinav-, sure :)
[09:07] <janimo> Riddell, hi, do you have a recent package example that used cmake and hardcoded /usr/lib/ paths that needs to be fixed for multiarch?I remember you mentioning something like this a while ago
[09:08] <janimo> there's a FTBFS  which may be caused by something similar https://launchpadlibrarian.net/67912682/buildlog_ubuntu-natty-armel.igstk_4.2.0-4_FAILEDTOBUILD.txt.gz
[09:14] <ohsix> hm
[09:14] <ohsix> seeing lots of 404s on changelogs in aptitude lately, did something change?
[10:14] <Riddell> janimo: cmake should be fixed to know to look in the multiarch directories
[10:15] <janimo> Riddell, so you only worked around that in a specific package? Is the cmake fix in progress?
[10:15] <janimo> is this affecting Kubuntu packages?
[10:16] <Riddell> janimo: cmake itself should be fixed with the debian/patches/ubuntu_multiarch_library_directory.diff patch
[10:48] <YokoZar> If a dummy package is removed entirely do we need to conflict/break it or can we just let it rot?  Will update manager remove dummy packages that no longer exist in the archive?
[10:52] <YokoZar> Nevermind, answered my own question:    "If a package is completely replaced in this way, so that dpkg does not know of any files it still contains, it is considered to have "disappeared".  It will be marked as not wanted on the system (selected for removal) and not installed.  Any conffiles details noted for the package will be ignored, as they will have been taken over by the overwriting package."
[10:52] <cjwatson_> in practice this never happens because there's always /usr/share/doc/$packagename/
[10:52] <cjwatson> or more or less never
[10:53] <YokoZar> hmm, that seems wrong somehow
[10:53] <cjwatson> I would declare Breaks anyway.  It's cheap.
[10:54] <cjwatson> actually, no, you want to get rid of the old package completely, don't you?  Conflicts+Replaces sounds appropriate
[10:55] <janimo> co
[10:55] <cjwatson> update-manager is useful for many things, but you shouldn't assume everyone is using it unless you have no other choice
[10:55] <cjwatson> (of course, presumably an old dummy package hanging around isn't actually going to do any harm, so use your judgement there)
[10:56] <YokoZar> Why not breaks/replaces?
[10:56] <Laney> breaks doesn't enforce removal
[10:56] <YokoZar> just deconfigure
[10:57] <Laney> you can still have the files unpacked
[10:57] <Laney> right
[11:00] <YokoZar> Will these conflict lines do bad things if I define a new virtual package by the same name as the dummy package?
[11:01] <YokoZar> I think that was my original intuition for wanting to use breaks
[11:01] <cjwatson> if you plan to do that, use versioned Conflicts
[11:01] <YokoZar> ahh, the one real use for versioned conflicts, makes sense
[11:02] <cjwatson> right
[11:02] <Laney> note that provides will only help for unversioned depends (if that's indeed what you are trying to take care of)
[11:11] <OdyX`> ScottK2: Aye. Bugs were filed. apiextractor: #748331 generatorrunner: #748333, shiboken: #748334 and pyside got renamed: #740177
[11:22] <Chipzz_> whoa, freenode is unstable today
[12:28] <chrisccoulson> @pilot in
[13:15] <nobuto> chrisccoulson: Could you review my debdiff on Bug #746538?
[13:15] <chrisccoulson> nobuto, sure
[13:15] <chrisccoulson> oh, it's for ubufox
[13:15] <chrisccoulson> heh, we seem to be carrying a monster patchset for that now
[13:16] <chrisccoulson> i should fork it ;)
[13:41] <UBuxuBU> can i have a ubuntu page on my website?
[13:43] <mterry> superm1, heyo, would you mind having a mythbuntu person look at https://code.launchpad.net/~mterry/ubuntu-seeds/mythbuntu.natty-gnome-system-tools/+merge/53423 ?  thanks
[13:46] <Daviey> mterry, Have you tested it?
[13:47] <mterry> Daviey, no?  it seemed straightforward.  But other flavors have used similar changes, so I believe it's safe
[13:53] <Daviey> mterry, Great, I see xubuntu has adopted it.. fine with me, merged.
[13:53] <Daviey> thanks for spotting it.
[13:53] <mterry> Daviey, I did the package split, so I felt obliged  :)
[13:54] <Daviey> heh
[14:02] <mterry> slangasek, are you on "archive admin" duty today?  I have a sync I'd love to see happen: bug 746448
[14:03]  * mterry isn't sure why he put archive admin in quotes  :)
[14:05] <cjwatson> mterry: I'll do a sync pass now
[14:05] <mterry> cjwatson, thanks!
[14:06] <mterry> cjwatson, note that that particular bug requires 3 syncs
[14:06] <cjwatson> if ubuntu-archive is subscribed to it, then I'll pick it up
[14:10] <mterry> cjwatson, well, they are all in the same bug.  perhaps I should have filed 3 separate ones?, but the other 2 are only needed to support new pylint
[14:10] <hallyn> skaet_: good morning - please let me know if there is anything else you need from me on bug 727342.  (As I say it tests well for me)
[14:10] <ScottK> OdyX: All approved now.  Should get sync'ed soon.  Thanks.
[14:10] <OdyX> ScottK: niiice. Thanks.
[14:14] <cjwatson> mterry: it's fine the way it is.
[14:30] <nobuto> chrisccoulson: Thanks for uploading!
[14:47] <OdyX> ScottK: Would pyside-tools (currently in unstable, got out of Debian:NEW recently) be considerable ? It's only new functionality, but pretty much needed for correct PySide operation ?
[14:47] <ScottK> OdyX: Yes, but it will need an FFe.
[14:47] <ScottK> Please file the sync request as an FFe request and I'll review it.
[14:48] <OdyX> ScottK: doing that now
[14:56] <OdyX> ScottK: https://bugs.launchpad.net/ubuntu/+bug/750295
[14:58] <ScottK> OdyX: Just approved it.  It should at least get to Ubuntu New on the next round of syncs.
[14:58] <OdyX> Nice.
[15:05] <skaet> hallyn,   have gone in and approved it.   Thanks for getting this fixed.
[15:10] <pitti> jdstrand, kees: releasing lucid kernels to -security/-updates: linux linux-backports-modules-2.6.24 linux-meta linux-restricted-modules-2.6.24 linux-ubuntu-modules-2.6.24
[15:11] <jonny> cjwatson: Is https://wiki.ubuntu.com/SeedManagement#CD%20builds still accurate? It doesn't look to have been update since there was a unified live/install CD. I've been hunting around to find the list of packages one expects on a Live CD - is there a better way than looking at filesystem.manifest (or filesystem.manifest-desktop) on the CD? For example a way that doesn't require I get the CD?
[15:17] <cjwatson> jonny: it looks fairly close to me, if you s/install/alternate/ and s/live/desktop/
[15:17] <cjwatson> jonny: you can look at the .manifest and .list files alongside the CD on cdimage.u.c
[15:20] <cjwatson> I've updated that documentation a bit - there's no point in it listing lots of seed names that are already in the STRUCTURE dependencies
[15:24] <jonny> cjwatson: thanks. Is there some documentation somewhere about how the livecd is build - this is curiosity speaking now :) - As I understand it, Germinate spits out a bunch of potentially intersecting lists of packages, is there a tool beyond apt that reconciles those and makes the cd inside a chroot or something?
[15:24] <jonny> *s/build/built ^
[15:26] <cjwatson> jonny: livecd-rootfs builds the live filesystem
[15:27] <cjwatson> https://code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline (plus the submodules in configs/devel) does the rest of it
[15:27] <cjwatson> hm, let me fix the mirroring there
[15:30] <cjwatson> well, it should sort itself out in a bit
[15:48] <superm1> Daviey, can you regenerate that meta package and upload too?
[15:58] <YokoZar> is there an easy way to tell why apt wants to remove something on dist-upgrade?
[15:58] <ohsix> use aptitude? :D
[16:00] <YokoZar> ohsix: welp, aptitude wants to do something different from apt-get
[16:03] <ohsix> shrug
[16:03] <ohsix> at least aptitude lets you investigate its upgrade solution
[16:03] <ogra_> ugh, aptitude
[16:04] <juliank> YokoZar: There are debugging switchs to see this
[16:04] <YokoZar> yeah that was my thought
[16:04] <Daviey> superm1, ack, i wanted to check there wasn't anything else before doing so.
[16:05] <juliank> YokoZar: Try -o pkgProblemResolver=true
[16:05] <juliank> YokoZar: "-o Debug::pkgProblemResolver=true"
[16:07] <juliank> But it can be very verbose
[16:07] <YokoZar> juliank: $ sudo apt-get -o Debug:pkgProblemResolver=true dist-upgrade ?
[16:07] <juliank> YokoZar: yes
[16:07] <YokoZar> hmm doesn't seem to be changing the output up to the prompt...
[16:08] <YokoZar> (the do you want to continue prompt)
[16:11] <juliank> YokoZar: Try apt-get dist-upgrade -o Debug::pkgProblemResolver=1
[16:12] <juliank> YokoZar: You just missed a colon, it seems
[16:13] <YokoZar> yeah
[16:13] <YokoZar> now if I can make sense of this output...
[16:14] <juliank> YokoZar: you could put it on a paste bin and tell me what you're looking for
[16:15] <juliank> http://paste.ubuntu.com/
[16:16] <YokoZar> ahh I think I figured it out, obsolete version of a pacakge in an enabled PPA that was the same version as the fixed package I installed locally.  Apt wants to upgrade from dpkg -i installed package to one available on PPA, which in this case means getting the broken one.
[16:16] <YokoZar> which had the side effect of trying to remove a fixed package that was also fixed in the ppa
[16:18] <juliank> YokoZar: If needed, you can use pinning to overwrite this
[16:19] <YokoZar> Yup.  Thanks juliank
[16:25] <SpamapS> jhunt_: about the sendsigs killing OMITPIDS .. this seems somewhat broken.. I think the appropriate thing to do is to only care about processes with a goal of stop/ .. since the point of having no 'stop on' is that you run "forever" is it not?
[16:26] <SpamapS> jhunt_: so whynot just replace that kill with a loop to stop all remaining jobs except rc?
[16:36] <jhunt_> SpamapS: seems reasonable - that script just kinda "feels" too complex right now.
[16:36] <jhunt_> I'm interested in the "vanilla upstart approach" too as it would be
[16:36] <jhunt_> nice to keep separation between Upstart and SysV jobs (Upstart shouldn't
[16:36] <jhunt_> need SyV)
[16:36] <jhunt_> s/SyV/SysV
[16:37] <jhunt_> We might need Keybuks thoughts on the preferred method for that one though.
[16:54]  * YokoZar just vastly simplified some package rules files thanks to debhelper 7.
[16:54] <smoser> jhunt_, can you verify for me that upstart doesn't care if a file is dos format ?
[16:55] <smoser> i have to fix something in cloud-init when input is  dos format, i have to fix user scripts ("#!/bin/sh\r\n" -> "#!/bin/sh\n" ...)
[16:55] <smoser> i'd like your statement as to whether or not i should do that for upstart jobs
[16:58] <ion> It makes no sense to use \r\n in anything unixish.
[16:59] <cjwatson> ion: except for TCP/IP protocols
[16:59] <cjwatson> but yeah, files?  \n
[16:59] <smoser> agreed. but user input is from windows, and i would like to not change their content except when required.
[16:59] <smoser> because arbitrarily "fixing" things will break checksums that they might have calculated.
[17:01] <cjwatson> I'm fairly sure upstart/libnih treats \r like \n
[17:01] <smoser> at least that is why i wasn't going to change everything.
[17:02] <smoser> ie, if you did a wget of a file, you wouldn't want wget to change its content.
[17:05] <slangasek> mterry: sync> ack
[17:05] <mterry> slangasek, cjwatson grabbed it for me, but thanks
[17:09] <slangasek> mterry: ok, cool :)
[17:31] <SpamapS> jhunt_: I wonder if we can complete the transition to an upstart-only shutdown in oneiric.
[17:37] <jhunt_> SpamapS: would be good! I've added it to the wishlist: https://wiki.ubuntu.com/FoundationsTeam/OneiricPlanning#Ideas
[17:45] <SpamapS> jhunt_: so another thing I was wondering is whether we can implement grouping in upstart jobs. If we could say   initctl --exclude-group shutdown stop-all   .. and let upstart do this internally.. that gives us a very clean way to terminate everything
[17:47] <SpamapS> jhunt_: the problem with "disable spawning" is that you may need to spawn a few processes to shutdown cleanly.
[18:12] <bryceh> @pilot on
[18:12] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[18:12] <bryceh> @pilot in
[18:12] <bryceh> @pilot in
[18:35] <mterry> TheMuso, so ldtp and pyatspi2 don't get along packaging-wise (ldtp depends on pyatspi1 currently).  Is that just a packaging bug or is ldtp not compatible with atspi2?
[18:47] <tgardner> cjwatson, I'm thinking vga=788 isn't gonna work so well on bare metal. see bug #745947
[18:50] <akheron> bug #660483, what should I do now?
[18:51] <akheron> I've proposed a patch
[18:56] <bryceh> akheron, I'll take a look
[18:56] <bryceh> akheron, can you also add to the changelog the bug number that your patch fixes
[18:56] <bryceh> i.e.
[18:56] <bryceh> +  * Don't link to system's jquery.js, as it's too old (LP: #660483)
[18:58] <bryceh> akheron, sometimes I also like to mention the error message that goes away with the fix (so people with the problem can verify that this patch fixes it).  Totally not necessary though.
[18:59] <bryceh> akheron, if you post an update ping me and I can upload it for you, the change itself (removing the link) looks fine
[19:00] <akheron> bryceh: ok
[19:02] <cjwatson> tgardner: seems odd because that was actually a change inherited from Debian
[19:02] <tgardner> cjwatson, well, I've got it repro'd on at least one server.
[19:02] <cjwatson> tgardner: wait, is this a recent regression?
[19:03] <cjwatson> tgardner: they said it was fine in the alphas, and those used vga=788 too
[19:03] <tgardner> I wonder if it has to do with modularizing CONFIG_FB_VESA
[19:03] <cjwatson> I bet that we forgot to put vesafb in a udeb
[19:03] <tgardner> cjwatson, hmm, lemme check.
[19:03] <cjwatson> the installer has code to load it if it can
[19:03] <tgardner> actually, I'm sure of it
[19:04] <cjwatson> hm, it's in fb-modules
[19:04] <cjwatson> -rw-r--r-- root/root     14288 2011-04-01 00:11 ./lib/modules/2.6.38-8-generic/kernel/drivers/video/vesafb.ko
[19:04] <cjwatson> mind you, d-i is still on -7
[19:04] <tgardner> cjwatson, and in modules/fb-modules:vesafb
[19:05] <cjwatson> yeah
[19:05] <cjwatson> does it actually work when modularised, at the moment? :)
[19:06] <cjwatson> fb-modules is in the initrs
[19:06] <cjwatson> initrds
[19:07] <tgardner> cjwatson, dunno. I've been reading the stuff in Documentation/fb/fbcon.txt. it says if you specify vga= , then fbcon isn't loaded (which kind of looks like what is happening)
[19:07] <cjwatson> d-i explicitly loads fbcon
[19:08] <tgardner> cjwatson, I'm not nearly as familiar enough with this frame buffer stuff and early boot.
[19:09] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/rootskel/ubuntu/view/head:/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86
[19:12] <cjwatson> tgardner: you can add BOOT_DEBUG=3 and drive stuff by hand, FWIW
[19:12] <cjwatson> that gives you a shell at the start of /init
[19:13] <tgardner> cjwatson, ok, gimme a minute. this is easily reproducible using VMware
[19:14] <cjwatson> the execution flow is then the stuff in /init, then /sbin/debian-installer-startup, then /sbin/debian-installer
[19:14] <cjwatson> (but you shouldn't need the last bit)
[19:14] <cjwatson> it's nearly all shell, fairly easy to pick apart and run step by step
[19:14] <cjwatson> kvm doesn't show it (either default or -vga std)
[19:15] <tgardner> cjwatson, agreed, kvm was the first thing I tried.
[19:16] <tgardner> cjwatson, BOOT_DEBUG=3 on the syslinux command line, right?
[19:16] <cjwatson> yeah
[19:16] <tgardner> no joy
[19:16] <akheron> bryceh: ping, I added an updated patch
[19:17] <bryceh> akheron, thanks
[19:17] <cjwatson> tgardner: what variety of absence of joy?
[19:18] <cjwatson> oh, hm
[19:18] <cjwatson> you can type 'modprobe vesafb' blind
[19:18] <tgardner> cjwatson, a total absense of joy with vga=788 (e.g. no display whatsoever). I verified that BOOT_DEBUG=3 works without vga=788/
[19:19] <cjwatson> tgardner: that total absence of joy may be fixed by typing 'modprobe vesafb'?
[19:19] <cjwatson> fbcon is non-modular
[19:19] <cjwatson> is there a particular way to tell it to attach to a new fb, or is it just supposed to notice?
[19:20] <cjwatson> I'm open to the option of deleting vga=788 BTW, I just want to try as hard as possible not to since it really makes the installer a lot more pleasant
[19:20] <cjwatson> and actually, we used vga=788 in maverick
[19:20] <cjwatson> it's not a new thing in natty
[19:21] <tgardner> cjwatson, so if I blindly type 'modprob vesafb' then I get a console with BOOT_DEBUG=3. so, its definitely related to the modularization of VESAFB
[19:22] <bryceh> akheron, looks good, upload sponsored
[19:23] <akheron> bryceh: thanks
[19:23] <akheron> my first upload :)
[19:23] <bryceh> akheron, well then congrats :-)
[19:23] <cjwatson> tgardner: aha, so then the question is what happened to the existing code to run that
[19:25] <tgardner> cjwatson, at the point that the boot debug breaks, /proc isn't mounted.
[19:25] <cjwatson> indeed
[19:25] <cjwatson> cat /init
[19:25] <bryceh> akheron, for reference, in the future when you have patches to sponsor you can check the topic of this channel to see if someone is listed as Patch Pilot on duty, and if so give them a holler, and they'll help you get stuff uploaded
[19:25] <cjwatson> it's mounted right after that debug shell
[19:25] <akheron> bryceh: ok
[19:25] <tgardner> cjwatson, ok, that looks fine.
[19:26] <akheron> bryceh: I actually once worked on a new package, but fixing existing packages seems to be way easier :)
[19:26] <akheron> what comes to get the upload sponsored
[19:26] <akheron> *getting
[19:27] <cjwatson> tgardner: what does 'readlink /proc/self/fd/0' say, after you mount /proc?
[19:27] <tumbleweed> we are much more forgiving of lack of perfection in existing packages :)
[19:28] <tgardner> cjwatson, I exited busybox once to let init run, so /proc is now mounted, readlink /proc/self/fd/0 == /dev/console.
[19:28] <bryceh> akheron, 'upload sponsored' means your patch has been added to the ubuntu repository and will be live to natty users once the package has finished rebuilding (typically a couple hours, depends on the package and build server loads)
[19:29] <akheron> bryceh: yeah
[19:29] <akheron> bryceh: but this fix was actually targeted to the lucid backport only
[19:29] <bryceh> akheron, in this case since your patch is against lucid, it will also need to go through a review step
[19:29] <akheron> ah, ok
[19:29] <bryceh> subject: [ubuntu/lucid-backports] couchdb 1.0.1-0ubuntu3~lucid2 (Waiting for approval)
[19:30] <cjwatson> tgardner: hm, not quite the right test, one moment while I experiment
[19:30] <bryceh> I'm not sure how frequently lucid-backports gets reviewed though... could take anywhere from a few hours/days to maybe weeks
[19:30] <akheron> is there a backports team or such that does the approving?
[19:30] <bryceh> yes
[19:31] <akheron> ok, sounds good
[19:31] <akheron> and I'm not in that big a hurry, a few days is fine :)
[19:32] <bryceh> akheron, I'm not sure exactly who is on the team, but https://help.ubuntu.com/community/UbuntuBackports has some more information
[19:32] <cjwatson> tgardner: ok, reboot; in the first debug shell, 'modprobe vesafb; echo sh >/lib/debian-installer.d/S00sh' (no need to make it executable); exit twice; 'readlink /proc/self/fd/0'
[19:32] <cjwatson> in kvm, that gives me /dev/tty0
[19:32] <tgardner> cjwatson, ok, one sec while I get there
[19:34] <tgardner> cjwatson, readlink /proc/self/fd/0 == /dev/console
[19:35] <m4n1sh> pitti: send the brainstorm final mail to technical-board list. It might be in the moderation queue
[19:37] <cjwatson> tgardner: hm, so d-i's assumption is that that means serial
[19:37] <cjwatson> tgardner: is there a free vmware download that exhibits this, do you know?
[19:37] <tgardner> cjwatson, you can use it as an eval for 30 days AFAIK
[19:38] <cjwatson> ok, will just workstation do, do you think?
[19:38] <tgardner> cjwatson, yep, I'm using 7.1.4
[19:38] <cjwatson> ok, I can queue it up to give it a try, unless you want to continue
[19:39] <cjwatson> IIRC there is some weird interaction with stdin and the console in the depths of busybox init
[19:40] <tgardner> cjwatson, well, what would you like to try next? remember, I can get this on bare metal (buts a huge pain 'cause the server takes 3 minutes to boot)
[19:40] <tgardner> cjwatson, I could always de-modularize VESAFB for the -server flavour, but that seems like a hack.
[19:41] <cjwatson> I think what I ideally want is a set -x trace of debian-installer-startup, to see why it apparently isn't loading vesafb
[19:41] <cjwatson> there's a lot of blind typing involved there though
[19:42] <tgardner> cjwatson, ok, perhaps I'll let you handle it, ok?
[19:42] <cjwatson> after that ... not sure, might involve building a debug busybox init?
[19:42] <cjwatson> I'm happy to have a crack at it, although I do already have about a week's worth of work queued up that's beta-2-critical
[19:42] <cjwatson> but I guess we have an understood fallback option
[19:43] <tgardner> I'll dribble some notes in the bug report.
[19:43] <cjwatson> thanks - I'll give you a shout if it's looking impossible for me
[19:51] <tgardner> cjwatson, I'm sure you don't get enough email, so I've subscribed you to bug #745947. I'm sure this'll come up on skaet's radar pretty soon.
[19:52]  * tgardner --> lunch
[19:53] <cjwatson> ta
[19:58] <vish> SpamapS: hi, i think you also have to comment asking people to test the -proposed.. pitti uses a reply template for SRUs; otherwise people wont know how they have to test it.. (noticed it on the compiz bug)
[20:00] <vish> or was that the initial ACK? (/me confused, normally used to seeing pitti do those :D )
[20:01] <micahg> vish: that happens when it's accepted I believe
[20:01] <vish> ok, seems something new.. i blame pitt-i ! ;p
[20:02] <micahg> vish: or rather, when review/accepted at the same time, that notice is used since the package is building, it's hard to post it before it's actually accepted since you don't know when the package will build
[20:02] <vish> ahhh! its still building
[20:05] <SpamapS> vish: I do not have the ability to accept the package into -proposed yet, as pitti is still training me, so he will see that message and accept it.
[20:06] <SpamapS> I'd make a template, but I'm hoping we'll finish with the training-wheels soon and I can just use his template.
[20:06] <vish> SpamapS: cool, thanks! dint know that.. :) (thought you approved it)
[20:29] <SpamapS> vish: well I "approve" it, but Pitti pulls the big red handle to make it actually go. :)
[20:29] <vish> righto, i meant accepted :)
[20:30] <sladen> ivanka-train: cunning.  how did you manage that?
[20:31] <ivanka-train> sladen: which bit?
[20:31] <sladen> ivanka-train: not dropping IRC while transitioining?
[20:31] <ivanka-train> sladen: skillz
[20:32] <ivanka-train> sladen: it will drop - but network manager handles the tunnels rather well without throwing its toys out
[21:09] <hallyn> I pushed a package to lucid-proposed.  Where do I go to track whether I properly caused a package build?
[21:10] <micahg> hallyn: was it accepted yet?

[21:10] <hallyn> how do I tell? :)
[21:10] <micahg> hallyn: you can look at launchpad.net/ubuntu/+source/foo to see about any package in the archive
[21:10] <tgardner> hallyn, https://launchpad.net/ubuntu/lucid/+queue
[21:10] <hallyn> (sorry, by 'pushed' i meant 'bzr push', not dput)
[21:11] <hallyn> ok, thanks, lemme check those
[21:11] <micahg> hallyn: ah, that's different :)
[21:11] <micahg> hallyn: you should be able to do bzr lp-open in the dir I think
[21:12] <hallyn> hm, i don't think i did it right
[21:14] <micahg> hallyn: which package?
[21:14] <hallyn> lp:ubuntu/lucid-proposed/qemu-kvm
[21:14] <hallyn> it did update in bzr
[21:15] <hallyn> but from the bzr source page i don't see how to go to package builds
[21:15] <micahg> hallyn: that doesn't work yet
[21:15] <micahg> hallyn: you can to create a source package like normal from the bzr branch and upload
[21:21] <hallyn> micahg: doh.  are you saying that only doesn't work for -proposed?
[21:21] <hallyn> or for anything?
[21:21] <micahg> hallyn: you can't build from branch unless it's a source recipe for a PPA
[21:22] <micahg> AFAIK
[21:22] <hallyn> micahg: good to know.  i didn't know that :)
[21:22] <micahg> hallyn: once you push the bzr branch, you can have to still use bzr-builddeb to create a source package
[21:22] <hallyn> thanks, will just dput then
[21:22] <hallyn> well do, thx
[21:22] <hallyn> (was just trying to be as UDD as possible :)
[21:48] <hallyn> slangasek: so i did a bzr push to lp:ubuntu/lucid-proposed/qemu-kvm, thinking (wrongly) that would kick a build.  Now I can't dput the src package from the same tree bc it sees it already there.  Should I bzr uncommit and push --force?  Is there something better to do?
[21:48] <slangasek> hallyn: I don't understand what you mean, "it sees it already there".  Can you paste me the error?
[21:49] <hallyn> it rejected in email, i can fwd that
[21:49] <slangasek> yes please
[22:17] <slangasek> hallyn: so the reason for the reject is that the 0.12.3+noroms-0ubuntu9.4 *version* already exists; it appears to have been a security update, so it was never uploaded to lucid-proposed
[22:17] <slangasek> hallyn: you'll want to untag your version from the lucid-proposed branch, merge in the version from lucid-updates/lucid-security, and re-push your changes on top
[22:17] <hallyn> slangasek: d'oh, but that's not in lucid yet either right?
[22:18] <hallyn> (i checked the bzr tree and didn't see it there)
[22:18] <slangasek> hallyn: the "lucid" bzr branch is never updated after the release
[22:19] <hallyn> ah
[22:19] <slangasek> so this is only in the updates and security branches
[22:19] <hallyn> even with an SRU?
[22:19] <slangasek> yes
[22:19] <slangasek> SRUs are published in -updates
[22:19] <hallyn> oh!
[22:19] <hallyn> got it
[22:19] <hallyn> slangasek: thanks much.  i think it's clear to me now
[22:19] <slangasek> sure thing :)
[23:13] <bryceh> @pilot out
[23:14] <hallyn> slangasek: yay, upload worked.  (now just waiting for approval)
[23:31] <Keybuk> jono: hey
[23:38] <jono> hey Keybuk
[23:38] <jono> hows tricks?
[23:38] <Keybuk> good thanks, you?
[23:41] <poolie> hi keybuk
[23:41] <poolie> RAOF_, hi, can you have a look at bug 749817 for me?
[23:41] <poolie> is there anything i can do to help move it along?
[23:51] <penguin42> poolie: You might like to attach the output of intel_reg_dumper from the intel-gpu-tools package in both the normal and broken states
[23:52] <poolie> ok, thanks
[23:52] <penguin42> I also wonder, shouldn't that be against xserver-xorg-intel or whatever the correct intel specific name is?
[23:53] <RAOF_> penguin42: No, we like X bugs to be filed against xorg.
[23:53] <penguin42> RAOF_: Oh ok, didn't know that - I'd moved a few to the specific ones in the past
[23:53] <Keybuk> jono: but in answer to your tweet, no
[23:53] <Keybuk> I'm not attending LF Collab this week
[23:54] <RAOF_> penguin42: No, that's generally right.  We just encourage people to *file* bugs against xorg, where we can dispatch them appropriately.
[23:54] <penguin42> ok
[23:57] <jono> Keybuk, np