[01:34] back [01:47] doanac: you around? [01:51] cihelp - is mako-07 down? The autopilot release gatekeeper job is stuck [01:53] thomi, the jenkins slave process was dead, I've restarted it [01:54] fginther: thanks [01:54] * thomi tries again [01:54] that looks better, thanks fginther [01:55] thomi, no problem, glad it's working again [02:09] === trainguard: IMAGE 17 building (started: 20140508 02:10) === [02:15] fginther: speaking of that job... a couple of things I wanted to ask you about with it [02:15] err [02:15] sorry fginther, I meant to say thomi :) [02:15] plars: shoot [02:16] thomi: on that gatekeeper job, Saviq was asking earlier if we could make the channel selectable, and default to utopic [02:16] thomi: I was going to just change it, but wanted to talk to you first [02:16] plars: it's not utopic already? [02:17] heh.. yeah, let's change that pleae :) [02:17] thomi: nope, it's on trusty still [02:17] hmm, I guess I assumed it ran whatever smoketests ran [02:17] thomi: the other thing was what you and I and doanac had talked about before - removing the selection of mako-07 specifically and have it just use the daily-mako pool [02:17] thomi: we're parallelizing those jobs now, so there's less risk [02:17] plars: that sounds great as well [02:18] thomi: and also I already sorta offered up mako-07 up as a sacrifice (to be replaced later) [02:18] plars: How confident should I be that the job does the same thing as the smoke runner job? [02:18] thomi: but sometime soon it's going to get pulled out and we're going to do surgery on it [02:18] plars: ok, well, I cancelled the job, so it's not doing anything right now [02:18] we need to land a new branch and then try again [02:19] so I guess it'll be free for a few hours at least [02:19] thomi: oh the job won't change at all for this part, I'm just going to change it so that instead of telling it to run on mako-07, it runs on $some_mako from a pool [02:19] ok [02:19] thomi: do you generate that job from a script, or was it manually configured? [02:20] plars: doanac made the job for us, I have no idea how [02:20] I'm just concerned that the smoke test job may have changed, and we'd like those changes to apply to our job as well [02:20] so we're testing the same as the smoke test job [02:21] thomi: heh, someone already added a $series with "#TODO support $series" [02:21] heh [02:21] thomi: but I'm going to just add a $channel since I'm not sure if that's used somewhere else [02:21] we can remove it later if possible [02:21] since I'd like to just specify the full channel [02:22] ex. ubuntu-touch/utopic-proposed [02:22] ok [02:22] so, when I re-run that job, it should pick up the right channel now? [02:25] thomi: yes, I just made the changes. Is it something you want to try now while I'm still up? [02:25] thomi: I think as long as we get through the install, we will know we're good [02:25] plars: sure, I'll kick it off again [02:25] I'm going to add that device to the pool too, since it's there for now [02:26] http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/116/ is running [02:26] + ubuntu-device-flash ubuntu-system --channel ubuntu-touch/utopic-proposed --bootstrap [02:26] looks good to me :) [02:27] heh, as luck would have it, it ended up picking mako-07 anyway, but it picked it from the pool this time :) [02:27] it's flashing utopic though, so all good [02:28] Saviq: you can specify the channel on the autopilot gatekeeper job now, and default is utopic-proposed [02:28] thanks thomi [02:28] I'll wait till it starts installing packages, just to make sure it picks up the correct ap packages [02:42] plars: still around? [02:43] I think phablet-test-run isn't using the correct autopilot version [02:46] thomi: is that for click packages? [02:47] robru: ubuntuuitoolkit ATM [02:47] surely that's ported to py3 [02:47] it'd have to be, for anything else to use it [02:47] well, I guess it's bilingual [02:47] but I expected bilingual ports to use py3 [02:49] thomi: I found out yesterday that phablet test run needed to have a test section in the manifest for it to use py3 [02:50] robotfuel: yeah, xnox told me that as well. I'll keep an eye on this run and see what happens [02:50] thomi: https://code.launchpad.net/~xnox/gallery-app/py3-manifest is an example [02:50] yup [03:00] thomi: sorta [03:01] plars: nvm, I'll pick it up again tomorrw [03:01] gonna let the test job finish [03:01] thanks for your help :) [03:01] thomi: anytime :) [03:01] good night [03:02] 'night [03:24] === trainguard: IMAGE 17 DONE (finished: 20140508 03:25) === [03:24] === changelog: http://people.canonical.com/~ogra/touch-image-stats/17.changes === [04:11] choo choo [06:49] plars, thanks! === psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone [08:11] cjwatson: hello! Could you by any chance help me out on understanding the ubuntu-download-manager autopkgtest failure? It doesn't seem like a valid failure to me on first look, seems more like some infra problem - what do you think? Example logs: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-system-image/4/ARCH=amd64,label=adt/console [08:12] morning psivaa, could we trigger Jenkins on https://code.launchpad.net/~akiva/reminders-app/fix-1316827-reload-notes/+merge/218566 ? I think it didn't run because the MP came from a contributor outside the development team [08:12] dpm: just a sec pls [08:13] no worries, thanks! [08:13] psivaa: could you please look at why sudoku-app isn't building in jenkins - http://s-jenkins:8080/job/sudoku-app-click/lastUnsuccessfulBuild/console [08:13] bzr: ERROR: Already a branch: "/home/ubuntu/jenkins/workspace/sudoku-app-click/tool_dir". [08:13] (morning btw) [08:13] popey: morning. ack will take a look [08:24] was the friends app discussed in the evening btw? I can confirm that it's indeed broken for me at least, like the autopilot say too, after the new 0.92.0+14.10.20140506.1 release [08:25] mardy: ^ [08:26] Mirv: I don't remember hearing about it [08:26] oh, hmm, going over it again, is it because ubuntu-system-settings-online-accounts is stuck in propose? [08:26] autopkgtest failed [08:26] https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/4/ARCH=amd64,label=adt/console [08:28] so the landing got partially stuck [08:28] Yeah, I noticed that in the morning alongside other failures [08:29] This one seems like a real failure though? [08:29] Let's discuss that on the meeting [08:29] popey: http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/119/console has some errors in the sudoku app code [08:30] dpm: still looking at the MP. i'll see if i can trigger without adding the proposer without adding to the group [08:30] psivaa: thanks [08:31] thanks psivaa [08:31] grr [08:32] no alarm ... [08:38] Mirv: mmm... you mean that friends-app landed, while the other bits in the same silo (like ubuntu-system-settings-online-accounts) didn't? [08:41] popey: why are you accepting bribes on my behalf :) [08:43] ☻ [08:43] popey: do you have the bug available for the download bar vanishing on update manager [08:43] mardy: yes. or the u-s-s-o-a landed but is stuck in proposed because its autopkgtest is failing (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html) [08:44] so friends is broken because it didn't declare a dependency on the newer u-s-s-o-a [08:44] davmor2: depends which bug - the one where the content disappears? [08:47] Mirv: I can't understand the failure in the u-s-s-o-a tests, it looks like something is missing but I'm not sure what [08:48] psivaa: when you get a moment could you retrigger jenkins on this merge, or tell me how to? https://code.launchpad.net/~popey/sudoku-app/fix-1315318/+merge/218035 [08:48] Mirv: is it correct to run the autopilot tests in the autopkg tests? [08:51] popey: so you click on update you see the download bar initially and then it disappears. I don't see it on mako but it happens on flo and manta reliably :) [08:51] i have seen it on mako and flo [08:52] bug 1307687 [08:52] bug 1307687 in ubuntu-system-settings (Ubuntu) "swiping upwards in the updater dialog while it downloads an image makes the UI vanish" [High,Confirmed] https://launchpad.net/bugs/1307687 [08:56] popey: I see you dont have access to that instance of jenkins. i've kicked off a rebuild. i'll see if i can add your account to it [08:59] mardy: I think so yes, even though my autopkg knowledge is limited. they should be executed in full graphical lxc environment. [08:59] mardy: but pitti mentioned earlier that there were some changes https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-May/001098.html [09:00] psivaa: thank you! [09:01] np [09:05] sil2100: That does look somewhat bogus; have you tried running the test locally? [09:09] popey: mtp died on me too so confirmed the bug [09:09] thanks [09:10] have assigned it to cyphermox [09:10] popey: yeah I can't even reattach to mtp now [09:11] davmor2: we should add a task in the manual test sheet for this. [09:11] also, probably need a test for "upgrading an app from the store" which would mean we probably need an app which we can install an old version of, to force there to be an update [09:17] sil2100: line 20 is now good to get a silo [09:18] sil2100: however, not sure if that requires explicit qa signoff (a lot of refactored code). what's the policy here? [09:21] thostr_: we get the pings automatically on #ubuntu-ci-choo-choo channel when a line is set to ready [09:22] thostr_: I think qa signoff is only for trusty SRU:s as it was introduced for finalizing the new stable image [09:22] silo assigned [09:22] Mirv: thanks for clarifying [09:29] Doesn't look like it's been mentioned here: the publisher will be stopped for the next five hours or so (technically, it's in the middle of a very very long run) because we're processing a takedown request and the caches for several of the affected suites were absent. [09:38] hey, what's this? [09:38] http://changelogs.ubuntu.com/changelogs/pool/universe/q/qmenumodel/qmenumodel_0.2.7+14.04.20140305-0ubuntu2/changelog [09:38] that latest version [09:38] thostr_: I switched the QA sign-off to No today, as we only do that when there is a critical situation with no-propotions [09:38] it's not in trunk [09:38] and now silo9 fails [09:38] with WARNING A version (0.2.7+14.04.20140305-0ubuntu2) is available at the destination archive for that component but is not in the destination branch which is still at 0.2.7+14.04.20140305-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check. [09:39] dpm: so i've kicked off a build manually for Akiva's proposal. http://91.189.93.70:8080/job/reminders-app-ci/309/console [09:39] you can bypass no-change rebuilds imo [09:40] dpm: it should work, but if it's not, some one has to approve the membership request [09:40] cjwatson: what takedown request? is there a public bug for it? [09:40] Wellark: https://bugs.launchpad.net/ubuntu/+source/maitreya/+bug/1317234 [09:40] Ubuntu bug 1317234 in maitreya (Ubuntu Trusty) "maitreya package contains non-distributable font" [High,Triaged] [09:42] Wellark: so, this message basically means that someone made a direct release to the archive without merging in the changes to the bzr branch [09:42] Wellark: so most likely 0.2.7+14.04.20140305-0ubuntu2 got released manually and there is no 0.2.7+14.04.20140305-0ubuntu2 in the bzr branch for that component [09:42] sil2100: yes. as I noted, the 0ubuntu2 is not in trunk [09:42] so how to proceed now? [09:43] psivaa, thanks. It seems all jobs failed, not sure why -> https://code.launchpad.net/~akiva/reminders-app/fix-1316827-reload-notes/+merge/218566/comments/521402 [09:43] I'd say that is to be expected for no change rebuilds, and should be ignored at train level (which will discard the changelog entry, but that's fine) [09:43] What needs to be done is you (or anyone else) need to, for instance, prepare a merge that actually 'adds' this missing changes and the changelog entry from the archive [09:45] sil2100: so I just get the archive source package, copy over it's debian/changelog and commit. ok. thanks! [09:46] dpm: there is another build ongoing. i dint enter the parameters in the first build properly [09:46] psivaa, ok, no worries. I had top-approved it too, not sure if that will help or interfere [09:46] Wellark: yes, that's the best way :) Just getting the changes as a merge and adding them to your landing as the first merge [09:47] sil2100: it has to be a separate MP? [09:48] can't I just make a commit to the MP that I have proposed for landing? [09:51] Wellark: it can, no problem [09:51] Wellark: am a bit worried about the changelog generation, but I guess we'll see how it goes [09:52] ok. let's see [09:55] sil2100: ok. done. could you tricker a rebuild of silo9? [09:57] Wellark: sure [09:58] sil2100: thanks! [10:02] psivaa: could you also re-trigger https://code.launchpad.net/~gang65/ubuntu-docviewer-app/ubuntu-docviewer-desktop-improvements/+merge/210866 ? [10:03] popey: done [10:03] thanks psivaa [10:13] sil2100: ... https://ci-train.ubuntu.com/job/landing-009-1-build/62/console [10:14] Wellark: yeah, was a bit worried this might happen, not a big deal though - let me find the best solution here [10:14] sil2100: so I need to change the 0ubuntu2 to UNRELEASED and also use dch -i [10:14] No no no [10:14] that what the message says! ;) [10:14] Leave 0ubuntu2 as it is, as it was released, so it cannot be UNRELEASED anymore ;) It needs to stay as utopic [10:14] What would be best to do is: [10:15] (this is the safest way) [10:16] Now that you have 0ubuntu2 in as 'utopic', go to the source tree and do a dch -i (to generate 0ubuntu3) and write the commit message manually there [10:16] i.e. copy-and-paste the commit message as a changelog entry for 0ubuntu3 [10:16] And leave 0ubuntu3 as UNRELEASED [10:16] but will I leave 0ubuntu2 there? [10:17] Yes, leave 0ubuntu2 in there as it was in the archive [10:17] so 0ubuntu3 contains the commit message from my MP? [10:17] Yes, with the addition of 0ubuntu3 on top with your changelog entry from the commit message [10:18] citrain, during release, will change the version number of 0ubuntu3 to a proper one and change it to 'utopic' during release, just we need to make sure it doesn't mess up the changelog [10:19] (there is a high-chance that citrain would handle this correctly, but it's best to be sure) [10:20] Wellark: so, just dch -i in your branch now, add the commit message as the changelog entry, commit, push and let's rebuild [10:20] sil2100: please make a sanity check: https://code.launchpad.net/~kaijanmaki/qmenumodel/unitymenumodel_setname-allow-empty-string/+merge/213768 [10:22] Wellark: looks awesome, just one thing that needs to be changed - the actual changelog entries have to be wrapped at 80 characters [10:23] oh, com'on! [10:23] ;) [10:23] will do. [10:23] Wellark: so do this: http://paste.ubuntu.com/7415234/ [10:23] ;) [10:23] Sorry, otherwise it might cause trouble ;p [10:23] But besides that we're ready to build [10:24] sil2100: pushded [10:25] * Wellark wonders if we are still stuck to 80 characters in 2036 [10:25] I guess we will ;p [10:25] popey: your screenshot script do you see this remote object '/tmp/mir_screencast_768x1280.rgba' does not exist [10:26] Wellark: ok, rebuilding [10:26] sil2100: thanks! [10:26] they added _60Hz to the filename davmor2 [10:26] yw! [10:26] popey: ah ta [10:27] sil2100: looks like Saviq just hit the same problem [10:27] https://ci-train.ubuntu.com/job/landing-010-1-build/11/console [10:28] could we please not do manual uploads in the future... :) [10:28] Wellark: *sigh* this is the biggest problem - manual uploads wouldn't be a problem if they would be later merged-back into trunk [10:29] nasty [10:29] sil2100: if it's just a rebuild upload [10:30] what about pushing the debian changelog entry directly to trunk? [10:30] would be easiest [10:30] Wellark: that could be done as well, yes - there's also another thing we were doing, but core-devs generally frowned upon that ;p [10:31] Wellark: since in the past we basically 'forced' ignoring that version, just pushing without that changelog entry [10:31] It would work, as if it's just a rebuild, there is no risk involved - but you basically 'remove that version from history', which is bad [10:31] these changes are not even simple rebuilds [10:31] they actually modify debian/control [10:31] http://changelogs.ubuntu.com/changelogs/pool/universe/libu/libusermetrics/libusermetrics_1.1.1+14.04.20140305-0ubuntu4/changelog [10:32] * Wellark looks for a fresh trout [10:33] sil2100: did you tick "reconfigure" on my silo yet? [10:34] or is it "build" [10:34] anyway.. [10:34] Wellark: yes ;) It's building [10:34] sil2100: thanks! [10:35] let's see what the next error is.. [10:55] sil2100: what does this now mean... https://ci-train.ubuntu.com/job/landing-009-1-build/63/console [10:56] Another error?! Let me look in a moment [10:56] Oh, connectivity-api now, let's see [10:57] uh [10:57] sil2100: wait.. [10:57] So, looking at the connectivity-api merge, there's some strange changelog magic there o_O [10:57] for some reason there is a change to debian/changelog as part of the MP [10:58] I guess that's something that's not needed, I would remove that [10:58] sil2100: yeah.. [10:58] weird.. [11:01] sil2100: ok. fixed. [11:02] sil2100: could you do a reconfigure while you are at it? [11:03] I merged some tests from dednick to the unity8 branch [11:03] oh, actually [11:03] never mind [11:03] didn't push them yet [11:03] Wellark: did you add a new merge? :) [11:03] A reconfigure is needed only when a new merge is added to the list of merges [11:03] ah, ok [11:03] Otherwise a rebuild is all that's needed [11:03] ok. cool. [11:04] Should I wait for you to push those changes? [11:04] rebuild then pleae :) [11:04] nope. [11:04] I'm fighting with ssh-agent [11:04] need to remove gazillion of tags from a remote branch [11:04] and bzr is asking for my ssh key passphrase on each removal for some reason [11:10] sil2100: let's see what happends next.. :) [11:10] maybe my c++11 monster will hit OOM on the arm builders or something.. [11:21] ogra_: do you have a manta? [11:25] cjwatson: hi! So I ran the system-image autopkg tests locally and everything is passing correctly - I would say this was some transient issue, do you know if we can somehow re-run those to get it move out of -proposed? [11:25] cjwatson: ubuntu-download-manager has no autopkg tests of its own, it was the system-image ones that seemed to have failed there [11:26] cjwatson: I'm still a bit of a newbie here, but I guess it would be nice to have that re-ran if possible [11:26] (not even sure who to ping?) [11:28] I can re-run them [11:29] sil2100: build scheduled. in general you want to ask pitti/jibel for autopkgtest stuff though [11:29] sil2100: but didn't pitti point out a problem on another channel though? [11:29] it would be nice not to have this conversation spread across channels [11:30] cjwatson: ok thanks! Yes, but I can't really fix that, and running locally seemed to work - and I also poked pitti but he seems to be AFK ;) [11:30] but pitti answered you and suggested a specific change to make [11:30] you could just wait for system-image people to wake up, since it's not like you're going to get anything moved out of -proposed right now anyway with the publisher in the middle of a very long run [11:30] cjwatson: yes, but how could I change that, as it's a test in system-image, which I do not have commit-access to [11:31] it sounds like the rerun I just scheduled was a waste of time since it'll fail in the same way [11:31] cjwatson: and as I mentioned, it passed locally, so I guess if it was a real problem as outlined it would have failed for me as well I would suppose [11:31] the comments from pitti on #ubuntu-devel don't suggest that it was transient [11:31] no, not necessarily [11:33] depends on the test runner [11:33] oh, that said, amd64 passed ... [11:34] Oh [11:34] So... even I didn't really expect that [11:34] ;p [11:34] ... and so did i386 [11:34] so ok :) [11:34] I wonder why it didn't pass before then [11:34] beats me [11:35] cjwatson: thanks and sorry for poking around, now at least I know who to contact best ;) [11:35] anyhow, yeah, core devs / release team types should generally be able to rerun jobs [11:35] pitti/jibel operate the infrastructure [11:36] I think only Canonical members of the above teams can rerun jobs, at the moment, since Jenkins [11:36] Indeed, because you need to use an instance behind a private VPN to do that [11:38] popey: https://bugs.launchpad.net/ubuntu-filemanager-app/+bug/1317480 [11:38] Ubuntu bug 1317480 in Ubuntu File Manager App "File manager tests are failing on flo" [Undecided,New] [11:39] popey: no idea why but manta hates your screenshot script in the end I had to modify the phablet-screenshot script and that eventually worked :) but I got there [11:39] what did you have to change ? === alan_g is now known as alan_g|lunch [11:56] ogra_: _60Hz to adb pull line [11:56] davmor2, ah, good ... just porposed an MP for that [11:56] * ogra_ was just scared there was something else [11:59] ogra_: no it worked fine once I'd found the script and modded it. popey's from what I can tell mirrors it only uploads them to a server via ssh at the same time. The only issue is that manta spits it's dummy out with the first adb command even though I changed the size to match the image name and added the _60Hz :( [11:59] yeah, https://code.launchpad.net/~ogra/phablet-tools/force-mirscreencast-filename/+merge/218788 fixes that === cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone === sendak.freenode.net changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone [12:33] davmor2: i am getting no notification sounds in #17 on mako when I get an SMS [12:36] popey: I had that too the other day but then I think I rebooted and it went away let me check though [12:36] * popey reboots to test [12:36] did you guys get a meeting notification this morning ? [12:36] i didnt on #15 [12:37] i did for one meeting, not for another [12:37] yeah, reboot and the ding comes back [12:37] popey, ogra_: so I got the first but not the second [12:38] so there is still something odd ... i would put my bets on that it is the same thing [12:38] and now I can't send a reply from the indicator [12:39] popey, ogra_: okay I've had no pings since the first [12:41] davmor2: ogra_ can either of you confirm bug 1317510 [12:41] bug 1317510 in indicator-datetime (Ubuntu) "Wrong icon for events #17 mako" [Undecided,New] https://launchpad.net/bugs/1317510 [12:42] popey: if reboot helps then its NOTABUG [12:42] ;p [12:43] :þ [12:43] popey: http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-05-08-134309.png I get a mix [12:44] popey: I'm assuming ones with alarms have the alarm icon and the ones that are just dates don't [12:45] popey: send a second text [12:45] i have sent a few [12:46] sil2100, any news about silo 001 [12:46] ogra_: for the meeting tomorrow morning on the phone look and see if it is the alarm clock or the calendar app icon in the date/time indicator [12:47] mandel: so! All is good now, with the help of cjwatson and pitti in the end a re-run helped - but it might take a while until it migrates [12:47] mandel: since the publisher seems to be in the middle of something long [12:47] ogra_: see my screenshot in comparison to popey 's [12:48] davmor2, i only have clocks [12:48] sil2100, great, that means that I just have to wait for the bot to let me know is publish and I can free the silo, awesome [12:49] hi psivaa, I've got another MP from someone outside the dev team, which means Jenkins won't run automatically. I've top-approved it now - will Jenkins do the autolanding, or does it need to be triggered manually? -> https://code.launchpad.net/~dholbach/reminders-app/some-lintian-fixes/+merge/218792 [12:51] dpm: ok, i think this issue could be easily solved by adding dholbach to the app developers group. [12:51] fginther: ^^ does that sound doable? [12:52] dpm, if you've top approved it, jenkins will pick it up [12:52] psivaa, right, but I'd prefer not to have to add any folk that sends a MP to the team. I'd like to add them once they've done more sustained contributions [12:53] fginther, psivaa, ok, then top-approval works for me, thanks! [12:53] dpm: fginther: ack, thanks === cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone === john-mca` is now known as john-mcaleely === alan_g|lunch is now known as alan_g [13:06] hello! [13:06] just wondering [13:06] https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+packages [13:06] indicator-network depends on connectivity-api on that same silo [13:06] and now indicator-network build fails as connectivity-api is not built before it [13:07] is it just enough to tricker a rebuild once connectivity-api has fully built? [13:07] or in other words: do the old packages stay in the ppa when rebuild is trickered? [13:08] + another guestion, is it possible to rebuild just one of the packages? [13:16] sil2100: ^ [13:17] Wellark: first answering the last question: yes, you can force a rebuild of only one package ;) [13:17] As for the rest, let me take a look [13:18] Oh [13:18] Wellark: so, in case indicator-network requires a newer connectivity-api, then we would need the build-dependencies to be bumped [13:19] Wellark: if the dependencies would be correct, then even if the packages are built out-of-order, it would only enter a dep-wait [13:19] gah.. it's private api.. [13:20] and no different from a situation when there is a crash for example where you need to land two depending packages at the same time [13:20] sil2100: can't you just kick a rebuild of the indicator-network package on that silo? [13:22] Wellark: hm, need to think about that, since I'm always a bit weary about having a case where theoretically someone would be unable to build indicator-network with dependencies properly installed [13:23] Since for me if something doesn't build with an older version means that we need the build-deps bumped [13:23] BUt I need to think if it's a big of a deal [13:24] the whole marvel of ci train compared to the previous process is that we can actually make a coordinated landing of separate components without doing such bumps etc. if they are not absolutely necessary [13:24] sil2100: it's perfectly safe for this landing [13:25] as long as indicator-network and connectivity-api from that ppa hit the archive atomically [13:25] "atomically" [13:26] This is the point - we can't guarantee that anymore, one of them can get blocked in -proposed by some freak accident [13:26] Just as what happened due to autopkgtest problems [13:26] Let me simply ask a core dev about opinion and then proceed :) [13:27] well, freak accident sounds like unlikely breakage that most probably breaks stuff anyway ;) [13:37] sil2100: any resolution? [13:38] One moment, just finishing my meeting! [13:38] oh, ok [13:39] sil2100: Mirv: what do I do wrong? http://pastebin.ubuntu.com/7416073/ [13:46] Wellark, just use a versioned build dep ... thats why we can use these ;) [13:47] if a version has a new feature you need to make your package not FTBFS it is pretty clear you need to add a ( >= $version) to your build deps ... [13:47] especially since (if your packaging is proper) your binary deps will be generated from this [13:53] Wellark: so, I don't think there's a general policy to block on this, but I think we would really prefer the deps being bumped ;p [13:53] (the landing team is a bit pickish as well... ;p) [13:53] And yes, by 'landing team' right now I basically mean myself [13:53] ;p [13:54] well, if he wants to fix his FTBFS he needs to add that dep [13:54] policy or not [13:54] :) [13:54] * ogra_ thinks thats pretty obvious and nothing to waste time to discuss about :) [13:58] right, you mean just adding a version to build dep [13:58] that I can do [13:58] yeah with a gtreater-equals ... (>= ... ) [13:58] I'm just against bumping the package/so-name if it's not absolutely necessary [13:58] I didn't mean that ;) [13:58] I just wanted the build-dep to be bumped [13:59] well, can't reallly do the = part [13:59] as I can't know what the last will be [13:59] Just do this >= 0.0.1+14.10.20140508.1-0ubuntu1 I guess [13:59] oh, there was a variable for that [13:59] should be enought to do > $latest_released_version though.. [14:00] but but [14:00] dpkg should offer a $version or something [14:00] man deb-substvars [14:00] oh, but that's inside a package [14:00] but you can't do that in build-deps [14:00] I think if you mark it as (>= 0.0.1+14.10.20140508.1-0ubuntu1) it's good idea [14:00] yeah [14:00] for build-deps just remember that the version you use in >= does not actually have to exist [14:00] indeed [14:01] Wellark: since any further re-builds will be anyway greater than this [14:01] you just need to predict what the train will do, roughly [14:01] As cjwatson says :) [14:01] cjwatson: ok, so I can just take $today and slam it in [14:01] you shouldn't use >> $latest_released_version because that will do the wrong thing if somebody else needs to do a no-change rebuild before you land [14:01] but the same would basically be archived by doing ">$last_version_in_debian_changelog" [14:02] oh, right [14:02] maybe the citrain should do this automatically regardless (I might be opening a can of worms though) or with a toggle or heuristics from the packages to be built (check build deps for packages in the same silo) [14:03] sil2100: if I promise to do this on next reconfigure, could we just get the package to be built in the silo for now to enable testing. [14:03] ideally you'd probably want to use a specific new upstream version for the thing you're depending on, if it's part of the landing; that way unless someone actually goes out to bump the upstream version (ie. I don't know, 1.05 instead of 1.0) then >= 1.05 is both short and would work === Ursinha is now known as Ursinha-afk [14:04] I'm pretty sure I need to modify the branches a bit as somebody will dig up a problem [14:04] cyphermox: yeah [14:05] for major features, it's worth it, i think [14:05] also much easier to spot visually [14:05]