[11:34] <mac_v> njpatel: the thumbnail problem you 'tweeted' about > Bug 416251
[11:34] <ubot4> Launchpad bug 416251 in nautilus "Nautilus does not show Desktop thumbnails" [Low,Triaged] https://launchpad.net/bugs/416251
[11:34] <mac_v> it seems greatly reduced with kernel .32
[11:49] <njpatel> mac_v: ah nice, thanks :)
[11:49] <mac_v> np :)
[11:53] <njpatel> still, dissapointed nautilus hangs with the bug
[18:54] <alkisg> Could I do something more to help get this accepted? https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/491940
[18:54] <ubot4> Launchpad bug 491940 in gnome-session "Patch for LTSP clients to properly reboot/shutdown" [Undecided,New]
[19:38] <tedg> alkisg: Probably not, I imagine someone will pick it up when they're doing a gnome-session package.  I don't think anyone has made one recently.
[19:38] <tedg> alkisg: I would say the only thing you could do is apply it to a package and put it in a PPA -- just so people could test it if they wanted.
[19:45] <alkisg> tedg: thanks - I have put it in a PPA, it's in https://launchpad.net/~ts.sch.gr/+archive/proposed
[19:46] <alkisg> Testers say it works fine
[19:46] <tedg> alkisg: Cool, comment on that in the bug :)
[19:57] <alkisg> Done, ty :)


