[05:43] <rsalveti> is there a way to list the packages at a ppa that are superseded by a newer ones at ubuntu?
[05:43] <rsalveti> like https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=oneiric
[05:43] <rsalveti> the package lightdm
[05:43] <rsalveti> there's a (Newer version available) at it's name
[05:43] <rsalveti> looking to automate that with launchpadlib
[05:44] <rsalveti> but the package status at the ppa is still Published, what makes sense, but didn't see an easy way to match with the package version available at ubuntu
[05:44] <rsalveti> just wonder how that is done at the launchpad ppa interface
[06:08] <lifeless> rsalveti: apt/dpkg version comparison is what you need
[06:08] <lifeless> there isn't a magic search no
[06:08] <lifeless> (at least, I don't think there is)
[06:09] <rsalveti> lifeless: guess I could iterate over the source package names and compare with the latest from same series at ubuntu
[06:09] <rsalveti> it's not optimal, but works
[06:09] <lifeless> derived distributions can do it very nicely, but that is separate to ppas
[06:09] <rsalveti> yeah
[09:59] <feasty> Is anyone able to moderate bug report? There's a couple of idiots messing one up: https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/925895
[09:59] <czajkowski> feasty: what do you mean?
[10:00] <feasty> Look at the last comments. Theyre just swearing, arguing and not concentrating on the actual bug. Theyre setting it to invalid then to incomplete, then invalid because theyre ididots
[10:01] <feasty> Their comments arent related and this bug is being dismissed when it's a legit bug!
[10:01] <feasty> Or at least appears to be...
[10:02] <czajkowski> I'll poke someone on unity
[10:02] <feasty> Cheers
[10:20] <czajkowski> feasty: there is no spam on the bug, there is a discussion happening, you can change your bug mail on the bug so you don't see the notifications
[10:24] <feasty> I'm not worried about the mail but people were messing with it's status. The discussion was declining into something irrelevant, that is all. I just didn’t want the report to become disregarded because of it :o).
[14:54] <adeuring> abentley: yes.
[14:54] <adeuring> where is the problem?
[14:55] <adeuring> abentley: look at lib/lp/registry/tests/test_process_job_sources_cronjob.py , or the diff for that file. The tests are about the log messages
[14:55] <abentley> adeuring: The problem is that job_str is used elsewhere, and that makes you reluctant to define a proper default repr.
[14:56] <abentley> So I recommend using %r in the "Running" message, using class name in job_str, and defining a proper default repr.
[14:57] <adeuring> abentley: I don't mind to change __repr__ in lazr.jobrunner -- i did not dio it yet out of lazyness because it requires additional changes to the tests in lazr.jobrunner. but it not a rela problem for me to makle them
[14:57] <adeuring> abentley: no, we should not use the class name. Look at lib/lp/registry/tests/test_process_job_sources_cronjob.py
[14:58] <adeuring> abentley:  lines 10 and 19 in the diff
[14:58] <adeuring> abentley: 'about ~murdock in ~a-team; status=Waiting>')
[14:58] <adeuring> abentley: that's why I want to use __repr__ in job_str
[14:59] <sinzui> adeuring, I think persontransferjob and productjob also use classname in __repr__
[15:00] <adeuring> sinzui: right, I think that's fine
[15:00] <abentley> adeuring: lines 10 and 19 are "Running" lines.  I suggested changing Running messages to use %r, as they have previously.  Then changes to job_str would not affect them.
[15:01] <adeuring> abentley: ok, the we can simply delet job_str, I think
[15:02] <adeuring> abentley: ah, no, it's still used in one place
[15:02] <adeuring> but we could use '%r' % job there too
[15:03] <abentley> adeuring: I'm a bit confused about what you've done here.  Have you consolidated two messages into one?
[15:03] <adeuring> abentley: which two messages?
[15:04] <abentley> adeuring: runJob emits "Running %s in status %s" and runJobHandleError emits "Running %r"
[15:07] <adeuring> abentley: right. I did not see the point to have the separate message from runJobHandleError() in the old implementation. The next one from runJob() will follow immediately
[15:07] <adeuring> abentley: but can we first finish the discussion about job_str, __repr__, and related log messages?
[15:08] <abentley> adeuring: Sure.
[15:09] <abentley> So, now that I understand the runJobHandleError message is gone, ISTM that the runJob message must contain the job id.
[15:09] <abentley> And it also makes sense to use the repr in that message.
[15:09] <adeuring> abentley: personally, I don't have any real pinion if we should use job_str or __repr__ directly to log things, but job_str has the advatage to add the job ID
[15:10] <adeuring> abentley: right, that's the poit
[15:10] <abentley> adeuring: Sure, we can kill two birds with one stone by using the repr in job_str.
[15:11] <abentley> adeuring: If you want to use a weird repr in order to land your code, that's okay with me, as long as we fix it later.
[15:12] <adeuring> abentley: as I said, I don't mind to change the __repr__ of class Job in lazr.jobrunner to show just <Job> instead
[15:12] <abentley> adeuring: Okay, great.
[15:12] <abentley> adeuring: let's do that, then.
[15:13] <adeuring> ok
[15:18] <abentley> adeuring: I don't want to land ~adeuring/launchpad/lp-lazr.jobrunner until we're sure runJobHandleError has not regressed in handling database errors.  I think we need a test for that.
[15:19] <adeuring> abentley: right. But taht we be a bit difficult to test in lazr.jobrunner itself.
[15:19] <adeuring> (without pulling in STorm)
[15:19] <abentley> adeuring: testing it in Launchpad would be fine.
[15:21] <adeuring> abentley: but... the issues with runKobHandleError are already in lazr.jobrunner/trunk, I think, and my most recent branch does not affect the known problem
[15:22] <abentley> adeuring: Your branch makes Launchpad start using lazr.jobrunner, so they introduce a regression into Launchpad.
[15:22] <adeuring> abentley: ak, right I swapped the two braches (LP main and the lazr one) mentally
[15:30] <ujjain> Does Launchpad really have to approve my pot files?
[15:31] <czajkowski> ujjain: yes in some cases
[15:31] <czajkowski> but it's done very regularly
[15:32] <ujjain> Launchpad still puzzles me.
[15:32] <ujjain> It seems imported, thanks.
[16:00] <ujjain> Can I keep reuploading pot files without losing translations from previous pot files?
[16:24] <ujjain> How can I delete a translation import?
[16:49] <ujjain> it keeps saying Translated so far: 0%
[16:50] <ujjain> 90 untranslated.
[16:50] <rick_h> jono: ping, did you ever figure out what was up with your download cache from using the api the other day? Wonder if this is the issue: https://bugs.launchpad.net/lazr.restfulclient/+bug/459418
[16:51] <jono> rick_h, I didn't, but my script runner got stuck in an infinate loop which may have caused the isssue
[16:51] <rick_h> ah, ok then
[19:09] <pfarrell> on https://code.launchpad.net/~libadjoint/+recipe/dolfin-adjoint-daily: is it possible to delete the ones going to "AMCG packaging"? I started them by accident.