[12:37] cjwatson: Can you remind me how a version passed to a livefs requestBuild call should manifest itself within the live-build? I thought it was as $BUILDSTAMP, but I'm not seeing that... [13:14] Odd_Bloke: It's $NOW in the environment of the build; live-build sanitises the environment, so livecd-rootfs stuffs BUILDSTAMP="$NOW" into config/binary [13:14] So depends where you're looking from [13:29] cjwatson: Ack, thanks; looks like a bug in our tooling which was throwing me off. :) === coreycb` is now known as coreycb [15:10] None of the builds for the latest upload (via recipe) in https://launchpad.net/~cloudware/+archive/ubuntu/cpc-livecd-rootfs/+packages are getting queued; anyone know what's up? [15:14] Ah, looks like they're getting queued now. :) [15:15] Let me poke some builders a bit on general principles [17:00] I requested livefs #50000, do I win a prize? [17:00] "You've won a brand new ... ... log describing your build failure!" [17:07] Congratulations! [17:47] :) [17:48] cjwatson: FWIW, I'm seeing the builds for that recipe (https://code.launchpad.net/~cloud-images-release-managers/+recipe/cloud-image-sauce) queued despite available builders again. [17:48] cjwatson: If that's just the way it is, that's not a problem at all; just flagging it up in case that indicates something being broken. :) [17:51] Odd_Bloke: I can't see these, so are these builds using a private archive? [17:51] or into a private archive, rather [17:52] cjwatson: Yes, they are. [17:52] Odd_Bloke: right, so private PPA builds are special [17:52] OK, cool. [17:53] Odd_Bloke: we don't have the necessary things hooked up for them to be able to be granted tokens to access private files directly in the librarian; instead we have to wait for the source to be published in the PPA, and then we can start building them [17:53] Odd_Bloke: so it all takes an extra publisher cycle vs. normal [17:53] Ahhh, OK. [18:40] any news about git repo support on recipes? [18:51] sergio-br2: it's beta now [18:51] https://blog.launchpad.net/cool-new-stuff/beta-test-git-recipes [18:51] oh [18:52] nice [18:53] thanks [19:00] dobey, how can I do a git-git import on launchpad? [19:02] basically I want to clone a github repo, and maintain it sync [19:03] *mirroring [19:07] or, is it possible to use recipes with external git repos? like github? [19:25] sergio-br2: i don't know [21:00] sergio-br2: I'm afraid we don't do git-to-git imports yet, though we'd like to, it's on the wishlist. at best you just have to mirror things manually [21:00] hi cjwatson [21:00] like git pull && git push ? [21:00] sergio-br2: recipes only work with repositories hosted in LP (fairly fundamentally), so there's an obvious link there [21:01] mirroring is what I'm looking [21:01] sergio-br2: maybe push --mirror, but yes, that general idea. acknowledge it's not great [21:01] sergio-br2: we know roughly what we need to do to get mirroring going but it hasn't been started yet [21:02] can I use a git repo, and nest it with a debian repo (bzr) ? [21:03] or the debian repo needs to be git too ? [21:05] they all need to be the same VCS [21:07] ok [21:33] bzr: ERROR: unknown command "fast-export" [21:33] bzr fast-export --export-marks=../marks.bzr ../old-bzr-branch | git fast-import --export-marks=../marks.git [21:33] that tutorial is wrong i guess [21:34] bzr: ERROR: no such option: --export-marks [21:37] oh, it's missing a package [22:58] failed to build :/ [22:58] https://code.launchpad.net/~dolphin-emu/+recipe/dolphin-daily-trusty [22:58] and there's no log [22:59] sergio-br2: Yes, just investigating that as soon as I get a sysadmin's attention - https://bugs.launchpad.net/launchpad/+bug/1538276 [22:59] Launchpad bug 1538276 in Launchpad itself "git recipe failed to build without showing buildlog" [Undecided,New] [23:01] I'm pretty sure it's right [23:01] it's building here [23:02] It's just a problem with the base image being booted by the buildds you happened to hit [23:02] We can't see the logs for the process that updates those, unfortunately, so it's a bit of an arm's-length-guesswork game to make sure they're all updated [23:04] I guess {revno:packaging} will not work for git right? [23:04] could I do {revtime:packaging} ? [23:05] revno will work [23:05] see the docs [23:05] eh [23:05] it's a bit of a hack, but it does work [23:05] what it'll get? [23:05] we take the length of the left-hand-parent history of the commit [23:05] which is a decent emulation, and it's useful to have a simple monotonically-increasing value you can use there [23:05] uh [23:05] you certainly can use {revtime:packaging} instead, it just gets rather long [23:06] yeah [23:06] this is documented near the end of https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables [23:08] so there's no way this number get less right? [23:12] cjwatson, nest packaging lp:~dolphin-emu/+git/debian-master-trusty debian [23:12] is it right? [23:12] or do I need do this: [23:12] nest packaging lp:~dolphin-emu/+git/debian-master-trusty master debian [23:13] get less> revno will always increase unless you do a non-fast-forward push [23:14] the main git repo needs the "master", the nest needs it too right? [23:14] sergio-br2: if you need to specify a branch name, it needs to go at the end ("nest packaging lp:~dolphin-emu/+git/debian-master-trusty debian master") - slightly weird but a consequence of following the existing recipe format which put an optional commit identifier in that position. But you can omit "master" and you'll get whatever HEAD for that repository is, which is usually master [23:15] humm [23:15] sergio-br2: this is true for the main repository as well, you can leave out the branch name and get HEAD, though I would say it's normally clearer to include a branch name [23:15] yeah, for the main I saw it was optional [23:16] sergio-br2: especially since "debian-master-trusty" is a very weird repository name - it implies that a future "debian-master-xenial" would be a separate repository, whereas surely you would want those to be different branches of the same repository [23:16] putting series in git repository names is usually a mistake [23:16] you can if you like, it's just odd :) [23:17] humm [23:17] lp:~dolphin-emu/+git/dolphin [23:23] didn't understand cjwatson [23:31] https://launchpadlibrarian.net/235314217/buildlog.txt.gz [23:31] ok, the recipe is working now [23:32] but I have this unmet deps [23:32] sergio-br2: I was talking about lp:~dolphin-emu/+git/debian-master-trusty, not lp:~dolphin-emu/+git/dolphin [23:32] I'm pretty sure I work-a-rounded it by changing the PPA deps, using the Security option [23:33] unmet deps are entirely your problem, they work the exact same way for bzr/git [23:33] the series you mean "trusty", cjwatson ? I need 3 different deb packages for dolphin [23:33] but it was working with the other ppa [23:33] sergio-br2: trusty is an example of a series, yes [23:34] sergio-br2: my point is that trusty/xenial/etc. should normally be a branch within a git repository, not in the git repository name [23:34] seriously, why they updated this gcc-4.9-base [23:34] oh, right cjwatson [23:34] yeah, I'm used to do it cjwatson [23:34] with bazaar [23:34] heh [23:35] eh, I'm not sure that an update of gcc-4.9-base was your problem [23:35] let me look into it, modulo children's bedtime [23:35] it's the problem [23:35] someone thought it was a good idea to update it [23:35] in YOUR PPA [23:36] even if 14.04 has no full 4.9 support... [23:36] I mean, that's kind of what it's complaining about ... [23:36] It was working until this update cjwatson [23:36] I noticed this update 2 weeks ago [23:36] why did you put it in https://code.launchpad.net/~dolphin-emu/+archive/ubuntu/tmp2/+packages in the first place? [23:36] because I'm testing [23:36] what was the failure without that? [23:37] there's was no failure at all, before [23:38] the update of gcc-4.9 in trusty-updates can't possibly be related, because this build log doesn't have -updates enabled [23:39] yeah, I'm using security only [23:39] so what update are you talking about that broke things? [23:40] so from where this 4.9.3 is appearing? [23:41] weird [23:41] it's in your PPA [23:41] you put it there [23:41] nope [23:41] your recipe points at it [23:41] my PPA is using 4.9.2 [23:42] https://code.launchpad.net/~dolphin-emu/+archive/ubuntu/tmp2/+packages disagrees [23:42] https://code.launchpad.net/~dolphin-emu/+archive/ubuntu/tmp2/+edit-dependencies [23:42] eh [23:42] it's getting from tmp2 ? why... [23:42] that's what https://code.launchpad.net/~dolphin-emu/+recipe/dolphin-daily-trusty points to [23:42] under "Daily build archive" (hover over the link) [23:43] ok, tmp2 has 4.9.3 [23:43] but I thought tmp2 can't get packages from its own [23:43] and the reason it doesn't work is that you need to backport (at least) isl as well [23:43] let's delete this [23:44] or just point your recipe at the PPA you actually want to use for it [23:47] ok, now it failed without log heh