| === Ursinha is now known as Ursinha-away | ||
| 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:43 |
| 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 | 05:44 |
| 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:08 |
| 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 | 06:09 |
| === 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 | ||
| 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 |
| ubot5 | Ubuntu bug 925895 in light-themes (Ubuntu Precise) "Ambiance sub-menus light like Radiance after latest light-themes update." [High,Invalid] | 09:59 |
| czajkowski | feasty: what do you mean? | 09:59 |
| 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:00 |
| 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:01 |
| czajkowski | I'll poke someone on unity | 10:02 |
| feasty | Cheers | 10:02 |
| 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:20 |
| 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). | 10:24 |
| === 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 | ||
| adeuring | abentley: yes. | 14:54 |
| adeuring | where is the problem? | 14:54 |
| 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:55 |
| abentley | So I recommend using %r in the "Running" message, using class name in job_str, and defining a proper default repr. | 14:56 |
| 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:57 |
| 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:58 |
| sinzui | adeuring, I think persontransferjob and productjob also use classname in __repr__ | 14:59 |
| 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:00 |
| adeuring | abentley: ok, the we can simply delet job_str, I think | 15:01 |
| adeuring | abentley: ah, no, it's still used in one place | 15:02 |
| adeuring | but we could use '%r' % job there too | 15:02 |
| 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:03 |
| abentley | adeuring: runJob emits "Running %s in status %s" and runJobHandleError emits "Running %r" | 15:04 |
| 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:07 |
| abentley | adeuring: Sure. | 15:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| adeuring | ok | 15:13 |
| 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:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| ujjain | Does Launchpad really have to approve my pot files? | 15:30 |
| czajkowski | ujjain: yes in some cases | 15:31 |
| czajkowski | but it's done very regularly | 15:31 |
| ujjain | Launchpad still puzzles me. | 15:32 |
| ujjain | It seems imported, thanks. | 15:32 |
| ujjain | Can I keep reuploading pot files without losing translations from previous pot files? | 16:00 |
| === matsubara is now known as matsubara-lunch | ||
| ujjain | How can I delete a translation import? | 16:24 |
| ujjain | it keeps saying Translated so far: 0% | 16:49 |
| 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:50 |
| ubot5 | Ubuntu bug 459418 in lazr.restfulclient "Cache is not safe for concurrent use (by processes or threads)" [High,In progress] | 16:50 |
| 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 | 16:51 |
| === zyga is now known as zyga-food | ||
| === zyga-food is now known as zyga | ||
| === matsubara-lunch is now known as matsubara | ||
| 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. | 19:09 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!