[00:15] nooooooooooooooooooo [00:15] slangasek, ^ [00:19] slangasek, diff looks simple enough, we might be able to resolve that [00:26] slangasek, resolved conflicts here: https://code.launchpad.net/~robru/unity-api/require-g++-4.9/+merge/226559 [00:26] will rebuild [00:29] slangasek, new build started: https://ci-train.ubuntu.com/job/landing-008-1-build/125/console [00:32] robru: I just finished testing my silo (and updating the testplan with the new features) [00:33] alecu, and it's good to go? [00:33] robru: yes! [00:33] robru should I mark testing done as "yes"? [00:33] alecu, yes, I was just going to ask that ;-) [00:34] robru: let me know if I need to do anything else; I'll check here after cooking :-) [00:34] thanks a bunch! [00:35] alecu, you're welcome, should be good for now [00:35] slangasek, https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scope-click_0.1+14.10.20140711.1-0ubuntu1.diff can I get a packaging ack here? i see new deps [00:35] yeah that one [00:46] robru: why is that showing upstream delta as part of the "packaging changes"? [00:46] robru: and thanks for the rebuild on 008 [00:48] slangasek, packaging changes includes the build system, so CMakelist.txt is included but not the entire upstream delta [00:49] it also includes like setup.py if there was one, configure.ac etc [00:52] ah, ok [00:53] robru: ack for https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scope-click_0.1+14.10.20140711.1-0ubuntu1.diff [00:54] slangasek, thanks! [01:08] * alecu looks at that warning, puzzled [01:11] alecu: it seems like an awfully gratuitous warning, since all packages go to -proposed first :) [01:13] alecu, slangasek: yeah, that's just the process, not a warning at all. the citrain system is polling the archive to see if the package is fully landed yet, and it isn't, so it just reports "hey, this is still migrating" [01:14] "INFO: archive did not use a time machine" [01:15] slangasek, think of it more like "Congratulations! Your package is already in -proposed!" [01:15] slangasek, also, it becomes more important during archive freezes, when things can sit around in UNAPPROVED for days, it reports on that, too [01:16] ok [02:04] === trainguard: IMAGE 127 building (started: 20140712 02:05) === [03:01] alecu, still around? [03:03] slangasek, can you try rerunning this autopkgtest? looks like a transient error to me: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click [03:03] alecu, ^^ this is why your thing is still in proposed [03:04] slangasek, I can't seem to get into d-jenkins right now, I thought I used to be able to... === plars_ is now known as plars [03:20] * alecu looks [03:26] weird that the error is "tar: Unexpected EOF in archive". Sounds like it's not related to this MP, right. [03:49] === trainguard: IMAGE 127 DONE (finished: 20140712 03:50) === [03:49] === changelog: http://people.canonical.com/~ogra/touch-image-stats/127.changes === [05:23] robru: I can get to d-jenkins, but I don't know where/how to retry autopkgtests [05:24] slangasek, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click go here, there's a link that says 'private', it takes you to a jenkins page, you should be able to re-trigger the jenkins job there [05:24] robru: I have a 'PUblish again' button; is that the one? [05:25] that seems like it refers only to pushing it to the public jenkins [05:25] slangasek, uh, not sure. I would expect jenkins to have a 'build' or 'build with parameters' link... are you logged in? [05:26] ah, not so much :) [05:26] still no option to retry, though [05:26] slangasek, hrm, dunno then. I guess we'll have to get infinity or cjwatson involved [05:27] my only options are 'Publish again' and 'Keep this build forever' [05:27] ohp, no, found it - one level up, "Build Now" [05:28] there you go ;-) [06:03] robru: so, trying to understand the build failures in silo-008 [06:03] the MP referenced in the spreadsheet for mir is https://code.launchpad.net/~thomas-voss/mir/explicit-gcc-version/+merge/224773 [06:04] this is superseded by https://code.launchpad.net/~thomas-voss/mir/explicit-gcc-version/+merge/224787 [06:04] which is superseded by https://code.launchpad.net/~thomas-voss/mir/explicit-gcc-version/+merge/226140 [06:04] which is listed as already merged in lp:mir/devel [06:05] uh huh [06:05] and lp:mir/devel, in turn, has the fix for the mir build failure already committed [06:06] so should we just do a new MP from lp:mir/devel to lp:mir do you think? [06:06] I have no idea [06:07] why is there a separate lp:mir/devel at all? [06:08] slangasek, well, some people didn't like our vision of how citrain was *supposed* to work, and just pre-merged everything into devel branches before getting silos assigned. it always baffled me, because it completely defeats the way we generate changelogs from commit messages. [06:09] looks like I need r1757 from lp:mir/devel, but why is this not already being merged into lp:mir [06:09] slangasek, they merge it into trunk periodically [06:10] so I should be able to just propose a merge from lp:mir/devel to lp:mir, and the train will DTRT, and no one will be surprised or upset by this? [06:11] slangasek, hmmmmmm well you can make the MP, but I wouldn't merge anything until we get some kind of ack from the mir team. don't want to step on their toes. [06:11] slangasek, actually I'm just looking at their branches now and I realize I don't have a clue how they're organizing their development. [06:11] ok, so, that's a problem then [06:11] because this transition needs to happen in Ubuntu [06:11] and the workflow is now making it more difficult to fix a latent bug in the mir code [06:11] slangasek, well we don't have to wait for tvoss, we can probably ping kgunn about this [06:12] right, a workflow that requires me to ping someone for signoff before merging a bugfix is broken :) [06:13] slangasek, how big of a diff are we talking about here? [06:13] slangasek, it's a big silo, I assumed it was a big change [06:13] lots of testing required, etc. [06:13] no [06:13] the change I need from devel is a one-liner [06:13] the delta from devel to lp:mir is 36 commits an 10kloc of diff [06:13] slangasek, ok but if you actually MP lp:mir/devel to lp:mir, is it just one line? or does it pull in a bunch of crap, too? [06:14] slangasek, yeah, so I'm gonna say, let's not MP 10kloc of stuff without upstreams involvement there. [06:14] and the actual change related to this silo is a packaging-only change to the compiler used [06:14] slangasek, maybe just cherry pick that one line you need [06:14] ok [06:15] slangasek, adding a new MP to the silo is easy anyway [06:15] yes... it's just irksome to be cherry-picking, due to bzr :) [06:16] heh [06:17] slangasek, I think you can handle one line. [06:18] I mean that it's irksome later due to the history mismatch [06:19] hm [06:22] robru: ok, https://code.launchpad.net/~vorlon/mir/explicit-gcc-version-and-g++4.9-compatibility/+merge/226563 [06:23] spreadsheet updated [06:23] now I would just need to reconfigure with https://ci-train.ubuntu.com/job/landing-008-0-reconfigure/build?delay=0sec ? [06:23] slangasek, yep that should do it [06:23] ok [06:23] not doing it yet, there are other build failures to sort out first [06:24] robru: thanks for the sanity checks :) [06:24] ah ok [06:24] slangasek, you're welcome [06:24] slangasek, I'm signing off soon but I'll still hear pings if you need something