[00:02] <lifeless> mwhudson: suggests we need a newer testtools
[00:14] <lifeless> or newer fixtures. EDUNNO
[00:19] <wgrant> lifeless: So, oops-amqp's AMQP usage.
[00:19] <wgrant> lifeless: At present, if the queue doesn't exist then OOPSes will silently be dropped.
[00:23] <poolie> is an ec2 land based on image 522 going to work, or do i need to update onto trunk?
[00:24] <wgrant> poolie: 522 is the latest. If ec2 says it's using that, it will work.
[00:24] <StevenK> wallyworld: Thank you for deleting 518
[00:24] <wallyworld> StevenK: np. i should have done it sooner
[00:34] <lifeless> wgrant: right, it depends on correct config
[00:36] <lifeless> wgrant: thats a standard thing in amqp - the producer cannot know what a 'right' config is, can it ?
[00:36] <wgrant> lifeless: Right.
[00:36] <lifeless> wgrant: we'd check this via nagios I think - send a probe oops through kindof thing
[00:37] <wgrant> We could use the mandatory publish flag, but failure notifications are async and not even exposed by amqplib, I don't think.
[01:20] <StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/rest-glob-imports/+merge/78902
[01:27] <lifeless> wgrant: right
[01:27] <lifeless> wgrant: so as it stands I think its feature complete and usable
[01:27] <lifeless> wgrant: and we can write a small respooler for datedir-repo
[01:28] <lifeless> anyhow -> next thing
[01:31] <wgrant> lifeless: Yep.
[01:36] <wgrant> Arggh
[01:36] <wgrant> https://launchpad.net/linux-kernel
[01:38] <wgrant> Hmm, created by a Googler, apparently.
[01:38] <wgrant> Oddity.
[01:39] <wgrant> StevenK: Has garbo-hourly run on qastaging yet?
[01:42] <wgrant> erm
[01:42] <wgrant> https://code.launchpad.net/~alex-endfinger/google/unity-4.0
[01:42] <wgrant> I think they must be stopped.
[01:43] <wgrant> what
[01:43] <mwhudson> hm, isn't that url already imported somewhere else?
[01:43] <wgrant> That's lp:google.
[01:43] <wgrant> mwhudson: linux.git vs linux-2.6.git
[01:44] <mwhudson> wgrant: ah ok
[01:46] <wgrant> Tempting to deactivate both projects, too.
[01:46] <wgrant> One's a dupe, and one's insane.
[01:47] <wgrant> Ah, jelmer may be on the case as well.
[01:54] <wgrant> We need a "cripple user until they are not doing crazy things any more" button :(
[02:02] <wgrant> [02:02] <wgrant>    190.98s  OOPS-2109ED42   Distribution:+questions
[02:02] <wgrant>     30.57s  OOPS-2109EC14   Distribution:+ppas
[02:05] <wgrant> Heh.
[02:05] <wgrant> Distribution:+ppas is the same thing.
[02:05] <wgrant> I saw it show up on the OOPS reports a couple of days back, didn't think much o fit.
[02:15] <wgrant> Bug #872086
[02:15] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872086 >
[03:17] <StevenK> lifeless: O hai
[03:27] <StevenK> Oh dear, G in #linode
[03:27]  * StevenK tries to not confuse the channels
[03:30] <jtv> StevenK, wgrant: I've got a devastating monster horror branch that overthrows everything the buildd-manager does.  Mind if I try it out on dogfood?
[03:30] <wgrant> Oh god it burns it burns.
[03:31] <wgrant> We didn't have too much luck with buildds there last night.
[03:31] <wgrant> They didn't seem to want to... well, they didn't do very much at all.
[03:32] <jtv> That would be…
[03:32] <jtv> …“bad,” right?
[03:34] <wgrant> That's a bit insensitive. They prefer the term "dogfood".
[03:36] <jtv> Ah, these modern euphemisms.
[03:38] <jtv> The branch I'd like to test is going to be a tough one.  It basically puts the entire scanning loop in read-only transactions, with a few explicit write transactions that commit immediately (rather than waiting for a response from a slave etc.)
[03:39] <wgrant> Yeah, saw that.
[03:39] <wgrant> Unfortunate that you have to put the transaction stuff into the model code.
[03:41] <jtv> Very.
[03:42] <jtv> I can only hope it'll be one step on the way to a good redesign.  At least we'll know where the database changes are.
[03:42] <wgrant> Yep.
[03:44] <jtv> Two things really annoy me about it: (1) it's now painfully hard to work out the transactional behaviour and inspect it for semantic safety, and (2) it's actually been this way all the time but it was implicit so you couldn't even see what was going on.
[03:46] <wgrant> Yup.
[03:46] <jtv> I wonder if this thorough twistification was really the best solution to the performance-bottleneck problem.
[03:46] <wgrant> Well, the problem is that it wasn't a thorough Twistedification.
[03:47] <jtv> True, but I probably mean it in a different respect:
[03:47] <jtv> it probably goes against everything the Twisted crowd believes in, but instead of making entire protocol surfaces asynchronous,
[03:48] <jtv> it might have been better to identify just one or two high-latency interactions where async could be made safe.
[03:49] <jtv> I say “might” because whether it would have helped enough depends on details I have no knowledge of.
[03:49] <wgrant> That's how it was initially, I believe.
[03:49] <wgrant> It was a partial asyncification that jml and bigjools replaced.
[03:49] <wgrant> With a full asyncification.
[03:49] <jtv> I thought they started with the synchronous loop.
[03:50] <wgrant> I think some downloads were async.
[03:50] <wgrant> Some of it was, at elast.
[03:50] <wgrant> least
[03:50] <wgrant> But not much.
[03:50] <jtv> Ah, true, yes.
[03:50] <jtv> So maybe that approach had simply been milked dry already.
[03:54] <jtv> wgrant: I'm still wondering if there's a safe place we can take this code.  Here's one thought: associate a different master store with each builder.
[03:55] <jtv> Or just give each a thread — I know GIL contention is bad but the structure we have now seems to assume that everything spends most of its time blocked anyway.
[03:56] <wgrant> That would solve some of the issues.
[04:02] <jtv> I also see a comment in there: “We need to re-fetch […] as the Storm store is invalidated over transaction boundaries.”
[04:02] <jtv> I know SQLObject did that implicitly, but Storm just re-fetches the object if necessary, right?
[04:05] <wgrant> jtv: I believe it will always refetch in a new transaction.
[04:05] <lifeless> StevenK: hi?
[04:06] <StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/kill-set_up_tacfile_logging/+merge/78908 << crack, or am I doing something good?
[04:07] <lifeless> StevenK: incomplete; you need to migrate not just delete
[04:07] <jtv> wgrant: I know I should be grateful that Twisted is here to liberate us from structured programming and transparent multitasking and bring us the awesome scalability of single-threading.  But on days like this I'm just not feeling it.  I'll grab some more coffee.
[04:07] <lifeless> StevenK: what set_up_tacfile_logging does is bridge python logging to twisted.python.log logging
[04:08] <lifeless> StevenK: I filed a bug on this last week
[04:08] <lifeless> StevenK: I have a branch that overlaps with this too, so we'll conflict. You might want to hold off a few days
[04:08] <wgrant> Mmm.
[04:09] <wgrant> I think deleting it is good.
[04:09] <wgrant> I believe it's doing more harm than good.
[04:09] <wgrant> Causing hangs, for example.
[04:09] <lifeless> it needs to be addressed, yes. Just deleting however will cause stderr spew
[04:10] <wgrant> Better than what we have now.
[04:10] <lifeless> different
[04:10] <lifeless> still a problem.
[04:10] <lifeless> why do you think it is causing hangs ?
[04:10] <wgrant> I know it is.
[04:11] <wgrant> A unicode exception (like, say, uploading a changes file with a key that's on the keyserver but not registered in LP) will cause the upload to hang.
[04:11] <lifeless> how
[04:11] <wgrant> Yes.
[04:11] <lifeless> no, really. How.
[04:11] <wgrant> I don't know. I drowned in Twisted before I could work it out.
[04:11] <wgrant> But it seems to recurse and then melt.
[04:12] <lifeless> python logging should be eating unicode formatting errors.
[04:12] <lifeless> anyhow, if you have a SSCCE it should be easy to address that
[04:13] <wgrant> utilities/start-dev-soyuz.sh; gpg --keyserver keyserver.launchpad.dev --send-key somekey; debsign -ksomekey something.changes; dput lpdev:anyything something.changes
[04:16] <StevenK> lifeless: Yes, I did that branch due to the bug you filed
[04:16] <lifeless> StevenK: ah, I wasn't sure as the bug wasn't linked ;)
[04:17] <StevenK> Is now :-)
[04:24] <lifeless> heh
[04:57] <lifeless> StevenK: can you WIP that branch for now ?
[04:58] <StevenK> Done
[04:59] <lifeless> than ks!
[05:02] <lifeless> anyone happen to know if we have semi-sane configs for rabbit yet? (e.g. not None etc)
[05:02] <lifeless> in prod
[05:03] <wgrant> lifeless: We don't.
[05:05] <lifeless> k, so I need a review for oops 0.0.9 (lp:~lifeless/oops/fallbacks)
[05:07] <lifeless> https://code.launchpad.net/~lifeless/python-oops/fallbacks/+merge/78911
[05:21]  * StevenK looks at pofile-stats-daily and runs screaming, his eyes bleeding
[05:24] <jtv> StevenK: if you need help with that, I'm here for you.
[05:24] <jtv> Right after lunch.
[05:25] <StevenK> It last ran 2 months ago
[05:25] <StevenK> And it takes on average 10 seconds to do one POFile.
[05:25] <StevenK> And given the query in IPOFile._countTranslations(), I'm unsurprised.
[05:27] <wgrant> (132 rows)
[05:27] <wgrant> Nearly there.
[05:27] <StevenK> wgrant: For what?
[05:28] <wgrant> StevenK: That's the number of remaining private multi-pillar bugs that aren't in known evil projects or tagged apport-crash.
[05:30] <lifeless> wgrant: can I nab you for a small follow on review - the changes to oops to support fallbacks from oops-amqp
[05:30] <lifeless> jamesh: ping (touching base on oops migration)
[05:33] <wgrant> lifeless: "if the first publisher doesn't and returns None"
[05:34] <lifeless> blah, You want english now ?
[05:34] <wgrant> 'fraid so.
[05:34] <lifeless> well, it is.
[05:34] <lifeless> But it can be clearer. how about
[05:34] <lifeless> 'if the first publisher does not publish and instead returns None'
[05:35] <wgrant> True.
[05:35] <wgrant> 78+ if id:
[05:35] <wgrant> Do you want to make that explicitly "is None"?
[05:35] <lifeless> I'm torn
[05:36] <lifeless> I'm thinking of rewriting the docs to say 'evaluates nonzero'
[05:36] <wgrant> You need to do one of those.
[05:36] <lifeless> I don't think an oops id of 0 or '' is useful
[05:36] <lifeless> do you ?
[05:37] <wgrant> Not useful, but it's possibly also not useful to special-case them.
[05:37] <lifeless> there is a case for 0 in a single-creator monotonic allocation scheme, but bleh.
[05:37] <lifeless> wgrant: well, they aren't special cased at the moment
[05:37] <lifeless> (other existing code also just tests for if report.get('id'):)
[05:40] <lifeless> wgrant: contributors shouldn't be a wiki page
[05:42] <wgrant> I take it that poolie's +affectingbugs fix landed, then? :)
[05:42] <lifeless> yes
[05:42] <lifeless> wgrant: how hard would it be to switch that to be a blat to lpqa?
[05:45] <wgrant> lifeless: You could just change your subscription regex to exclude it :P
[05:45] <wgrant> But it wouldn't be hard.
[05:47] <StevenK> lpqateam seems like ... the wrong place
[05:47] <lifeless> I am open to any place
[05:48] <lifeless> just wiki seems wrong to me - its not actually an editable page
[05:48] <lifeless> wgrant: so, that review.
[05:48] <lifeless> wgrant: I presume ESHINY happened
[05:50] <wgrant> EMAWSONNEEDSMORERAM
[05:57] <lifeless> I've pushed up fixes around those two points
[05:57] <lifeless> bbiab
[06:18] <poolie> wgrant: and my patch fix it?
[06:19] <wgrant> poolie: Hm?
 I take it that poolie's +affectingbugs fix landed, then? :)
