[07:14] <syq> who can help me to import a po for simple-scan?
[07:14] <syq> https://translations.launchpad.net/simple-scan/trunk/+imports
[07:17] <wgrant> syq: You'll need to talk to the project maintainer, https://launchpad.net/~simple-scan-team
[09:41] <mwhudson> silly recipe q time again
[09:41] <mwhudson> the package version gets e.g. ~ubuntu16.04.1 appended to it
[09:42] <mwhudson> where does the .1 in that come from?
[09:42] <cjwatson> haha
[09:42] <cjwatson> you're going to love this
[09:42] <cjwatson> buildrecipe:            '--append-version', '~ubuntu%s.1' % distroseries_version,
[09:43] <cjwatson> I assume it's just so that it's obvious that if you need to bump it manually for some reason then you can change it to .2, or something.
[09:44] <mwhudson> cjwatson: how very scientific
[09:44] <mwhudson> i was naively/stupidly hoping it would get incremented for each recipe build or something
[09:44] <mwhudson> even though that doesn't make a great deal of sense
[09:47] <cjwatson> I fear not.  You can always make your recipe build version include a timestamp or similar.
[10:10] <mwhudson> cjwatson: i'm probably being dense again but: eh? https://launchpadlibrarian.net/251972218/buildlog.txt.gz
[10:10] <mwhudson> recipe: https://code.launchpad.net/~mwhudson/+recipe/golang-1.4
[10:12] <cjwatson> Hm.
[10:13] <cjwatson> That is not obvious, but I'll have to fetch the repositories in order to debug it.
[10:13]  * cjwatson gets coffee and goes back to the ethernet connection
[10:13] <mwhudson> cjwatson: oh maybe it's because only part of the packaging branch is nested?
[10:13] <mwhudson> so there is no debian/changelog in that part of it
[10:13] <mwhudson> (only /changelog)
[10:13]  * mwhudson guesses wildly and goes to have a shower
[10:14] <cjwatson> Hm, possible.
[10:15] <cjwatson> Yeah, very possible.
[10:15] <cjwatson>     show_process = subprocess.Popen(
[10:15] <cjwatson>         ["git", "-C", child_branch._get_git_path(),
[10:15] <cjwatson>          "show", "%s:debian/changelog" % child_branch.get_revspec()],
[10:15] <cjwatson>         stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
[10:15] <cjwatson> Not sure how best to fix that.
[10:26] <mwhudson> cjwatson: and by this point the branch has been mutilated?
[10:27] <mwhudson> anyway i can just put the version in the recipe for now for my slightly strange use case
[10:27] <cjwatson> Not about mutilation, it's that the file never existed in that particular branch with that name.
[10:27] <cjwatson> I agree that putting the version in the recipe is the easiest workaround.
[11:29] <jaksi07c8> hi
[11:30] <jaksi07c8> is there a way to use gcc-5 when building something for trusty in a PPA?
[11:31] <jaksi07c8> I'm trying to build a KASan-enabled kernel for Trusty, but KASan requires gcc>=5, and trusty has gcc 4.8 by default
[11:32] <jaksi07c8> i've added ppa:ubuntu-toolchain-r/test as a PPA dependency and gcc>=5 as a package dependency, the builder installs gcc-5, but still uses 4.8 to build the package
[11:35] <cjwatson> You'll need a new gcc-defaults somewhere as well.
[11:37] <rbasak> I get timeout errors trying to mass delete ~70 packages from a PPA. Is this ever expected to work? Is there a better way?
[11:38] <rbasak> eg. OOPS-7f2d9fc214a7d52b3b85ed006d09e230
[11:38] <ubot5`> https://oops.canonical.com/?oopsid=OOPS-7f2d9fc214a7d52b3b85ed006d09e230
[12:07] <cjwatson> I suppose it's a bug, but you may just have to divide it into smaller chunks.  The OOPS isn't full of repeated queries or anything.
[12:08] <cjwatson> Oh, there's like 5 seconds of non-SQL time.
[12:10] <cjwatson> rbasak: Is this repeatable?
[12:10] <rbasak> cjwatson: yes
[12:10] <rbasak> I retried a few times.
[12:10] <rbasak> I can try in small chunks I suppose.
[12:11] <cjwatson> There's no obvious reason it should be spending several seconds contemplating its navel outside an SQL query there ...
[12:11] <rbasak> I can leave it for examination if you wish. No real hurry.
[12:11] <cjwatson> I mean there are quite a lot of BinaryPackagePublishingHistory ids but still.
[12:11] <rbasak> I was just cleaning up as requested :)
[12:12] <cjwatson> We probably won't have time to get to it very soon, and we have the OOPS, so go ahead.
[12:13] <rbasak> OK
[12:13] <cjwatson> I suppose it *might* just be spending a long time materialising four rows for the sake of a single ID.
[12:13] <cjwatson> 4 * len(bpph_ids) I mean
[12:14] <rbasak> Since they don't disappear straight away, it's a little awkward for me to do a chunk at a time. I'll do it over a day or two I guess.
[12:17] <cjwatson> We could probably simplify the query there, since we don't care about being able to order the BPPHs by bits of the other rows.
[12:18] <cjwatson> rbasak: Please file a bug and mention the OOPS ID above.
[12:18] <rbasak> OK will do
[12:22] <rbasak> bug 1566825
[12:22] <ubot5`> bug 1566825 in Launchpad itself "Timeout on deleting large number of packages from PPA" [Undecided,New] https://launchpad.net/bugs/1566825
[19:23] <mitya57> Is something wrong with the buildds? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-035/+builds?build_state=all
[19:23] <mitya57> The builds fail after 1-15 seconds on "unknown build machine" with no log
[19:25] <dobey> https://launchpad.net/builders says nothing out of ordinary
[19:26] <dobey> there's test rebuild happening though, so some things are backed up pretty heavily
[19:30] <Saviq> mitya57, yeah something went really wrong with LP builders
[19:30] <Saviq> wgrant, are you guys aware ↑?
[20:01] <kamal> hi #launchpad.   my upload to the kernel team PPA is insta-failing for all arches, with no build log at all, and no email from Launchpad:
[20:01] <kamal> https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/9545473
[20:01] <kamal> is the build farm unhappy, or did I do something silly?
[20:03] <dobey> something is unhappy
[20:03] <dobey> apparently
[20:42] <barry> ppas are borked?
[20:43] <mitya57> yes
[20:44] <barry> mitya57: do we know details yet?
[20:45] <mitya57> barry, nope. I can only say that you are not alone.
[20:46] <barry> mitya57: ack
[20:46]  * mitya57 wonders if this affects the archive too
[20:47] <dobey> it affects builders
[22:57] <cjwatson> mitya57,dobey,kamal,barry: LP deployment rolled back, all affected builds retried
[23:15] <barry> cjwatson: thanks!
[23:20] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/1567132 <- analysis
[23:20] <ubot5`> Launchpad bug 1567132 in Launchpad itself "r17979 causes package build dispatch failures in devirtualised PPAs" [Critical,Triaged]