=== heroux_ is now known as heroux === sakrecoe1 is now known as sakrecoer [11:57] I've just migrated uvtool from bzr to git. So lp:uvtool seems to exist both for bzr and git, and that works. I've configured the project to say that the VCS is Git. [11:59] However, my new source build recipe, despite starting with "# git-build-recipe...", seems to be automatically changed to "# bzr-builder..." and then run against bzr dailydeb instead. [11:59] https://code.launchpad.net/~uvtool-dev/+recipe/master-daily is the recipe [11:59] "Base source" seems to link to the bzr branch, not my git branch. [11:59] I don't see any way of changing this. [11:59] Help? [11:59] rbasak: You can't convert a bzr recipe into a git one. You need to create a new recipe from the git branch. [11:59] That's what I thought I did. Perhaps I created it from the wrong branch? [12:00] Likely. [12:00] I think there may be a problem with ambiguous lookups ... [12:00] * rbasak deletes it to try again [12:00] Hmmm. [12:00] You could unset the bzr development focus; I think that would help. [12:01] Ah, yes, SourcePackageRecipe.new only gets the text, not the context. [12:01] wgrant: yeah I did create it from the correct branch. I'll try what cjwatson says. [12:03] It's messy because we use bzr-builder to parse the recipe text, which means we have to hack the format line internally and then hack it back again in the git case, which is why you're seeing the change to "# bzr-builder...". [12:03] Should maybe extract that code. [12:04] But indeed the fundamental problem here is that the recipe parser doesn't quite have enough information and has to guess. [12:04] cjwatson: the "Development focus" dropdown on the project only gives me one option (the bzr trunk branch) [12:04] rbasak: "Development focus" is a series, not a branch. The series might have a branch. [12:04] Head over to "Configure code" instead [12:04] Expand the Bazaar section, and unset the branch. [12:05] I see, thanks. I'll try that. [12:05] focus> sorry, I always forget exactly what the weird semi-inconsistent vocabulary used for Bazaar is :P [12:06] I emptied the "Link to a Bazaar branch already on Launchpad" box, and that has stuck. [12:06] lp:uvtool should be unambiguous now, then. [12:06] I think an alternative would have been to use a URL form that only exists for git. [12:07] But it's probably less confusing anyway if lp:uvtool stops existing for bzr once you've migrated. [12:07] (series also shouldn't be as prominent as they are. if you don't use Bazaar you basically never have to deal with them now, at least...) [12:07] Keeping the old branch around is useful; keeping the alias less so. [12:07] Agreed (lp:uvtool should stop existing for bzr) [12:09] Yes "Base source" now points to the git repo, and the header has stayed "# git-build-recipe". Thanks! I'll try a build now. [12:10] Would you like a bug for this? [12:21] May as well. [12:36] OK, filed bug 1623924. Thank you for your help. [12:36] bug 1623924 in Launchpad itself "git-based source build recipes are sometimes interpreted as bzr recipes instead" [Undecided,New] https://launchpad.net/bugs/1623924 [14:29] hi, I'm kind of blocked on having exceeded my ppas size - who might I bother to increase its size (https://answers.launchpad.net/launchpad/+question/394937) [14:38] cpaelzer: done [14:39] cjwatson: thanks you! [14:39] -s [14:40] cjwatson: thanks for your mentioning on the 6 hour cron job [14:40] cjwatson: would that be worth updating https://help.launchpad.net/Packaging/PPA/Deleting? [14:40] cjwatson: there is says "In the most common situation, files are removed within an hour." [14:41] maybe that was ment for the archive indexes, but since the text talks "archive, file on disk, comment" I misinterpreted it to belong to the files on disk [14:49] cpaelzer: clarified a bit [14:51] cjwatson: perfect, thanks === dpm is now known as dpm-afk === dpm-afk is now known as dpm === PaulW2U_ is now known as PaulW2U [17:53] cjwatson: what's the PPA builders' core OS version? [17:54] (i.e. which release of Ubuntu drives 'sbuild' or similar in the builders) [17:55] (if you know) [18:01] i think 12.04 or 14.04 [18:02] teward: looks like 14.04 according to build logs [18:02] sbuild_0.65.2-1ubuntu2~ubuntu14.04.1~ppa8 [18:03] dobey: hmmmmm [18:03] the ~ppa8 means that that's a patched sbuild... which makes sense, but i was curious about that or not [18:04] (esp. given that there's a nasty sbuild issue in Trusty wrt any schroot containing gnupg 2.x) [18:04] yeah, sbuild and some other packages are update from a ppa [18:04] makes total sense. doesn't necessarily help the rest of us (Yakkety schroots no longer work, at least on Trusty sbuild) [18:06] dobey: thanks. [18:18] The base release varies a bit across architectures, but at the moment it's mostly trusty, yes [18:18] The PPA in question is https://launchpad.net/~canonical-is-sa/+archive/ubuntu/buildd/+packages [18:24] teward: ah, you're probably hitting the same issue i had setting up schroots on jenkins, with the trusty sbuild [18:25] cjwatson: right i found that [18:26] dobey: was it the gpg no priv. key problem? [18:27] teward: i don't recall exactly, but there was a bug filed iirc, and the fix was not yet SRUed to trusty. [18:27] dobey: which explains the evils I'm having. [18:27] dobey: I know that Ubuntu Bug 1624046 which I just filed addresses the existing problem and links back to the Debian bug I'm seeing, but CBA to fully finish triaging (lazy, and still recovering from bronchitis0 [18:27] Ubuntu bug 1624046 in sbuild (Ubuntu) "sbuild: Does not work with gnupg 2.x installed in the chroot" [Undecided,New] https://launchpad.net/bugs/1624046 [18:28] (matches the Debian bug reporter's issue basically 1-for-1) [18:29] dobey: was there any timeline on a Trusty SRU? [18:29] wait why am I asking in here instead of #u-devel [18:29] don't recall and don't know :) [22:20] Hi, is there a problem with lp? I can't seem to comment or act on bugs [22:21] ("Service Unavailable") [22:30] ok, I was not patient enough :) It's back, thanks a lot !