=== Logan is now known as y
=== y is now known as Logan
[08:45] <mpt> Is there any way to see the current translation for a particular string in every available language?
[08:46] <wgrant> mpt: There is not.
[08:56] <mpt> ah, pity
=== G_ is now known as G
[10:04] <Laney> cjwatson: Do you know about situations like https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-008/+build/7714108? Seems to be waiting for libmedia-dev despite the arch restriction.
[10:05] <cjwatson> Laney: known bug which I spent most of yesterday yak-shaving on
[10:06] <cjwatson> and which will probably continue to consume my time today :-(
[10:06] <Laney> OK :(
[10:06] <Laney> No problem if I just mash the button then?
[10:07] <cjwatson> Laney: will it make any difference?  the other dependencies would have been removed from the list if they were satisfied now
[10:07] <cjwatson> (modulo cronjob)
[10:08] <cjwatson> Laney: oh, of course, they won't because the same bug crashes retry-depwait
[10:08] <cjwatson> Laney: sure, go ahead and mash button
[10:09] <Laney> Ha. Yeah, they should be satisfied.
[10:09] <Laney> mushed
=== JanC_ is now known as JanC
=== hloeung_ is now known as hloeung
[13:38] <teward> is there a way i can break the bugcheck logic for a linked upstream bug on one case to force it to "Won't Fix" status due to the broken bugtracker logic (https://bugs.launchpad.net/launchpad/+bug/1413304)
[13:38] <ubot5> Ubuntu bug 1413304 in Launchpad itself "[Bugtracker - Debian] Done+WontFix (whether 'fixed' or not after the fact) in Debian marked as 'Fix Released'" [Low,Triaged]
[13:40] <teward> or, where in the LP code should I look at for that so I can propose a patch?
[13:46] <cjwatson> lib/lp/bugs/externalbugtracker/debbugs.py + lib/lp/bugs/externalbugtracker/tests/test_debbugs.py (assuming you mean to fix the statuses rather than bodging around them)
[13:48] <cjwatson> follow https://dev.launchpad.net/Running/LXC to set up a dev instance, make a branch, 'utilities/link-external-sourcecode && make', and then you can do 'bin/test -vvct lp.bugs.externalbugtracker.tests.test_debbugs'
[13:49] <cjwatson> after that, given that these tests seem quite easy to extend, I'd recommend writing tests that enforce your improved behaviour specification first, checking that the new tests fail, and then fixing code until they pass
[13:54] <mapreri> aka TDD
[14:01] <cjwatson> Indeed.  Sometimes in LP it's unreasonably difficult to do things that way, but it would work well here and I think would actually be easier for a newcomer to the codebase.
[14:15] <teward> cjwatson: yes, i meant 'fix the statuses'
=== [HeOS] is now known as HeOS