[01:56]  * wallyworld_ off to a funeral. back later today
[01:57] <lifeless> :(
[01:59] <wallyworld_> yeah. sad.
[02:17] <lifeless> \o/ deleting code
[02:21] <wgrant> lifeless: Oh?
[02:25] <lifeless> getBugCounts
[02:25] <lifeless> unused
[02:25] <lifeless> and getBugContextWhereSQLClause too, or however it was spelt
[02:30] <wgrant> Ah, yeah, I noticed that looked a bit duplicated when I did the initial query rewrite.
[02:31] <lifeless> _getBugTaskContextClause
[02:31] <lifeless> actually
[02:31] <lifeless> I could use a teddy bear
[02:31] <lifeless> got 5?
[02:32] <lifeless> wgrant: ^
[02:33] <wgrant> Sure.
[02:33] <lifeless> skype>
[02:33] <wgrant> If it stops segfaulting...
[02:33] <lifeless> \o/
[02:34] <lifeless> I can ring your landline if thats easier?
[02:35] <wgrant> Nah, just give me a sec to boot my laptop.
[02:37] <wgrant> Hmm. Nobody is online... not even Skype Test Call.
[02:37] <wgrant> Ah, there we go.
[03:32] <StevenK> Cockatoos need to die.
[03:33] <StevenK> Washing out on the balcony, and they attacked the pegs, so now the clean clothes need re-washing :-(
[03:34] <StevenK> Stewart Smith
[03:34] <StevenK> have noticed over $timeperiod improvements in #launchpad responsiveness and stability. #awesome
[03:35] <StevenK> lifeless: ^
[03:38] <lifeless> StevenK: hanging out in #drizzle ? :)
[03:38] <StevenK> lifeless: No, that was from Failbook
[03:38] <lifeless> oh cool
[03:38] <lifeless> he was going to tweet it
[03:38] <lifeless> also expecting a blog post too
[03:42] <wgrant> :/ big deploy queue
[03:42] <wgrant> And nothing we can do about it :(
[03:46] <lifeless> wgrant: because of the subscribers thing?
[03:46] <wgrant> Yeah.
[03:47] <lifeless> how many revs apart was the initial landing and the fix?
[03:47] <wgrant> Landed 13243, reverted 13247, relanded 13248, first fix 13258, still not OK.
[03:48] <lifeless> oh? I thought danilo landed a fix?
[03:48] <wgrant> It's OK for anonymous users now, sure.
[03:48] <wgrant> Doesn't mean it's OK :)
[03:48] <lifeless> how isn't it ok?
[03:48] <wgrant> It's a 12000 line diff, so we can't be even slightly sure it's OK.
[03:49] <wgrant> And IMO it's a regression.
[03:49] <wgrant> I can't see who is subscribed to a bug any more :/
[03:49] <wgrant> Oh, actually, I can, but it's not at all obvious.
[03:50] <wgrant> ("Notified of all changes" is direct subscriptions, "Maybe notified" isn't valid English and is structural subscriptions, and the other categories are something else that I forget)
[04:06] <lifeless> so, why can't we deploy ?
[04:08] <wgrant> Last I heard they were still QAing it.
[04:08] <lifeless> ugh
[04:09] <lifeless> how can we help them
[04:09] <wgrant> 22:33 < danilos> matsubara, right, so we still haven't marked it as qa-ok because I'd prefer to get a little bit more QA done first
[04:09] <wgrant> That was Friday night.
[05:15] <lifeless> what defines when a view does/doesn't have a self.user ?
[05:15] <lifeless> or more precisely
[05:15] <lifeless> why would a view not inherit from LaunchpadView ?
[05:17] <lifeless> BugTargetBugListingView is what I'm staring at
[05:24] <lifeless> ok, random q #2
[05:24] <lifeless> is there a way to say 'any class that implements this Interface should allow the interface to be used'
[05:24] <lifeless> rather than explicit <allow interface=xxx> statements for each implementing class?
[05:26] <mwhudson> lifeless: i think "being incredibly ancient" is the only reason to not inherit from LaunchpadView?
[05:26] <mwhudson> -?
[05:35] <lifeless> well, who knows
[05:35] <wgrant> mwhudson's understanding is the same as mine.
[05:37] <lifeless> and on the second point ?
[05:37] <wgrant> No. Why?
[05:39] <lifeless> reducing duplication
[06:33] <lifeless> grrrrrrrrrrrrrah
[06:33] <lifeless> BugSummary.tag in [BugSummary.milestone_id]
[06:33] <lifeless> True
[06:35] <wgrant> Yeah...
[06:35] <mwhudson> just by fluke?  or because types are being strange?
[06:35] <lifeless> I'm guessing some of the query builder magic either has a corner case or a bug
[06:35] <wgrant> It's the same Storm misfeature that wiped out part of the primary archive last year when I used in instead of is_in.
[06:36] <wgrant> __contains__ returns an expression.
[06:36] <wgrant> Which evaluates to True.
[06:36] <wgrant> Wait, no.
[06:36] <lifeless> but thats not applicable here
[06:36] <wgrant> __eq__ returns the expression.
[06:36] <wgrant> Which evaluates to true.
[06:36] <lifeless> bug 799602
[06:36] <wgrant> s/expression/Expr/
[06:36] <_mup_> Bug #799602: something funky in comparisons makes introspecting things tricky <Storm:New> < https://launchpad.net/bugs/799602 >
[07:39] <lifeless> and, I have bugsummary2 enabled stats portlet
[07:45] <wgrant> These version numbers are a bit Chromy.
[07:49] <lifeless> ?
[07:53] <wgrant> Version 2 after like a month :P
[07:54] <StevenK> Haha
[07:56] <lifeless> wgrant: well, it won't be versioned live
[07:56] <lifeless> its just a handle
[08:14] <lifeless> I can has review ? https://code.launchpad.net/~lifeless/launchpad/bug-793848/+merge/65158
[08:17] <StevenK> 1,110 lines at 5:20pm? Uh, no.
[08:17] <lifeless> its mainly deletes
[08:18] <lifeless>  21 files changed, 215 insertions(+), 337 deletions(-)
[08:18] <lifeless> the way we assess patch size is pretty crazy
[08:19] <StevenK> You only complain about that when you go over
[08:19] <lifeless> of course
[08:19] <lifeless> its crazy all the time
[08:19] <lifeless> but doesn't come up in conversation otherwise
[08:19] <StevenK> I shall pass, sorry. I'm developing a headache from DSP/DSPR/DSBP.
[08:20] <lifeless> no worries
[08:20] <lifeless> I'm getting one just reading those abbreviations
[08:20] <StevenK> Welcome to my day.
[08:24] <StevenK> henninge: O hai, Mr OCR.
[08:25] <henninge> Hi StevenK! ;)
[08:25] <henninge> StevenK: what can I do for you?
[08:25] <lifeless> \o/
[08:25] <lifeless> henninge: https://code.launchpad.net/~lifeless/launchpad/bug-793848/+merge/65158 when you have a chance ;)
[08:26] <StevenK> henninge: https://code.launchpad.net/~stevenk/launchpad/db-add-bprc/+merge/64783 . I don't mind you if review lifeless' first, or mine, but my branch is smaller. :-)
[08:26] <henninge> wow, 1110 lines of diff ...
[08:26] <lifeless> yes yes
[08:26] <lifeless> deletes do that :)
[08:26] <henninge> oh, deteles are cool ;)
[08:27] <lifeless> Diff against target: 1110 lines (+215/-337) 21 files modified
[08:27] <lifeless> is a more useful metric I think
[08:27] <lifeless> given the vast chunk of the line count is context
[08:27] <henninge> yes yes :-P
[08:27] <lifeless> :)
[08:28] <lifeless> I think StevenK's was up first, you should save mine for later :>
[08:28] <lifeless> (especially as I just noticed a spelling error to fix)
[08:29] <StevenK> My DB review was on Friday, I spent most of the weekend doing the interfaces and model
[08:29] <wgrant> StevenK: Reviewed.
[08:29] <wgrant> Bah, you just roped henning into it, I see.
[08:30] <henninge> wgrant: I was about to start ...
[08:30] <henninge> wgrant: that's what the "claim review" button is for :-P
[08:31] <wgrant> I don't trust buttons.
[08:31] <adeuring> good morning
[08:32] <henninge> Hi adeuring!
[08:32] <adeuring> moin henninge!
[08:32] <StevenK> wgrant: Thanks.
[08:35] <wgrant> lifeless: How can column.__eq__(column) evaluate immediately?
[08:36] <lifeless> wgrant: perhaps it can't
[08:36] <lifeless> wgrant: I have a headcold. I'm excused from thinking.
[08:36] <wgrant> True, true.
[08:43] <StevenK> wgrant: Sadly, it is not a full path name, it is 'bin/true', for example.
[08:44] <wgrant> StevenK: So it is. How stupid.
[08:45] <lifeless> on the unicode thing
[08:45] <lifeless> unicode(foo) is always unsafe
[08:45] <wgrant> Unless it's always an ASCII string, yes.
[08:46] <lifeless> yes
[08:46] <StevenK> It's a path name
[08:46] <wgrant> So using it on a potentially non-ASCII string is wrong.
[08:46] <wgrant> StevenK: Paths aren't ASCII.
[08:46] <lifeless> there are some source packages with non-utf8 paths around; I don't know about binary packages offhand
[08:47] <StevenK> Query the conflict checker?
[08:47] <lifeless> just check a current Contents.gz
[08:47] <lifeless> easier
[08:47] <StevenK> I don't know how to check for UTF-8
[08:48] <lifeless> for line in thing: line.decode('utf8')
[08:48] <lifeless> if it goes boom it wasn't utf8
[08:50] <rvba> wgrant: Hi William, if you have time to take a look at my MP before you EOD it would make me happy ;) (https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676)
[08:50] <rvba> I've worked with jtv on Friday on the perforance and I plan to do that again with Julian (testing real world queries) today. But if perf needs improvement I'd like to do that in another branch.
[08:51] <StevenK> It goes boom
[08:51] <lifeless> well then :)
[08:51] <lifeless> so we need to change the db patch
[08:51] <StevenK> Which is fine, it hasn't landed yet
[08:52] <wgrant> Or say that if people have non-UTF-8 paths then they should die.
[08:52] <lifeless> -or- we need to say that we'll exclude such things from the contents.gz
[08:52] <wgrant> rvba: Looking, thanks for the reminder.
[08:52] <lifeless> I'd favour talking to the distro now and then excluding non-utf8
[08:52] <lifeless> it will make it a lot easier to work with.
[08:52] <StevenK> usr/lib/OpenVerse/language/Espanoles                        universe/net/openverse
[08:52] <StevenK> usr/lib/OpenVerse/language/Espa<F1>oles                     universe/net/openverse
[08:52]  * StevenK facepalm
[08:54] <lifeless> btw I'm pretty sure you can read the files straight out of the ar
[08:54] <lifeless> lemme have a quick look
[08:54] <wgrant> ar then tar, yeah.
[08:54] <wgrant> It's easy enough to do.
[08:54] <wgrant> But apt_pkg can do it for us..
[08:55] <wgrant> (but the tarball may be compressed in several different ways)
[08:55] <StevenK> It does?
[08:55] <StevenK> wgrant and I already had this discussion
[08:55] <StevenK> apt.debfile.DebPackage.filelist
[08:56] <StevenK> lifeless: Your MP is out of date?
[08:56] <wgrant> rvba: bigjools accepts the orphaned binary issue?
[08:56] <wgrant> rvba: And the binary and source file conflict issue?
[08:58] <rvba> wgrant: Hum ... since I now apply the same copying method to binary and source those two problems are not really there any more ...
[08:58] <wgrant> rvba: they're still very much there.
[08:59] <lifeless> StevenK: apt_inst.debExtract(open(local_file.name), capture_filepaths, "data.tar.gz")
[09:00] <wgrant> Or apt.debfile.DebPackage.filelist...
[09:00] <rvba> IIRC Julian was not really concerned by the orphaned binary issue right now since it's ugly but not an imminent danger to the integrity of the data.
[09:00] <lifeless> StevenK: perhaps
[09:00] <StevenK> lifeless: And I say again, what's wrong with apt.debfile.DebPackage.filelist ?
[09:00] <lifeless> refreshing the page :)
[09:00] <wgrant> I already complained at him for using subprocess, and he fixed it.
[09:00] <StevenK> wgrant had this argument 5 hours ago.
[09:00] <rvba> wgrant: can you elaborate on the "binary and source file conflict issue" ?
[09:00] <wgrant> rvba: Orphaned binaries are ungood but do not cause irreparable damage. Binary and source file conflicts do.
[09:01] <StevenK> wgrant: 13 is the number of files in pmount.deb, excluded directories. Do you want a comment or me to calculate it in the test?
[09:01] <wgrant> rvba: Say I have hello 1.2-3 in some old series.
[09:01] <lifeless> StevenK: wasn't meaning to cause extra work, was just looking at the need for a temp dir
[09:01] <wgrant> StevenK: I'd like some verification that the filenames are right.
[09:01] <StevenK> wgrant: Right, fair enough.
[09:02] <StevenK> lifeless: I'm switching to tempfile.TemporaryFile()
[09:02] <wgrant> rvba: So, from that I'll probably have a hello_1.2-3_i386.deb. That gets superseded in these series.
[09:02] <StevenK> Or, attempting to.
[09:02] <wgrant> rvba: What happens if I now initialise a new series in my distribution from another distro with a different hello_1.2-3_i386.deb?
[09:02] <lifeless> TempDir is fine if we don't expect to be kill -9ing the process
[09:02] <lifeless> but we may end up doing that :>
[09:02] <rvba> wgrant: then only the package present in the *first* parent will be copied.
[09:03] <rvba> s/package/packages/
[09:03] <lifeless> StevenK: NamedTemporaryFile is as safe (or unsafe) as TempDir, FWIW
[09:03] <wgrant> rvba: But that's enough.
[09:03] <wgrant> rvba: Because the package present in the first parent is different from the one already in the archive.
[09:04] <rvba> wgrant: each time we copy a parent into the (new) archive, we exclude from the copy any package with a name (sourcepackagename or binarypackagename) already present in the destination archive.
[09:04] <wgrant> rvba: In the destination archive *and suite*.
[09:04] <danilos> rvba, hi, do you think you'd be able to QA 795396 fix soon? allenap, how about you and 798263? :)
[09:04] <rvba> danilos: hi! one sec.
[09:04] <danilos> rvba, cheers
[09:05] <StevenK> Damn it, does NamedTemporaryFile() delete the file on close?
[09:05] <allenap> danilos: Okay, I'll do that now.
[09:05] <lifeless> StevenK: yes
[09:05] <lifeless> StevenK: it can't unlink it before then
[09:05] <StevenK> Bah
[09:05] <danilos> allenap, thanks a bunch!
[09:05] <lifeless> StevenK: if a regular temporary file onw't work, then use your current code.
[09:06] <wgrant> lifeless: Why use TempDir when a NamedTemporaryFile is fine?
[09:06] <rvba> danilos: I'll be able to QA 795396 right now (if DF is up to date)
[09:06]  * rvba checks DF
[09:06] <lifeless> wgrant: shrug, was saying 'do the simplest thing'
[09:06] <StevenK> NamedTemporaryFile() currently isn't, since I'm using copy_and_close() to grab the contents of the filename from the librarian.
[09:06] <lifeless> wgrant: they are functionally equivalent
[09:07] <lifeless> wgrant: in terms of diskspace and leaks
[09:07] <wgrant> lifeless: They are. But creating a file is probably simpler than creating a directory and then creating a file.
[09:07] <StevenK> And so copy_and_close() close()'s the temporary file and it gets deleted.
[09:07] <wgrant> That's rather antisocial of it.
[09:07] <lifeless> wgrant: I think StevenK has found a difference :>
[09:08] <rvba> StevenK: Hi Steven, can you update DF?
[09:08] <danilos> rvba, just let me know when it's done because I have a mixture of revisions landed that should only be rolled out together, and I can't mark the earlier one qa-ok until everything in between is qa-ok :)
[09:08] <wgrant> rvba: I'm there already. Will do it now.
[09:08] <rvba> danilos: sure, I will.
[09:08] <rvba> wgrant: thanks.
[09:08] <danilos> thanks all
[09:08] <StevenK> Unless I can use something other than copy_and_close() to copy from the librarian?
[09:09] <lifeless> you can, theres a pump_file in bzrlib.osutils
[09:10] <wgrant> rvba: Should be coming back now.
[09:10] <rvba> wgrant: so your point is that since I check that the package is already there in the destination archive and suite, it's still possible to have the exact same *file* (in two different archives) ... right?
[09:10] <rvba> wgrant: thanks.
[09:10] <StevenK> % grep -c pump_file eggs/bzr-2.3.3-py2.6-linux-x86_64.egg/bzrlib/osutils.py
[09:10] <StevenK> 0
[09:10] <rvba> s/two different suites/two different suites/
[09:10] <wgrant> rvba: Right.
[09:11] <rvba> s/two different archives/two different suites/ even
[09:11] <wgrant> It may not be in the current suite.
[09:11] <rvba> wgrant: right, I get it ... that's the point ou already made last week but I guess I did not understand it properly ...
[09:11] <wgrant> It's an edge case, but this is the sort of place that an edge case will crop up and nomnomnom goes the primary archive. And we want primary archives to not be eaten alive.
[09:11] <lifeless> +1
[09:12] <rvba> wgrant: right.
[09:13] <rvba> danilos: QA ok for 795396.
[09:13] <danilos> rvba, great, thanks!
[09:13] <rvba> np
[09:14] <bigjools> morning all
[09:15] <StevenK> Looks like copy_and_close() is it. :-(
[09:17] <lifeless> StevenK:     pumpfile(from_file, to_file, read_length=-1, buff_size=32768, report_activity=None, direction='read')
[09:17] <lifeless>         Copy contents of one file to another.
[09:17] <lifeless>         
[09:17] <lifeless>         The read_length can either be -1 to read to end-of-file (EOF) or
[09:17] <lifeless>         it can specify the maximum number of bytes to read.
[09:17] <lifeless>         
[09:17] <lifeless>         The buff_size represents the maximum size for each read operation
[09:17] <lifeless>         performed on from_file.
[09:17] <lifeless> StevenK: (bin/py -m pydoc bzrlib.osutils)
[09:17] <StevenK> lifeless: It seems NamedTemporaryFile() has a delete parameter
[09:18] <rvba> wgrant: Thanks for the clarification, I'll work on this today.
[09:18] <lifeless> StevenK: at which point its no longer a temporary file
[09:18] <wgrant> rvba: Thanks. This isn't an easy thing, unfortunately :(
[09:19] <rvba> wgrant: right, but with your help I'll see it through and land the 2500+ SLOC which depend on this ;)
[09:20] <lifeless> StevenK: check the implementation - both the __del__ handler and the context manager will leave the file behind if you pass delete=False
[09:20] <lifeless> StevenK: which is very much not what you want
[09:20] <lifeless> myself, I'd use the tempdir and get on with my life ;). If you want to do something different, pumpfile will let you copy things around relatively sanely.
[09:22] <StevenK>     self._debfile = apt_inst.DebFile(open(self.filename))
[09:22] <StevenK> SystemError: E:Archive is too short
[09:22] <StevenK> That's right after calling pumpfile()
[09:23] <wgrant> seek(0)
[09:24] <lifeless> you have a file already
[09:24] <lifeless> seek(0) and pass the file in rather than a new file object.
[09:24] <lifeless> henninge: I hope my review isn't frying your brain
[09:25] <henninge> lifeless: no, it won't ...
[09:26] <lifeless> do we have a list of supported browsers ?
[09:26] <jml> good morning launchpadders
[09:26] <lifeless> (bug 799491)
[09:26] <_mup_> Bug #799491: Posting a comment in rekonq does not insert it into the page <Launchpad itself:New> < https://launchpad.net/bugs/799491 >
[09:26] <jml> huwshimi & I are in Millbank
[09:26] <lifeless> hola jml
[09:26] <jml> lifeless: umm... I *thought* we did. huwshimi, do you know about such a list?
[09:27] <huwshimi> lifeless: Yeah I think there is something like that around. Let me dig it out
[09:29] <huwshimi> lifeless: This is what I was thinking of: https://dev.launchpad.net/GradedBrowserSupport
[09:29] <lifeless> KLMN - its 2 years old?
[09:30] <lifeless> anyhow
[09:30] <lifeless> what I really care about is
[09:30] <lifeless> do we consider bugs w/js on rekonq important, or do we say 'thanks for noticing, now please give us a patch' ?
[09:30] <lifeless> [paraphrasing obviously]
[09:31] <bigjools> rekonq uses webkit FWIW
[09:31] <lifeless> yeah
[09:31] <lifeless> still manages to fail - multiple different bugs open for it
[09:31] <bigjools> not sure why the KDE people thought we needed another browser
[09:34] <StevenK> wgrant: So, unicode() is wrong, what you prefer I use? filename.encode('utf8') and catch the encoding exception?
[09:34] <lifeless> StevenK: if you're willing to not put non-utf8 stuff in the contents file, then yes.
[09:34] <lifeless> StevenK: the alternative is to change the column from text to a byte array
[09:35] <StevenK> And then use RawStr() ?
[09:46] <jml> lifeless: if it's just a rekonq bug & not a webkit bug, it's the latter.
[09:46] <lifeless> definitely not webkit; chrom* is fine
[09:48] <jml> huwshimi: btw, I'm done w/ email stuff.
[09:49] <huwshimi> jml: I'm almost there. 5-10 mins if that's ok?
[09:49] <jml> huwshimi: sure.
[09:52] <StevenK> wgrant: What would you prefer?
[09:58] <huwshimi> jml: OK, done for now'
[09:58] <jml> huwshimi: cool. want to come over here?
[09:58] <huwshimi> jml: OK, coming
[10:01] <lifeless> StevenK: excluding some files will need an ack from the distro I think
[10:01] <lifeless> StevenK: that might be easy to get
[10:02] <lifeless> I would prefer to drag stuff into the unicode-only world
[10:02] <lifeless> so encourage you to seek that ack
[10:15] <StevenK> lifeless: Given nothing uses this, and isn't likely to until I write a population script are you personally happy with me leaving it as is and landing it while I wait for the ack.
[10:16] <lifeless> StevenK: I'd be happy with you doing .decode('utf8'), catching errors and skipping those files, and seeking the ack async
[10:16] <lifeless> StevenK: I wouldn't be happy with the cast-as-is landing
[10:16] <StevenK> Right
[10:42] <jml> jelmer: do you need anything from me wrt build-from-branch-into-(archive|primary)?
[10:46] <danilos> lifeless, whatever fails on webkit browsers is likely to fail on safari as well (I've hit a few problems like that with epiphany as well)
[10:46] <danilos> for instance, use of "class" keyword for a variable fails in webkit browsers
[10:49] <jelmer> jml: No, though thanks for checking. (I'm waiting to double check with poolie, then I'll send an announcement of the LEP to the list)
[10:49] <jml> jelmer: ok cool.
[11:19] <lifeless> bigjools: have you put any thought into query schemas for soyuz ?
[11:19] <bigjools> none at all
[11:19] <lifeless> k
[11:19] <bigjools> sorry - too busy with DDs
[11:20] <bigjools> when we start maintenance I will
[11:20] <lifeless> no need to apologise
[11:20] <lifeless> I ask so that if I get some time to look at it, I'm not reinventing already thought out stuff
[11:20] <bigjools> sure
[11:31] <danilos> bigjools, hi, do you know if jtv will show up today or if there's someone who can help QA bugs 394645, 537335?
[11:33] <bigjools> danilos: he's having a day off
[11:35] <danilos> bigjools, ah, ok, thanks; seems a pretty big change so I don't feel comfortable doing the QA, and if we can't find anyone else to do it, I suppose we won't have a rollout today
[11:36] <bigjools> danilos: are they his changes ?
[11:38] <danilos> bigjools, yeah
[11:38] <bigjools> let me checkl
[11:38] <danilos> bigjools, spread over 3-4 revisions in the deployment report
[11:38] <danilos> bigjools, https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[11:40] <danilos> bigjools, (the first blocking revision is QAd but I need 13258 to be included in the deployment before I can mark it as qa-ok)
[11:40] <lifeless> danilos: I think its your patch blocking atm :)
[11:41] <danilos> lifeless, see above, it's not
[11:41] <lifeless> danilos: ah I see
[11:41] <danilos> lifeless, I mean, I am keeping it like that on purpose
[11:41] <danilos> (haven't used proper metadata in the commit message)
[11:41] <lifeless> its fine, just a tad confusing
[11:44] <lifeless> gnight everyone
[11:51] <huwshimi> allenap: Hi, are you around?
[11:51] <allenap> huwshimi: Yes, hi.
[11:52] <allenap> huwshimi: Want to have a chat?
[11:52] <huwshimi> allenap: Do you have a minute and want to talk about the initialization errors UI?
[11:52] <allenap> huwshimi: What's your preference? Skype, Mumble, phone?
[11:53] <jml> lifeless: g'night.
[11:53] <huwshimi> allenap: Skype or Mumble is fine. I might try and trigger the error first though.
[11:53] <huwshimi> allenap: Unless you have a screenshot?
[11:54] <allenap> huwshimi: The error does not display anywhere in the page; it's an error in an job that runs outside of the app server.
[11:54] <huwshimi> allenap: Ah I see
[11:55] <allenap> huwshimi: I'm online in Mumble, in Launchpad/Red.
[11:55] <huwshimi> allenap: OK, one minute
[12:11] <huwshimi> allenap: Let me know if you have any more questions about that.
[12:12] <huwshimi> allenap: I would also like to have a chat after you've implemented it to see how it went and how easy it was to do the UI side of things
[12:13] <allenap> huwshimi: Cool, okay, thanks.
[13:54]  * jml afk
[13:56] <henninge> adeuring: I won't make it to the call be fore :15
[13:58] <henninge> Hi deryck, I wont make it until :15
[13:58] <deryck> hi henninge.  see my #launchpad-ops message. :)
[13:59] <henninge> not on there atm
[14:01] <adeuring> henninge: everything postponed for >30 minutes :)
[14:01] <henninge> cool
[14:02] <deryck> henninge, yeah, sorry.  I need to wait to bottom of hour for standup.
[14:31] <deryck> abentley, adeuring -- ping for standup
[14:35] <Ursinha-brb> this is taking forever, argh
[14:38] <maxb> Hi all - is r13249 deployable, and when is the next nodowntime deploy likely to occur?
[14:54] <danilos> Ursinha-brb, hi, is there a way for me to mark a revision as fixed by one of the subsequent commits? (i.e. 13243/13248 is fixed by 13258)
[15:00] <maxb> Ah, that half-answers my question :-)
[15:03] <Ursinha-brb> danilos, if the revision referencesthe same bug, it'll be marked as needstesting and the first revision should be fine
[15:03] <Ursinha-brb> what links the revisions are the bugs they refer to
[15:05] <Ursinha-brb> maxb, we generally do the nodowntime deployments when we reach more than 5 revisions ready to deploy
[15:05] <Ursinha-brb> when we reach five, I mean
[15:06] <maxb> Ursinha-brb: amount of ready revisions isn't really the problem right now :-)
[15:06] <Ursinha-brb> hehe
[15:06] <maxb> It seems there's some deployability firefighting going on
[15:06] <Ursinha-brb> let me see
[15:14] <Ursinha-brb> hm
[15:15] <danilos> Ursinha-brb, right, but they are linked to different bugs, and I don't want the first revision to be deployable before the latter one is :) I was hoping there'd be a qa tag like "qa-fixed-in-XXX" :)
[15:16] <Ursinha-brb> there's not, unfortunately
[15:17] <danilos> maxb, fwiw, I am intentionally blocking on r13243 before everything becomes deployable up to and including 13258, but there are some complex revisions that I can't QA myself
[15:18] <danilos> Ursinha-brb, ok, then I'll just have to keep an eye on the deployment report, thanks
[15:19] <maxb> 13260 is a rollback og 13521, so presumably we have to go all the way from 13242 -> 13260 at least, in one hop :-/
[15:20] <maxb> Perhaps I should check back tomorrow :-)
[15:20] <danilos> maxb, yeah
[15:20] <wgrant> danilos: Please keep lifeless and myself up to date... we will attempt to deploy tomorrow.
[15:21] <wgrant> Since you can't keep the tagger up to date :(
[15:22] <danilos> wgrant, well, there's not much I can do: jtv's revisions need QA and it seems complex enough a change that I couldn't QA it this morning; if we decide to ignore the anon user problem, we can just mark qa-ok bug 772754, but that will only bring us two revisions forward
[15:22] <_mup_> Bug #772754: After better-bug-notification changes, list of bug subscribers is confusing <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by gary> < https://launchpad.net/bugs/772754 >
[15:22] <wgrant> Argh
[15:23] <wgrant> And no bigjools.
[15:23] <danilos> wgrant, I did bring it up this morning with Julian, fwiw
[15:44] <henninge> Hi benji!
[15:44] <benji> hi henninge
[15:44] <henninge> benji: Are you already working on a review?
[15:44] <henninge> I just did Bryce.
[15:45] <benji> henninge: not at the moment, I'm helping on something else
[15:45] <henninge> ok
[15:51] <adeuring> henninge, benji: could one of please review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-796867/+merge/65209 ? (~100 lines diff)
[15:52] <henninge> adeuring: I can do it in a minute
[15:52] <adeuring> henninge: great, thanks!
[15:59] <jml> sinzui: hi
[15:59] <sinzui> hi jml
[16:00] <jml> sinzui: huwshimi & I are going to go into a room with a conference phone
[16:00] <jml> sinzui: oh yeah, I've invited huwshimi to join us :)
[16:00] <sinzui> I saw
[16:00] <sinzui> read
[16:01] <jml> sinzui: umm... can we dial a landline or voip number for you?
[16:01] <sinzui> sip 7642
[16:01] <jml> sinzui: thanks.
[16:02] <jml> sinzui: "the number you have dialled is currently unavailable"
[16:02] <sinzui> jml: call again
[16:48] <jml> sinzui, huwshimi: “The perfect search engine would understand exactly what you mean and give back exactly what you want.”
[16:53] <jcsackett> benji: can you take another look at my MP? i believe the diff had been out of date, which confused the issue of your comment. https://code.launchpad.net/~jcsackett/launchpad/package-pickers-navigation-jumps/+merge/65222
[16:54] <benji> jcsackett: sure, it'll be a little while though
[16:54] <jcsackett> benji: no worries. thanks. :-)
[16:57]  * jml is off for the day
[17:32] <henninge> adeuring: approved. Sorry, I thought I had already done that.
[17:40] <cjwatson> wgrant: any progress on deploying my germinate-lubuntu branch?
[17:48] <adeuring> henninge: thanks!
[17:52] <jelmer> abentley: hi
[18:01] <jelmer> abentley: can bug 586944 be closed? AFAICT it's fixed
[18:01] <_mup_> Bug #586944: Launchpad should provide a ui for daily builds <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/586944 >
[18:02] <abentley> jelmer: hi.
[18:03] <abentley> jelmer: I have no idea.
[18:03] <jelmer> abentley: You filed it, and there's a merged branch associated with it.
[18:04] <abentley> jelmer: okay, that's a different issue than I thought.  Yes, that bug could have been closed a year ago.
[18:04] <jelmer> abentley: ok, I'll close it. Thanks
[18:29] <benji> jcsackett: I finally got to look at your branch, it looks fine.  Please file a bug for the bad JS building.
[18:30] <jcsackett> benji: will do, thanks!
[18:42] <sinzui> Hail jcsackett. Do you have time to mumble?
[18:43] <jcsackett> sinzui: sure. mumble or sip?
[18:43] <sinzui> mumble?
[19:15] <gary_poster> abentley, could you either handle https://answers.launchpad.net/launchpad/+question/160629 or tell me what I can do about it?
[19:17] <gary_poster> deryck, someone wants to delete a hwdb submission.  Any ideas on what to tell them?
[19:20] <abentley> gary_poster: Now that 13241 has been deployed, the next scan of the branch should succeed.
[19:20] <gary_poster> Great news abentley, thanks.  I'll pas that on
[19:20] <gary_poster> s
[19:21] <abentley> gary_poster: in fact, it looks like that has already happened, as the last revision is from 3 hours ago.
[19:22] <gary_poster> abentley, yeah, I had just come to the same conclusion.  Thanks again
[19:22] <abentley> gary_poster: no problem.
[19:38] <deryck> gary_poster, I thought they could delete it from their user profile on lp, but would need to poke at code or urls to confirm.
[19:39] <gary_poster> deryck, ok.  I'll pass that on to the next CHR person :-)  Thanks
[19:39] <deryck> np :)
[20:04] <bac> hi sinzui, would you have a couple of minutes to chat with me for a pre-imp for bug 776437?
[20:04] <_mup_> Bug #776437: Enable ARM builders for PPA via API <api> <escalated> <not-pie-critical> <oem-services> <ppa> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/776437 >
[20:04] <sinzui> okay
[20:05] <sinzui> bac: I am on mumble now
[20:05] <bac> sinzui: ok, let me mumble up
[20:19] <abentley> benji: could you please review https://code.launchpad.net/~abentley/launchpad/memlimit-jobs/+merge/65256 ?
[20:20] <benji> abentley: sure
[20:20] <abentley> benji: thanks.
[20:29] <LPCIBot> Project windmill-devel build #252: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/252/
[20:33] <bac> sinzui: is bug 760849 the root cause of this problem?  if i hadn't exported the collection (IProcessorFamilySet) would the error not have been seen?
[20:33] <_mup_> Bug #760849: No way to restrict export_as_webservice_collection to a given API version <api> <lazr.restful:Triaged> < https://launchpad.net/bugs/760849 >
[20:34] <bac> jcsackett: ^^
[20:34] <abentley> sinzui: is it expected that bin/test --layer=YUITestLayer may segfault?
[20:37] <jcsackett> bac: not sure of the question. there is the problem that once you export a collection it is exported on all versions of the API. which is a pain.
[20:37] <bac> jcsackett: so is the solution to claim each entry first appeared in 'beta', as you did for IQuestion?
[20:38] <jcsackett> bac: that is *a* solution. i don't know that it's *the* solution.
[20:38] <bac> jcsackett: by "solution" i mean unholy work-around
[20:38] <jcsackett> bac: ah, yes. it's definitely that. :-P
[20:39] <jcsackett> bac: as it was explained to me (though i can't recall by who), the main thing is to make certain that the smallest possible set of stuff gets exported as of 'beta', and to make sure you don't export anything to it that's going to change.
[20:39] <bac> jcsackett: rt
[20:40] <sinzui> abentley, no. I was hoping deryck would follow up on the new package I build
[20:40] <deryck> sinzui, I wasn't clear we had a new package, sorry.  I tired from devel last we talked and still seg faulting....
[20:40] <deryck> sinzui, shall I update and try again?
[20:40] <benji> Ursinha: do you know where I can find the disable_project.py script mentioned in https://dev.launchpad.net/Registry/ProjectReview?
[20:41] <sinzui> abentley, The segfault is not seen on lucid or the natty/oneiric computers I have. I beleieve the issue a is a combination of libs
[20:41] <jcsackett> benji: lp-dev-utils, i think.
[20:41] <sinzui> benji, lp-dev-utils
[20:41] <benji> cool, thanks guys
[20:42] <abentley> sinzui: I'm running oneiric.
[20:42]  * benji edits said wiki page.
[20:42] <abentley> sinzui: sorry, natty.
[20:42] <sinzui> deryck, please do, but maybe it is pointless since abentley is seeing it now
[20:42] <sinzui> abentley, were you seeing this last Thursday when we talked about import gtk?
[20:43] <abentley> sinzui: No, I wasn't running YUITestLayer then.
[20:43] <abentley> sinzui: I was running twisted tests, and they were interacting badly with the import of html5browser.
[20:44] <lifeless> moin
[20:44] <sinzui> abentley, When I looked at deryck's report, the segfault happens in the first test of the second app (bugs)
[20:45] <sinzui> abentley, the tests were never played in the same order, all app/ tests completed, bugs dies on the first test
[20:45] <abentley> sinzui: http://pastebin.ubuntu.com/629993/
[20:46] <sinzui> abentley, do you have the version of python-html5-browser that landed Saturday?
[20:48] <abentley> sinzui: I do see an upgrade available.  I'll install it.
[20:48] <sinzui> 0.0.4-0~18-9
[20:49] <sinzui> abentley, the new packaging tries to avoid mixing gtk2/3 libs that can be implied by gir
[20:49] <sinzui> I suspect that is the origin of the segfults
[20:51] <abentley> sinzui: same result after upgrade.
[20:54] <sinzui> :(
[20:55] <sinzui> abentley, I am uncertain as to how to proceed. Have you tried ./bin/test -vvc --layer=YUI -t lp/bugs
[20:55] <sinzui> to see if those tests complete
[21:01] <deryck> sinzui, no luck still.  on latest package.  http://pastebin.ubuntu.com/629997/
[21:02] <abentley> sinzui: I get segfault from your suggestion.
[21:02] <benji> abentley: I'm done with https://code.launchpad.net/~abentley/launchpad/memlimit-jobs/+merge/65256, it looks good
[21:02] <abentley> benji: cool, thanks.
[21:03] <sinzui> Well you gentleman agree that is does not work. I have no clue. ec2 and jenkins run it, though I can see that there webkit lib behaves differently from what we use
[21:04] <sinzui> abentley, deryck: I still suspect that there is an interaction with gtk2
[21:04] <abentley> benji: I see your suggestion to use utilities/format-new-and-modified-imports, but it has no effect.
[21:04] <sinzui> abentley, deryck: Mixing the two libs will always cause problem. My packaging efforts center
[21:05] <sinzui> around be very precise about what must be installed
[21:05] <benji> abentley: darn, I thought it worked like bin/lint.sh in that it used the branch info to figure out which files to examine
[21:06] <abentley> benji: "utilities/format-new-and-modified-imports -r submit:" does the trick.
[21:06] <benji> cool
[21:07] <sinzui> deryck, abentley: I have another project that also needs to ensure libs do not mix. I am waiting for the builds to  so that I can test them. Maybbe that will help be find the right mix of gobject/pygtk/webkit
[21:07] <deryck> ok, cool
[21:07] <sinzui> deryck, !
[21:08] <sinzui> I just saw compared your paste to http://pastebin.ubuntu.com/629993/
[21:08] <sinzui> ^ abentley's
[21:08] <sinzui> I think then that changes to tests/libs have mutated when/where we get a segfault
[21:09] <deryck> I don't follow, sorry
[21:10] <sinzui> deryck, I see three tests cases in that test_lp_names. maybe there is something naughty in that file
[21:11] <sinzui> Maybe you could comment out some of the tests to identify an issue with how we write the test
[21:11] <deryck> sinzui, ah, since we had the same test to fail.
[21:12] <deryck> sinzui, FWIW, the failure is still dependent on order for me....still always the 7th regardless of which test.
[21:12] <sinzui> deryck, I believe the test changed thursday/friday
[21:12] <sinzui> ah
[21:12] <deryck> ok, I'll comment out some stuff, though.  I don't mind trying.
[21:13] <sinzui> bad things come in sevens
[21:13] <deryck> sinzui, a couple more just now to demonstrate:  http://pastebin.ubuntu.com/630006/
[21:15] <sinzui> deryck, there are seven app tests, what happens when you add -t lp/bugs?
[21:16] <deryck> sinzui, bugs passes.
[21:16] <deryck> trying app by itself
[21:16] <deryck> bugs has 6 tests ;)
[21:16] <sinzui> ho theres a shock
[21:17] <deryck> app fails the same way at test 7.
[21:17]  * deryck is trying all the app names....
[21:29] <cr3> is there a function to blacklist pillar names like 'projects' and 'people'?
[21:30] <abentley> sinzui: In my Natty vm, I get a different failure mode: http://pastebin.ubuntu.com/630014/
[21:30]  * sinzui looks
[21:31] <sinzui> abentley, and like deryck. The failure is in the seventh test.
[21:31] <sinzui> I could sort the tests to take the confusion out of future analysis
[21:32] <deryck> sinzui, so I've tested each module.... and only app fails.  and it's the only module with more than 7 tests.
[21:32] <sinzui> deryck, it has exactly seven tests
[21:32] <deryck> hmmm, exactly 7
[21:32] <deryck> right
[21:32] <sinzui> I see that bugs and app setup the tests identically
[21:33] <sinzui> only the name App/Bugs names change
[21:35] <deryck> sinzui, so I removed one test from app and the 7th still seq faults.  this time being the first bugs test.
[21:35] <deryck> 7 is the magic number
[21:36] <sinzui> deryck, I was thinking of changing YUIUnitTestCase.checkResults() return immediately to see if the tests return
[21:37] <deryck> sinzui, ok.  you want me to try that as well?
[21:37] <sinzui> deryck, please
[21:37] <deryck> ok
[21:38] <deryck> sinzui, just return at the top of the method?  Do nothing in the method?
[21:39] <sinzui> Return immediately. I wonder if the json parsing is a mess
[21:39] <deryck> sinzui, same seq fault.  same test 7.  even with the return.
[21:39] <sinzui> ah, but we do json parsing in setup()
[21:39] <sinzui> I am not thinking clearly
[21:42] <deryck> sinzui, hmm, it's not as consistent now, though.  12th test fails now sometimes.  so getting further in some runs.
[21:44] <sinzui> Deryck. I was thinking of make setup() return early by to see if browser/json is the issue
[21:44] <sinzui> self._yui_results = dict(testing=dict(result='pass'))
[21:44] <sinzui> return
[21:44] <deryck> ok, trying that now....
[21:48] <sinzui> deryck, abentleyI just brought another natty machine online to test withc
[21:48] <sinzui> This has a rushed setup of deps.
[21:49] <sinzui> While all the tests pass, I see something surprising in stderr before the tests start
[21:49] <sinzui> Failed to load gnomesegvhandler
[21:50] <deryck> sinzui, so playing in setup a bit.  and `page = client.load_page(html_uri, timeout=self.js_timeout)` seems to cause the seq fault...
[21:50] <deryck> sinzui, at least I can return before that line, no issue.  return after it, boom.
[21:51] <sinzui> deryck, okay, that is my-lib > webkit+gtk > gtk2/3 | libwebkit
[21:52] <sinzui> deryck, are you running another webkit app at the moment? Empathy, Gwibber perhaps
[21:52] <deryck> sinzui, both actually ;)
[21:52] <deryck> sinzui, shall I kill them all and see... ?
[21:52] <sinzui> :( so am I
[21:52] <sinzui> I was hoping they were setuping up something right in my env
[21:53] <sinzui> I am not running them in the new machine that reported gnomesegvhandler was not found
[21:53] <deryck> ah, I see.
[22:04] <sinzui> deryck, I am distracted now. My son was just stung by a bee
[22:04] <deryck> sinzui, no problem.  I'm at EOD anyway.  We can chat again tomorrow about it.
[22:14] <sinzui> abentley can you run
[22:14] <sinzui> GTK_DEBUG=ALL ./bin/test -vv --layer=YUI -t lp/app 2>1 >  _test.log
[22:15] <sinzui> and send/pastebin me the log
[22:15] <abentley> sinzui: sure.
[22:16] <abentley> sinzui: haven't dcced in ages.  Is it working?
[22:17] <sinzui> I see the window after I accepted it, but I see no progress
[22:18] <abentley> sinzui: mailed.  Must go.
[22:18] <sinzui> Thank you very much
[22:55] <mwhudson> jelmer: 203	+ except Exception, e:
[22:55] <mwhudson> 204	+ if e.__class__ in self.unsupported_feature_exceptions:
[22:55] <mwhudson> you know you can write this except  self.unsupported_feature_exceptions: ?
[22:56] <mwhudson> although that gets subclasses i guess
[22:56] <jelmer> mwhudson: no, I didn't realize that - thanks :) Subclasses would be nice to handle in this case too
[22:56] <mwhudson> jelmer: or even isinstance(e, self.unsupported_feature_exceptions)