=== Ursinha is now known as Ursinha-away [05:43] is there a way to list the packages at a ppa that are superseded by a newer ones at ubuntu? [05:43] like https://launchpad.net/~linaro-maintainers/+archive/overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=oneiric [05:43] the package lightdm [05:43] there's a (Newer version available) at it's name [05:43] looking to automate that with launchpadlib [05:44] 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] just wonder how that is done at the launchpad ppa interface [06:08] rsalveti: apt/dpkg version comparison is what you need [06:08] there isn't a magic search no [06:08] (at least, I don't think there is) [06:09] lifeless: guess I could iterate over the source package names and compare with the latest from same series at ubuntu [06:09] it's not optimal, but works [06:09] derived distributions can do it very nicely, but that is separate to ppas [06:09] yeah === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm [09:59] 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] Ubuntu bug 925895 in light-themes (Ubuntu Precise) "Ambiance sub-menus light like Radiance after latest light-themes update." [High,Invalid] [09:59] feasty: what do you mean? [10:00] 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] Their comments arent related and this bug is being dismissed when it's a legit bug! [10:01] Or at least appears to be... [10:02] I'll poke someone on unity [10:02] Cheers [10:20] 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] 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). === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === jtv is now known as mup === mup is now known as jtv === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === Ursinha-away is now known as Ursinha === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === wedtm is now known as wedtm|away === yofel_ is now known as yofel [14:54] abentley: yes. [14:54] where is the problem? [14:55] 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] adeuring: The problem is that job_str is used elsewhere, and that makes you reluctant to define a proper default repr. [14:56] So I recommend using %r in the "Running" message, using class name in job_str, and defining a proper default repr. [14:57] 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] abentley: no, we should not use the class name. Look at lib/lp/registry/tests/test_process_job_sources_cronjob.py [14:58] abentley: lines 10 and 19 in the diff [14:58] abentley: 'about ~murdock in ~a-team; status=Waiting>') [14:58] abentley: that's why I want to use __repr__ in job_str [14:59] adeuring, I think persontransferjob and productjob also use classname in __repr__ [15:00] sinzui: right, I think that's fine [15:00] 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] abentley: ok, the we can simply delet job_str, I think [15:02] abentley: ah, no, it's still used in one place [15:02] but we could use '%r' % job there too [15:03] adeuring: I'm a bit confused about what you've done here. Have you consolidated two messages into one? [15:03] abentley: which two messages? [15:04] adeuring: runJob emits "Running %s in status %s" and runJobHandleError emits "Running %r" [15:07] 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] abentley: but can we first finish the discussion about job_str, __repr__, and related log messages? [15:08] adeuring: Sure. [15:09] So, now that I understand the runJobHandleError message is gone, ISTM that the runJob message must contain the job id. [15:09] And it also makes sense to use the repr in that message. [15:09] 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] abentley: right, that's the poit [15:10] adeuring: Sure, we can kill two birds with one stone by using the repr in job_str. [15:11] 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] abentley: as I said, I don't mind to change the __repr__ of class Job in lazr.jobrunner to show just instead [15:12] adeuring: Okay, great. [15:12] adeuring: let's do that, then. [15:13] ok [15:18] 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] abentley: right. But taht we be a bit difficult to test in lazr.jobrunner itself. [15:19] (without pulling in STorm) [15:19] adeuring: testing it in Launchpad would be fine. [15:21] 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] adeuring: Your branch makes Launchpad start using lazr.jobrunner, so they introduce a regression into Launchpad. [15:22] abentley: ak, right I swapped the two braches (LP main and the lazr one) mentally [15:30] Does Launchpad really have to approve my pot files? [15:31] ujjain: yes in some cases [15:31] but it's done very regularly [15:32] Launchpad still puzzles me. [15:32] It seems imported, thanks. [16:00] Can I keep reuploading pot files without losing translations from previous pot files? === matsubara is now known as matsubara-lunch [16:24] How can I delete a translation import? [16:49] it keeps saying Translated so far: 0% [16:50] 90 untranslated. [16:50] 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:50] Ubuntu bug 459418 in lazr.restfulclient "Cache is not safe for concurrent use (by processes or threads)" [High,In progress] [16:51] rick_h, I didn't, but my script runner got stuck in an infinate loop which may have caused the isssue [16:51] ah, ok then === zyga is now known as zyga-food === zyga-food is now known as zyga === matsubara-lunch is now known as matsubara [19:09] 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. === epsy is now known as \u03b5 === wedtm|away is now known as wedtm === matsubara is now known as matsubara-afk === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm === mwhudson_ is now known as mwhudson === wedtm is now known as wedtm|away === wedtm|away is now known as wedtm