[06:19] <poolie> seems to work for lifeless; that's a good sign
[06:19] <poolie> hm, but not when sorted, oh well
[06:20] <wgrant> No, that shouldn't even be on qastaging yet.
[06:20] <wgrant> lifeless complained about dev.launchpad.net/Contributions
[06:20] <nigelb> whats wrogn with it?
[06:20] <wgrant> I guess lifeless subscribes to the whole wiki.
[06:20] <poolie> oh, i see
[06:20] <poolie> it's through pqm but not yet deployed
[06:20] <nigelb> ohlol
[06:25] <poolie> wbn to have it built in
[06:29] <lifeless> nigelb: its an advert, not shared-editable-docs
[06:32] <nigelb> lifeless: hehe, but its not a qareport either :)
[06:32] <nigelb> Want to get launchpadcontributions.com? :D
[06:32] <lifeless> sure it is; its a blamelist
[06:33] <lifeless> :>
[06:33] <lifeless> this is kindof an ohloh feature
[06:34] <nigelb> not entirely
[06:35] <nigelb> we only measure external contributors.
[06:37] <lifeless> yes, and ?
[06:37] <lifeless> I mean, for 'measure thing about code and contributions' - thats what ohloh have specialised in
[06:38] <lifeless> now, I'm not saying we shouldn't do it ourselves, what with geeknet having bought ohloh (so no longer a neutral web service), but as a feature, thats the space its in
[06:38] <poolie> didn't jml say 'every wiki page is a prototype of a web app'?
[06:38] <lifeless> something very close to that
[06:38] <lifeless> however, this is already not a wiki page ;)
[07:20] <jtv> StevenK, wgrant: the dogfood builders look happy… mind if I try upgrading the codebase, merging my branch, and triggering some builds?
[07:21] <wgrant> jtv: Go ahead.
[07:21] <jtv> OK
[07:55] <mrevell> Guten morgen.
[08:07] <adeuring> good morning
[08:42] <jtv> stub: seen the ongoing work on index-only scans?  Exciting.  Though Simon feels they're nowhere near as useful as people think.
[09:18] <lifeless> mwhudson: I had a q for you actualy :P but now I forget what it was
[09:19] <mwhudson> lifeless: heh, well, you have a few seconds i guess :)
[09:19] <mwhudson> lifeless: i updated https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 on the off chance it was about that
[09:20] <bigjools> wgrant: can you review this please? https://code.launchpad.net/~julian-edwards/meta-lp-deps/add-rabbit-management/+merge/78930
[09:26] <lifeless> rvba: bug 872077 needs an LP task
[09:26] <_mup_> Bug #872077: Import of crosstool-ng from Mercurial fails with unknown revid <Bazaar Hg Plugin:New> <NULL Project:Triaged> < https://launchpad.net/bugs/872077 >
[09:26] <lifeless> rvba: (because it would'nt be fixed if bzr-hg fixed it and we *didn't* deploy a new bzr-hg
[09:29] <wgrant> bigjools: Doesn't it need to be in CAT?
[09:29] <wgrant> bigjools: apt will use the new version if it's there.
[09:29] <bigjools> wgrant: yes, but Tom wanted this ....
[09:29] <rvba> lifeless: ok, thanks.
[09:29]  * bigjools shrugs
[09:29] <wgrant> bigjools: Depending on rabbitmq-management is sufficient.
[09:30] <wgrant> It won't install unless there's a matching version of rabbitmq-server.
[09:30] <wgrant> And that's all we care about.
[09:30] <bigjools> is it worth removing the dep on -server?
[09:30] <wgrant> No.
[09:30] <bigjools> doesn't make any difference :)
[09:30] <wgrant> But there's no point versioning them unless we actually have known version constraints.
[09:30] <bigjools> that's what I thought
[09:30] <wgrant> Which we don't.
[09:31] <bigjools> this is probably being used as a cheating kind of way to figure out if everything was backported to cat properly
[09:32] <wgrant> If rabbitmq-management installs, it has been.
[10:20] <G> hey silly question but the rocketfuel scripts upgrade to a special/newer version of bzr right?
[10:20] <jml> Don't think so.
[10:20] <nigelb> G: check the PPA's it adds?
[10:21] <bigjools> they don't
[10:21] <bigjools> only the bzrlib that LP uses
[10:22] <G> oh so, bzrlib gets changed, as in the one in /usr/lib64/python2.7/dist-packages by any chance?
[10:22] <bigjools> no, the buildout one
[10:22] <G> okay then
[10:23] <wgrant> rocketfuel-setup probably adds a bzr daily PPA.
[10:23] <wgrant> Or maybe only bzr beta.
[10:23] <wgrant> bzr stable, even.
[10:23] <wgrant> BZR_PPA="deb http://ppa.launchpad.net/bzr/ppa/ubuntu ${DISTRIB_CODENAME} main"
[10:24] <G> wgrant: ahhh thanks, yeah, just cehcked my sources.list
[10:25]  * G should get back to tackling a couple of LP bugs, but seem to run into a completely seperate issue first
[10:36] <soren> gmb: Was that topic change intentional?
[10:36] <soren> gmb: All of it, I mean?
[10:37] <G> soren: I think it's a reference to more than 256 crits
[10:37] <G> my observations have been each OCR has a different 'joke' to put there
[10:37] <soren> G: The irc://irc.freenode.grahambinns.com/ bit?
[10:37] <soren> Ok.
[10:38] <G> it nxdomain's so it's not a phishing attempt :)
[10:40] <gmb> soren: Hah, no. I copied and pasted; didn't realise that my IRC client was having a bad day :).
[10:40] <gmb> (Well, probably my proxy...)
[10:41]  * gmb goes to fix it.
[10:41] <soren> It used to say: "| 0:[########Segmentation fault (core dumped)"
[10:41] <soren> oh
[10:42] <soren> gmb: It used to say: "| 0:[########Segmentation fault (core dumped)"
[10:42] <gmb> soren: I see "| 0:[irc://irc.freenode.grahambinns.com/#%23%23%23%23%23%23%23Segmentation fault (core dumped)"
[10:42]  * soren hugs topic-diff.pl
[10:42] <gmb> Is that correct?
[10:42] <gmb> No.
[10:42] <soren> That's what i says now, yes.
[10:43] <bigjools> I'd be happy to see the lame attempt at humour removed
[10:44] <gmb> bigjools: Ah, see, I  couldn't tell it was supposed to be funny, because bip segfaulted yesterday. I thought it was an error.
[10:44]  * gmb removes it.
[10:44] <bigjools> heh
[10:44] <gmb> Whomsoever can be bothered to add a progress bar can add one at their leisure.
[10:45] <soren> "[#-] (not to scale)"
[10:45] <gmb> Heh.
[10:46] <nigelb> lol
[10:46] <bigjools> that's funny :)
[10:48] <nigelb> heh, someone should add that :)
[11:03] <jtv> Argh.  Ayiiee.  Test doubles don't hold up very well across transaction boundaries.
[11:04] <bigjools> wgrant: are you going to approve that meta-lp-deps branch?
[11:04] <wgrant> bigjools: No, I don't agree with it.
[11:05] <wgrant> We care that rabbitmq-management installs.
[11:05] <wgrant> Not what version it is.
[11:05] <bigjools> wgrant: in that case, please reply to RT 48032
[11:05] <wgrant> Sure.
[11:05] <bigjools> thanks
[11:06]  * lifeless deletes tests that test operational config.
[11:07] <bigjools> !
[11:08] <lifeless> bigjools: oops-tools have tests that there is a particular summary report; the summary reports for an install are done by pointing and clicking in the admin interface, *or* by a django migration
[11:08] <lifeless> it should be clear that the latter isn't relevant to trunk :)
[11:13] <wgrant> bigjools: Done.
[11:13] <bigjools> thanks
[11:42] <bigjools> bin/test is now segfaulting ...
[11:42] <lifeless> \o/
[11:42] <lifeless> I'm sorry Dave, I can't let you test that!
[11:43] <bigjools> :)
[11:55] <bigjools>   Set up canonical.testing.layers.LibrarianLayer in 23.685 seconds.
[11:55] <lifeless> 3 tests to go. Tomorrow's task.
[11:55] <bigjools> *cry*
[11:56] <bigjools> TDD is painful with LP, really painful :(
[11:57] <bigjools> hmmm bin/test is segfaulting on oneiric and natty
[11:57]  * nigelb screenshots and frames.
[12:09] <lifeless> theory: there are no new bugs, only more or less obvious duplicates
[12:10] <nigelb> Well, that depends on the kind of bugs already filed.
[12:10] <nigelb> If you file a bug saying -  "LP sucks", everything can dup to it :P
[12:10] <nigelb> I believe there's always edge cases and newer ways to break things.
[12:16] <wgrant> bigjools: Do you think someone from your squad might be able to look at bug #872086 soon?
[12:16] <_mup_> Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872086 >
[12:16] <wgrant> bigjools: It only appeared yesterday, but causes appservers to be useless for three minutes, and cronspam.
[12:17] <bigjools> I'll schedule it
[12:17] <wgrant> Thanks.
[12:18] <bigjools> googlebot... awesome
[12:18] <wgrant> Yep.
[12:18]  * bigjools → lunch
[12:24] <allenap> gmb: I've got a nice branch lined up for you :) I lie, it's not nice. (It's not that bad either.) Are you interested? https://code.launchpad.net/~allenap/launchpad/bug-stats-key-error-bug-871076/+merge/78870
[12:24] <gmb> allenap: Sure.
[12:25] <allenap> Thanks.
[13:17] <rvba> adeuring: Hi, can I ask you a quick question about the code in lib/canonical/launchpad/webapp/batching.py?
[13:17] <adeuring> rvba: sure
[13:17] <rvba> I know you've been working in this area lately.
[13:18] <rvba> adeuring: If you go to the definition of reverseSortOrder in that file,
[13:18] <rvba> In there there is a sub function called invert_sort_expression
[13:18] <adeuring> yes
[13:18] <adeuring> morning deryck
[13:18] <deryck> Morning, adeuring
[13:18] <rvba> The parameter name is 'expr' but it manipulates 'expression'.
[13:19] <rvba> adeuring: Maybe I'm seeing straight but why is it not a problem? :)
[13:19] <rvba> I'm not* seeing straight even
[13:21] <adeuring> rvba: i think you are right: s/expression/expr/ would make the function look much more sane. but let me check a bit more...
[13:21] <rvba> adeuring: Thanks for looking into it, I just randomly came across that code and it looked strange ;)
[13:22] <adeuring> rvba: yes, the code is ismply nonsense. I am a bit surprised that it worked at all...
[13:22] <adeuring> rvba: thanks for spotting this!
[13:22] <rvba> I confess I was surprised too.
[13:22] <rvba> You're welcome.
[13:24] <rvba> adeuring: The only solution for this to work is that this code is never called :)
[13:25] <adeuring> rvba: well, it is called in __init__()
[13:25] <rvba> Indeed.
[13:27] <adeuring> rvba: >>> [x for x in range(2)]
[13:27] <adeuring> [0, 1]
[13:27] <adeuring> >>> x
[13:27] <adeuring> 1
[13:27] <adeuring> so, expression is visible to the function
[13:27] <adeuring> but that's purely accidental..
[13:27] <rvba> I see, well spotted.
[13:34] <deryck> abentley, adeuring -- https://dev.launchpad.net/Projects/CustomBugListings
[13:49] <gmb> allenap: approved with some comments
[13:52] <bigjools> gmb: when we do an expiration countdown for incomplete bugs, how does that work when say only one of the tasks is incomplete?
[13:55] <gmb> bigjools: I have no idea, I'm afraid. You would hope that the countdown would only appear for the bug in that context, but I don't know whether that's the case or not.
[13:56] <bigjools> gmb: the countdown is bug-wide it seems, so ...
[13:56] <bigjools> well let me explain
[13:56] <bigjools> see these 2 bugs
[13:56] <bigjools> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/849414
[13:56] <_mup_> Bug #849414: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() <apport-crash> <bugpattern-needed> <i386> <oneiric> <rls-mgr-p-tracking> <plymouth (Ubuntu):Incomplete> <plymouth (Ubuntu Oneiric):Incomplete> <plymouth (Ubuntu Precise):Incomplete> < https://launchpad.net/bugs/849414 >
[13:56] <bigjools> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745
[13:56] <_mup_> Bug #553745: plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() <apport-collected> <apport-crash> <bugpattern-written> <i386> <iso-testing> <lucid> <maverick> <oneiric> <patch-forwarded-upstream> <rls-mgr-p-tracking> <Plymouth:Confirmed> <plymouth (Ubuntu):Incomplete by canonical-foundations> <plymouth (Ubuntu Lucid):Triaged by canonical-foundations> <plymouth (Ubuntu Maverick):Triaged by canonical-foundations> <plymouth (Ubuntu Natt
[13:56] <bigjools> the former has got "expiration in 59 days"
[13:56] <bigjools> the latter has not, despite it having 2 incomplete tasks
[13:57] <bigjools> I don't know if this is a bug - just looking to triage something
[13:57]  * gmb looks
[13:59] <gmb> bigjools: I don't think it's a bug. See the conditions on https://help.launchpad.net/BugExpiry.
[13:59] <gmb> The latter has been assigned to someone (several someones) so it doesn't count for expiry.
[13:59] <bigjools> ah ok
[13:59]  * gmb didn't know those conditions until just now :)(
[14:00] <bigjools> heh, thanks for finding them, I didn't know that page was there
[14:01] <allenap> gmb: Thanks!
[14:01] <gmb> bigjools: Nor did I. There's a (find out why) link in the expiry notice, but I only spotted it the third time I looked at the bug.
[14:02] <bigjools> hidden in plain sight
[14:12]  * gmb -> late lunch
[14:21] <abentley> deryck, adeuring: allenap presented mustache: http://mustache.github.com/
[14:21] <adeuring> abentley: thanks!
[14:27] <abentley> deryck, adeuring: They call it logic-less templates, but thankfully, they're lying; they support loops and conditionally-rendered blocks.
[14:27] <deryck> abentley, yeah, I thought the same thing when I saw the guy from Yahoo.
[14:33] <cr3> has anyone ever felt the need to check code before committing for code that might've been left around when exploring? I know that bin/lint in launchpad runs pocketlint which would detect things like pdb statements left behind by accident, but could it detect other things like behind perhaps identified with a TODO or FIXME comment?
[14:35] <sinzui> cr3, Given the large number of those plus XXX: comments those will be spurious warnings
[14:36] <sinzui> cr3, I think a switch is needed to support those kinds of comments so that they only warn when you want to get rid of them
[14:36] <cr3> sinzui: I'm thinking dedicating a particular keyword for warnings that should not be committed, so perhaps keeping XXX and only warning about TODO for example
[14:36] <bigjools> TODO would be one I'd be interested in
[14:37] <bigjools> I use TODO markers a lot, the bzr "todo" plugin is great
[14:38] <cr3> sinzui: I've often reviewed merge requests, noticed some weird code, commented on the request only to find out some code was left behind by accident. This has a long turnaround time and I wouldn't be surprised it happens regularly, so might be worth considering.
[14:38]  * jml accepts donations
[14:38] <cr3> bigjools: hm, that might be exactly what I'm looking for. thanks!
[14:39] <bigjools> jml: :D
[14:43] <sinzui> cr3, We see them in reviews and ask why the issue in the comment was not address. We often require a bug reported about the issue if the work is incomplete.
[14:44] <sinzui> cr3, I think a lot of those kinds of comments are spurious, which is what I think your concern is. Lp has a lot of such comments because the issue described in the comment is not important.
[14:59] <danilos> hum, anybody using balsamiq in oneiric?
[15:02] <sinzui> danilos, I was
[15:02]  * sinzui checks if it still works
[15:03] <sinzui> danilos, my old 32bit installation of air + MockupsForDesktop_1_6_50.air works
[15:04] <bigjools> jelmer: any idea why this import is failing? https://code.launchpad.net/~tillkruess/humanstxt-wp-plugin/trunk
[15:05] <jelmer> bigjools: the repository contains invalid data, which isn't properly encoded and makes us unable to access all history
[15:05] <bigjools> jelmer: ok thanks
[15:06] <danilos> sinzui, right, I guess I'll have to investigate the 32-bit installation which has changed in oneiric then
[15:18] <jml> so, you guys test javascript without a browser, right? how do you do that?
[15:18] <jml> (and would it work for jquery code?)
[15:23] <abentley> deryck, abel: random thought: mustache rendering would need to use the web service object representation to be reusable, so the server-side implementation could be a web service-consuming micro-service.
[15:29] <deryck> abentley, thinking through that statement…. sorry was on call.
[15:30] <deryck> abentley, so stepping into the territory of "web service consuming micro service" from "another tempting option" makes me slightly nervous.
[15:30] <abentley> deryck: is just random thought.
[15:30] <deryck> abentley, mostly due to keeping this scoped right to deliver on time.
[15:31] <deryck> abentley, right.  I'm fine with that as the next logical step for this.
[15:44] <bigjools> jelmer: is there anything they can do to fix it, BTW?
[15:45] <jelmer> bigjools: removing the invalid data from the repository, which stops the svn libraries from falling over
[15:45] <jelmer> bigjools: that's a fairly intrusive process though, which requires taking the repository offline
[15:45] <bigjools> jelmer: how can they find out what's invalid? It wasn't obvious to me from the log
[15:46] <jelmer> bigjools: the first available revision is 108326, so most likely 108325 is problematic
[15:46] <bigjools> jelmer: ah a bad revision.... gotcha
[15:46] <bigjools> thanks jelmer
[15:47] <jelmer> bigjools: svn itself falls over too:
[15:47] <jelmer> svn log -v --xml --with-all-revprops http://plugins.svn.wordpress.org/ -r108325
[15:48] <bigjools> heh
[16:28] <cr3> why does launchpad say that my project has three open bugs in the right-hand summary when there are only two in the main listing: https://bugs.launchpad.net/launchpad-results/+bugs
[16:28] <jelmer> cr3: IIRC that's the result of caching - could it be that there were 3 open bugs a while ago?
[16:29] <cr3> jelmer: there were probably more but I'll wait 24 hours to see if the cache gets refreshed correctly
[16:29] <cr3> jelmer: caching is hard to get right :(
[16:29] <jelmer> cr3: yes, and arguably it's not really useful to cache this kind of thing if there are only 3 results
[16:31] <jelmer> cr3: btw, is launchpad-results the result of the speccing you were doing earlier to store subunit results in Launchpad?
[16:31] <cr3> jelmer: yep, https://dev.launchpad.net/LEP/ResultsTracker
[16:32] <cr3> jelmer: you were actually a use case on that LEP but the primary use case because the Ubuntu Friendly programme: https://wiki.ubuntu.com/UbuntuFriendly/Website
[16:33] <cr3> s/because/became/
[16:34] <jelmer> cr3: ah, neat!
[16:34] <jelmer> I should have a closer look at it some time
[16:35] <cr3> jelmer: here's a temporary EC2 instance that has some interesting data already: http://<IP_ADDRESS>/
[16:35] <cr3> jelmer: the /systems page has almost 2000 models submitted by the community, so it's getting fun to look at
[16:43] <jelmer> cr3: wow, that's really nice
[16:43] <jelmer> cr3: how do the submissions work, is it subunit based or something else?
[16:48] <cr3> jelmer: that information comes from the launchpad hardware database which only stores checkbox submission files. if you happen to have a bunch of subunit files, those could be uploaded as well
[16:51] <jelmer> cr3: ah, cool
[16:52] <cr3> jelmer: I'd also like to support the document format from the linaro team and junit commonly used in hudson/jenkins so that they could all be piped into the results tracker... all your tests are belong to us
[16:53] <jelmer> bzr (and the bzr plugins) and samba generate subunit so if that's somehow supported that's great
[16:53] <cr3> jelmer: oh, another project would be to probe the bugs in launchpad for those reported by apport to create system entries in the results tracker too
[16:54] <bigjools> night all
[16:54] <jelmer> have a nice evening bigjools
[18:12] <abentley> deryck: Where I've gotten so far with Mustache: http://people.canonical.com/~abentley/mustache.png
[18:13] <deryck> abentley, very nice.
[18:13] <deryck> working from mockups is so nice :)
[18:15] <abentley> deryck: indeed.
[18:20] <lifeless> morning
[18:22] <deryck> Morning, lifeless
[20:23] <mwhudson> benji: did you see my update to https://code.launchpad.net/~mwhudson/launchpad/permit_timeout_from_features-on-participation-bug-861510/+merge/78355 ?
[20:23] <benji> mwhudson: I hadn't.  Thanks for pointing it out.
[20:56] <benji> mwhudson: I've responded to the MP (with approval).
[20:56] <mwhudson> benji: \o/ thanks
[20:56] <mwhudson> (it passed ec2 overnight btw)
[21:14] <bdmurray> There was some work done on Incomplete searches recently right?
[21:16] <bdmurray> using the API and search for "Incomplete" as a status used to return those with and without a response
[21:16] <bdmurray> it no longer does this and just returns 0
[21:17] <lifeless> there was yes
[21:17] <lifeless> hum
[21:17] <lifeless> please file a bug
[21:17] <bdmurray> is bug 872496 sufficient?
[21:17] <_mup_> Bug #872496: All package stats now report zero "Incomplete" bug reports <Launchpad itself:New> <Ubuntu QA Website:New> < https://launchpad.net/bugs/872496 >
[21:18] <lifeless> its arguably a regression (but since its inconsistent with bug searches outside the API, its arguably just a harmonisation and correct)
[21:18] <bdmurray> inconsistent how?
[21:19] <lifeless> look at the advanced bug search form
[21:19] <lifeless> there are two incomplete statuses there, and no unified one
[21:21] <bdmurray> so I should rewrite all my searches to use incomplete with and incomplete without?
[21:22] <lifeless> bdmurray: well, theres no reason we can't restore the old behaviour; I'm surprised it broke in fact :(
[21:22] <lifeless> but yes, it would be more precise to search with both states
[21:22] <lifeless> and it may work immediately if you do so
[21:35] <lifeless> sinzui: hi
[21:36] <lifeless> sinzui: I'll try to catch up with you later, today I'm making up for a fragmented day yesterday, but am kindof here
[21:40] <kb9vqf> Quick question--what is the easiest way to turn off debugging stack traces on a production instance of Launchpad?
[21:40] <kb9vqf> usually they appear when a user fumble-fingers a URL
[22:08] <wgrant>  kb9vqf canonical.show_tracebacks is the setting.
[22:13] <kb9vqf> wgrant: In which file?
[22:13] <wgrant> kb9vqf: launchpad-lazr.conf in the config that you're using.
[22:13] <kb9vqf> ok, thanks again! :)


[02:15] <arraybolt3> Possibly weird question, I'm building a debian/copyright file, what do I do when I hit a license that is clearly *supposed* to be a particular well-known license, but that has a bunch of modifications that look like they were either accidental (person trying to type the license from memory maybe?) or for the sake of making it look nicer? I've hit a file with a BSD 3-clause license, but...
[02:16] <arraybolt3> ...they keep omitting the word "above" when talking about the "above copyright notice", and it replaces "Neither the name of the copyright holder nor the names of its contributors may be used" with "The name of the author may not be used".
[02:16] <arraybolt3> Also "THE COPYRIGHT HOLDERS AND CONTRIBUTORS" gets replaced with "THE AUTHOR".
[20:29] <Eickmeyer[m]> vorlon: Thanks for taking-on the frescobaldi issue. We had someone mistakingly roping-in the Ubuntu Studio ML on it when we don't seed that package. I'd have gladly done it just as a measure of goodwill but ERR:Time.
[21:00] <vorlon> Eickmeyer[m]: no worries
[21:59] <arraybolt3[m]> Random licensing question - is it legal to include a GPL-2+ source code file in a repo that is LGPL-2.1+? Or does that make it so that the whole repo is actually GPL-2+? I'm pretty sure the latter is true, and if so, I have a bit of a mess to untangle.
[22:01] <juliank> arraybolt3[m]: it makes the stuff that uses it (or rather it forms a combined work with) gpl-2+
[22:02] <arraybolt3[m]> Sigh. Yeah, that's what I thought.
[22:02] <juliank> > In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
[22:03] <juliank> but yeah if it's like C code you link into your library you're sol
[22:09] <arraybolt3[m]> Yep. Alright, guess I have some problems to deal with then.
[22:54] <vorlon> rbasak: why is wike not in git-ubuntu? (sru currently in the queue)
[22:58] <rbasak> vorlon: I'll do that manually for you now.
[22:59] <vorlon> that wasn't the question! :)
[22:59] <rbasak> :)
[22:59] <vorlon> rbasak: I've already accepted the SRU :)
[22:59] <rbasak> The reason is that the code change that imports everything hadn't landed yet. Prior to that it was only packages that existed at the time I imported everything.
[22:59] <vorlon> ah
[23:00] <rbasak> That MP is now Approved but I'm on vacation for a week now. I'll put it into production when I get back.
[23:00] <rbasak> I'll leave wike for now then.
[23:01] <rbasak> So to be clear, everything that is already imported will continue being updated. Anything new that's not in main needs manually importing once, which I've already done for packages that existed at the time.
[23:01] <rbasak> When I land the MP to fix this, I'll catch up everything new since that point, and then we should be good.
[23:01] <vorlon> got it, thanks
[23:04] <rbasak> Oh and there are some exceptional packages that have edge case import failures. ~50. I've been working on whittling those down.