=== balloons is now known as Guest90681 === chihchun_afk is now known as chihchun [07:53] trainguards, morning, what need I do about https://requests.ci-train.ubuntu.com/#/ticket/445 ? [07:55] sil mentione binNEW, but not sure why? [07:55] trainguards: morning folks, I just tried to do a dual vivid+xenial landing, and I think I just ended up with both going into the overlay PPA [07:55] should I have done something different for the config for the silo? [07:58] Saviq: looks like you just need a core dev to ack & publish [07:58] * Saviq looks around [07:59] seb128, I can has core-dev ACK on https://requests.ci-train.ubuntu.com/#/ticket/445 please? [07:59] pete-woods: yep, you set the destination to the overlay so that's where the packages went. You'll need a core dev to copy those to xenial now [08:00] Saviq, hey, looking, not a trivial one ;-) [08:00] robru: so if I wanted the overlay PPA for vivid, but not for xenial, what should I have done? [08:01] pete-woods: leave dest ppa field blank because that only controls where the primary series goes. Vivid copies always go to overlay [08:01] robru: right okay, that's good to know, thanks :) [08:01] pete-woods: you're welcome! [08:03] might I ask a passing core-dev if they could copy my mistaken package from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=cmake-extras&field.status_filter=published&field.series_filter=xenial [08:03] Saviq, the summary is unreadable :-/ [08:03] into xenial? [08:03] it's like over a full screen of red bold text [08:03] wth [08:03] pete-woods: it may be helpful to think of it this way: in a dual silo, everything is focused on the primary series. Only the primary series gets tracked in migration, only the primary series let's you set the destination, etc etc. The vivid copies of the packages are sort of just bolted on and hard coded to always go to overlay [08:04] seb128, you mean the landing description? [08:04] Saviq, yes [08:04] https://requests.ci-train.ubuntu.com/#/ticket/445 [08:04] that page [08:04] robru: yeah, that makes sense now, could have sworn this behaviour has change from the past, though [08:04] seb128, it's a behemoth silo, I tried my best [08:04] is there a pointer somewhere to the diff to review? [08:04] anywa, I know what to do now [08:05] seb128: second from top there's a link to the artifacts [08:06] would be nice if there one concatenated diff [08:06] and if the page was not only red text [08:06] pete-woods: nope, vivid copies were always hardcoded to go to overlay. The only thing that changed was that wily copies also went to overlay for a time [08:06] seb128, re: not trivial, the -gles reworks are robru's authorship, replacing the need to set changelog and silo in debian/rules [08:06] but will only work in silo (or when you get the source yourself) [08:06] that feels hackish [08:07] seb128: it is hackish but it has reduced the effort required to maintain gles in real terms and also had slangasek 's approval [08:08] then slangasek should publish it :-) [08:08] Saviq: OK you need to wait 8 hours for Steve to wake up [08:08] did he state somewhere in public that he was ok with those? [08:08] like in a irc log I can read [08:09] seb128: it was in emails but I can't remember if it was on a list or not [08:10] robru, I got the thread you started after that, don't think Steve weighed in in that thread though [08:11] seb128: if you're feeling super generous could you push my mistaken upload to the overlay xenial series into xenial for real when you've finished reviewing Saviq's mega request? (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=cmake-extras&field.status_filter=published&field.series_filter=xenial) [08:11] pete-woods, hey, ok, queuing to have a look next [08:11] seb128: Saviq ugh yes it was private irc where he approved it [08:13] seb128: anyway I have no proof of Steve's approval but just realized that this dramatically reduces the amount of maintainance effort on the gles packages as they don't need to point debian/watch at a new ppa every time they do a release. [08:14] Saviq, robru, diff for other things is fine, I'm happy to press the publish button if you take responsability to deal with potential issues/discussions following the gles changes [08:14] seb128: OK [08:14] seb128, ACK [08:16] Saviq, there you go ;-) [08:16] thank you [08:16] Saviq, nice to see those changes coming btw! [08:16] yw [08:17] seb128, indeed, shame it took so long to land... [08:17] freezes, releases, everything that could delayed it [08:20] Saviq, failed :-/ [08:21] huuuh [08:21] aah [08:22] robru, help ↑ [08:22] robru, the previous release never migrated https://launchpad.net/ubuntu/+source/unity8 [08:23] seb128: oh just hit ignore, that's a bug on silos transitioned from wily to xenial [08:23] but we did rebuild after that landed [08:23] oof [08:23] "IGNORE_VERSIONDESTINATION"? [08:23] seb128: yeah [08:23] let's try that [08:24] you can even see in https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/46/artifact/unity8_packaging_changes.diff that the version was there before :) [08:24] Yeah [08:25] Saviq: most likely the last release was to wily overlay. For some reason xenial-proposed is a bit backed up [08:26] robru, yup [08:36] robru, does train not push to https://code.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-wily-proposed any more? [08:36] only to silo branches? [08:37] Saviq: right. It's the same branch though... [08:37] robru, ok, I didn't get a silo branch (didn't build when you added that), but I'll manage ;) [08:38] Saviq: oh awesome [08:38] Saviq: I can push something manually hang on [08:39] robru, oh if you can that'd help a bit [08:40] yeah just a minute to whip something up [08:51] Saviq: ok I started a mass-push of all branches currently in the train. could take a while until silo 22 shows up: https://code.launchpad.net/~ci-train-bot [08:51] robru, great, thanks [08:51] Saviq: you're welcome! [08:53] oh crap, I hard-coded all the branches to be labelled 'xenial', hopefully that doesn't confuse too many people (any subsequent builds will have correct branch names anyway) ¯\_(ツ)_/¯ [08:54] Saviq: ok 22 is there [08:56] robru, thankski [08:57] Saviq: you're welcome [08:57] Saviq: ah and I've just noticed that train publication is broken, let me fix that... [08:59] robru, check out this trick you just made possible https://requests.ci-train.ubuntu.com/#/ticket/564 ;) [08:59] Saviq: oh god what now [09:00] robru, while I wait for silo 22 to publish, I can use it to seed my new silo ;) [09:00] it == the branch [09:00] Saviq: how did you do that? [09:00] robru, https://code.launchpad.net/~ci-train-bot/unity8/unity8-ubuntu-xenial-landing-022/+merge/275672 ;) [09:00] robru, packages will be in proposed already, so it's just about the trunks [09:01] (or overlay for that matter) [09:01] Saviq: packages aren't in proposed yet ;-) [09:01] robru, yeah, note the "will" be ;P [09:01] Saviq: you can just force-merge the silo to get the same effect but you lose migration tracking that way [09:01] robru, I'm more interested about conflicts for now [09:02] robru, yeah, won't do that in case it's blocked in proposed forever [09:06] rvr, let me know if you have questions about that silo 39. [09:06] jgdx: Ok [09:17] Saviq: *whew* ^^ fixed publishing [09:28] :) [09:31] jibel, davmor2, ogra_, popey: hey, if you guys are not travelling, meeting ;) [09:39] robru, bug in train: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial+vivid/update_excuses.html#unity8 (note the xenial+vivid) [09:39] pete-woods, copied [09:39] Saviq: heh, yep, just fixed that in trunk but probably won't roll it out until tomorrow [09:39] ack :) [09:39] seb128: awesome, thanks! [09:40] yw! [09:43] sil2100, I was in another meeting [09:44] jibel: ok, no worries, we can sync on IRC if needed === _morphis is now known as morphis [10:07] sil2100: when using citrain currently I see: [10:07] The following packages will be REMOVED: [10:07] ubuntu-touch ubuntu-touch-session unity8 unity8-common [10:07] is that expected? [10:08] it is with silo 13 which just contains an updated ofono package [10:08] morphis, did you install another silo with these packages previously? [10:08] jibel: no [10:08] it's the most recent rc-proposed image + silo 13 [10:09] jibel: http://paste.ubuntu.com/12968947/ [10:11] morphis, looking [10:12] rvr, can you confirm that 'silent mode' switches are out of sync between the indicator and system-settings on latest rc-proposed? [10:12] jibel: Checking [10:14] jibel: Yes [10:14] Silent mode active in indicator, off in System Settings [10:14] rvr, k, I'll file a bug [10:14] not sure when it regressed [10:15] rvr, any idea of a silo that could have broke it? [10:15] Hmm [10:15] morphis, no problem *without* citrain [10:16] morphis, trying with citrain now [10:16] jibel: Related to indicator-sound, we had silo 55 with mpris controls, but I don't think that touched silent mode switch [10:21] morphis, and I confirm that with citrain it removes unity8 [10:21] sil2100, ^ any idea? [10:23] jibel: sadly, no, I don't have any knowledge or experience of the citrain commandline tool [10:24] morphis, as a workaround for the moment, you can install the silo manually. switch your device rw, add the corresponding entries to sources.list and pin the silo higher than the overlay [10:25] jibel: yeah, currently looking at citrain [10:25] jibel: http://paste.ubuntu.com/12969030/ [10:25] went through fine now [10:26] The following packages will be REMOVED: [10:26] ubuntu-touch ubuntu-touch-session unity8 unity8-common [10:26] Argh [10:26] jibel: adb shell SUDO_ASKPASS=/tmp/askpass.sh sudo -A apt-get -o Dir::Etc::SourceList=/dev/null update is the faulty line [10:26] rvr: edit citrain and drop -o Dir::Etc::SourceList=/dev/null from the apt-get update line [10:28] morphis, yeah but I don't remember the purpose of this line [10:28] jibel: looks like that is already fixed [10:28] jibel: it only fetches updates from the silos [10:28] not from the archive [10:29] ogra_: hey, you around for some package publishing? :) [10:29] jibel: robru already fixed this with https://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/revision/345 [10:30] morphis: jibel please don't edit the script just install the latest version from the ppa [10:30] rvr: ^ [10:31] robru: Ok [10:31] Ooh [10:31] robru, I don't use citrain :) [10:32] robru, is the patch released? [10:34] jibel: the fix is released in xenial only. If you're using anything prior to that you can get it from either phablet-team/tools or sdk ppa [10:34] robru, I'm on xenial [10:35] jibel: the fix just landed in xenial 4 minutes ago ;-) [10:35] robru, heh :) [10:36] jibel: i dunno why it was stuck in proposed so long, i published it last week [10:39] * rvr is in wily [10:40] rvr, bbl—in two hours ca. [10:41] jgdx: Ack [10:43] rvr, so silent mode switch in system-settings does nothing [10:44] jgdx: ^ [10:44] jibel: I'm checking in stable [10:45] jibel: Oops [10:45] jibel: It's also broken in stable [10:46] jibel: Silo 49 [10:46] jibel: sound-silent-mode-handling https://trello.com/c/y5CFR6eY/2349-452-ubuntu-landing-049-ubuntu-system-settings-kenvandine [10:47] rvr, how did it pass testing? There is an explicit test for that [10:47] jibel: Yes, and I marked it as passed [10:48] jibel: I don't know whether that's the culprit, but seems related [10:49] rvr, it looks like the silo you're testing contains the fix https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/fix-sound-ap-regression/+merge/275038 [10:50] Oh, I didn't finish installing the ppa [10:50] I will check it then [10:51] No bug attached [10:57] jibel: Silo fixes the sync between indicator and System Settings, indeed [10:59] seb128: Do you know which silo introduced the sound regression? [10:59] - property variant silentMode: action("silent-mode") [10:59] 20 property variant highVolume: action("high-volume") [11:00] So it was the one that I tested [11:00] jibel: It was my fault === oSoMoN_ is now known as oSoMoN [11:16] is silo 22 going to land sometime soon? :) (I have a conf at the weekend, wanted to try and demo it) :D [11:17] jibel, don't know how it wasn't picked up in manual testing, but the automated test failed as well and noone noticed. [11:20] though, our suite saw many many spurious failures at that time, so it was easy to miss [11:22] * jgdx really bbl [11:23] jgdx, yeah, there is a test in our regression testsuite and the tester marked it as passed. It's clearly a failure on our side, I'll talk to him. [11:25] popey: ping [11:26] rvr, hello [11:26] popey: Do you know when if music app being updated for mpris controls? [11:26] s/if/is/ [11:27] Heh [11:27] rvr, yes, we are working on it ;-) [11:27] waiting for the media-hub and indicator-sound bugs to be fixed first :-) [11:27] ahayzen: It should land for OTA7 [11:27] rvr, it can't too many bugs at the moment in the background-playlists implementation [11:27] it needs fixing in the platform _first_ [11:28] ahayzen: Are you waiting for ready-for-testing silos? [11:28] rvr, i believe Jim has another one WIP, but i would need to check with him if any are ready [11:29] silo015 looks possible, but i need to link music-app to its new commands to totally test (which i'll do when back from lectures later :-) ) [11:30] ahayzen: Ok, I will test silo 15 after I'm doing with the current one [11:30] I'm done [11:31] rvr, cool, not sure if Jim has any mini-apps to prove that the new command works or is faster [11:32] ahayzen: popey: Can you coordinate with Jim? [11:32] rvr, we are and have been for some time [11:32] Great [11:32] yup :-) [11:32] We keep getting asked about mpris in music app as if _we_ are the blocker here. [11:32] hehe [11:32] Which most certainly isn't the case. [11:33] popey: Sorry, I understood that after the indicator sound landed, only music app update was required [11:33] Yeah, a few people assumed that :) [11:33] hah [11:33] * ahayzen has a list of issues :( [11:33] Fact is, if we gave you the in-progress branch for music app, you'd reject it from QA perspective. [11:34] I don't think mpris should have landed _at_ _all_ until music issues were fixed [11:34] but that's just me :) [11:34] popey, there is work in the scopes which needed it ;-) [11:34] popey: Yeah, I try to test it and it was a failure [11:34] Yeah, it's big and invasive. [11:34] popey: The mpris silo had four or five failures [11:34] Glad ahayzen and jim are working on it. [11:35] erk [11:35] :) [11:35] Ah, the scopes too [11:35] fun times :) [11:36] \o/ [11:36] Hmm [11:42] sil2100: ping [11:43] rvr: pong === _salem is now known as salem_ [11:45] sil2100: Tomorrow is string freeze. Does it make sense to delay to Wednesday the language export, or to make a new one? [11:45] rvr: I think we can make a new one on Wednesday [11:46] Anyway, another auto-export will happen next week anyway [11:47] sil2100: I still wish more frequent exports :( [11:48] For rc-proposed I guess we could have that, since the exports take like 5 minutes anyway [11:48] But for now we can poke manually [12:02] sil2100, once a day is probably overkill but at least one on feature freeze day would be good. [12:04] I originally wanted the syncs to happen on Wednesdays, so after FF, but I remember pitti had some concerns [12:04] But those might have been related to time needed for the exports to happen [12:04] (which is minimal here) [12:05] sil2100, lets freeze a day earlier ;) === xavigarcia is now known as xavigarcia_lunch [12:22] trainguards, qtmir won't migrate in xenial (bug #1510067), I'm gonna force merge&clean in silo 22 and skip the release to xenial, unless you think I shouldn't? [12:22] bug 1510067 in qtmir (Ubuntu) "qtmir rebuild fails with "assertion fail ../../bfd/elf32-i386.c:5245"" [Undecided,New] https://launchpad.net/bugs/1510067 [12:31] Saviq: hm, I think +1 on force-merging [12:31] As long as you'll keep track of that it's fine with me [12:32] yeah I will === alan_g is now known as alan_g|lunch === xavigarcia_lunch is now known as xavigarcia [13:03] sil2100: how do I change silo 48 to xenial+vivid? it was pre-existing and using wily+vivid [13:04] bfiller: hey! You need to reconfigure it to xenial+vivid on bileto and then I'll do a binary copy of your wily packages to xenial [13:04] bfiller: was it ready for release? [13:04] sil2100: no not yet [13:04] sil2100: need to rebuild it first and finish test [13:05] Then I think a reconf to xenial+vivid and a rebuild of all packages would suffice, I'll remove the wily binaries then [13:05] sil2100: thanks [13:09] jibel, hey, I had emailed you a few months ago about getting some non-autopilot integration tests running for media playback...have you learned anything more about who I would need to talk to in order to get these tests automated? [13:10] sil2100: seems builds are failing, out of disk space: https://ci-train.ubuntu.com/job/ubuntu-landing-048-1-build/72/console [13:11] sil2100, +2 on that, https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/43/console [13:12] “mktemp: failed to create directory via template '/tmp/debsign.XXXXXXXX': No space left on device” [13:12] Argh, again [13:12] On it [13:12] thanks! [13:13] hmm, not sure if this will help, could you guys check? [13:14] The instance seems to have some size issues, I already see that there's not too much disk space available in overall [13:14] check wat [13:14] The disk that has all the pbuilders is like 10G, which seems really not enough [13:14] jgdx: check if rebuilding now works [13:15] ack [13:15] !build 47 [13:15] :'( [13:16] okay, in work [13:21] sil2100, failed [13:21] new error msg but same symptom [13:22] hmmm [13:22] same with me [13:23] uh [13:26] http://i.imgur.com/ji1pen2.png === Guest90681 is now known as balloons [13:44] trainguards, can I do a direct push to lp:unity and lp:unity/wily just to make a release (bump version numbers, add changelog...). But I don't want to release that on distro (at least, not yet and not in wily) [13:45] I mean, I want do do an Upstream only release, with new tarball and such... [13:50] sil2100: maybe you know ^ ? [13:50] Trevinho: hey! [13:50] sil2100: hey [13:50] hmmm... why would you want to do an upstream release without releasing it to the archive? [13:50] I mean, well, it poses some problems in the current model [13:51] sil2100: because I don't want to do an "SRU" for wily [13:51] As normally everyone expects that trunk == release [13:52] I just want to close the 7.3.3 gate move all the bugs waiting love there to the 7.4 milestone and release a tarball [13:52] but i wanted that to be on the wily branch, not only on the xenial one [13:53] And if we'll do an SRU to wily later, archive and upstream will sync again [13:55] hm, as said, I would personally prefer only doing releases when an actual release happens, but in the CI Train world we leave branch management to upstreams [13:55] So I guess you can do that, but it would confuse me personally [13:55] mh, ok... All that I don't want is that to break anything [13:56] sil2100: I mean, if the changelog in upstream is newer than the one downstream [13:57] Trevinho: you'll get a warning, nothing to worry about [13:57] ok thanks === alan_g|lunch is now known as alan_g === chihchun is now known as chihchun_afk [14:09] hello trainguards, i've recurring problem with silo 8 - No space left on device [14:10] pstolowski: hey, yeah, it's a known issue, looking into that in a moment [14:10] sil2100, ack, thanks [14:34] sil2100, robru: something seems to be really flawky with the citrain builds: https://ci-train.ubuntu.com/job/ubuntu-landing-052-1-build/64/console [14:35] tried five attempts but all failed: first because of no space, second cause of package upgrade, after that they fail with some jenkins errors [14:35] Yeah... [14:38] Poking IS/webops [14:38] Since this is something I can't help with, as now jenkins jobs fail running at all === sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: CI Train jenkins has disk-space issues [14:47] jgdx: Approving silo 39. [14:47] rvr, thanks. [14:58] sil2100: ok [14:59] Webops are on it, they're trying to make more space [14:59] For now they freed up some but this might not be enough [15:01] morphis, bfiller, pstolowski: could you guys re-try your builds? [15:02] ok [15:02] Webops moved the pbuilder stuff to persistent storage, symlinking to the original place, want to see if it didn't break anything [15:02] sil2100: running again [15:16] mterry: mind publishing silo 23? [15:16] cihelp hey, can we please switch unity8-ci job to vivid and xenial? thanks [15:16] bfiller, let me look [15:21] bfiller, done ^ [15:21] mterry: ty [15:24] \o/ [15:24] mterry: can I ask you for some other publishings? :) [15:24] sil2100, sure [15:24] mterry: https://requests.ci-train.ubuntu.com/#/ticket/519 :) [15:25] sil2100, why no QA on an SRU? [15:25] * mterry is often confused about what needs QA [15:25] mterry: it's a non-touch package, we only do QA sign-off for touch projects [15:25] (non-touch packages) [15:25] sil2100, ok [15:26] SRUs get the QA in the SRU queue :) [15:26] sil2100, fair... [15:28] morphis, bfiller: the train working fine for you guys? [15:29] sil2100: doesn't seem to be working correctly for silo 48.. not seeing anything building on the ppa [15:29] same for 47 [15:29] sil2100: still building :) [15:29] sil2100: stuck on "preparing packages" [15:30] sil2100: and silo 23 which mterry published seems to be stuck on status: publishing [15:32] rvr, jibel: can we have pay-ui in the qa review queue before the pay-service silo? this way the pay-ui change can be tested against the current pay-service, and we can get it in the store so that the new pay-service silo will then get tested against the new pay-ui too [15:32] dobey: Sure [15:32] bfiller: looks like it moves ;) [15:32] rvr: great, thanks [15:34] sil2100, https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/47/console [15:34] is that still the space issue? [15:35] Saviq, We're still in the process of getting builds setup for xenial. I'll add unity8 to the list once it's ready. [15:36] fginther, ack, thanks [15:37] jgdx: try again now, we just recently 'fixed' the space issue [15:37] jgdx: I had to ask webops for help as I didn't have enough power myself [15:43] josepht, how's the re-deploy of my jenkaas coming? I'm thinking it might be useful to test the backup and restore as well. Can we manually take a backup before doing it though so I don't hate my life in redoing things? :-) [15:46] balloons: the MP just landed. You will now need to request an upgrade of your jenkaas from IS. I'd discuss with them doing a manual backup as well. I don't think we have the means to easily backup the master from a job since we don't allow execution of jobs on the master. [15:47] fginther, psivaa: have a missed anything? ^ [15:47] Ursinha: do you want to request the core-apps upgrade or should balloons do it? [15:49] bregma: ping [15:50] josepht, ok, I'll make doubly sure I have a backup, and then I'd like to do a full redeploy if you don't mind. It needs to be tested [15:51] josepht, balloons, Correct, we don't have means to do a manual backup ourselves (we can make a backup of all the job configurations if that helps). IS can probably do that if specifically asked [15:51] bregma: hey! So, I want to publish silo 55 [15:52] fginther, how would you back up the job configs? That would represent a big portion of what's needed atm anyway, as little real data is in there right now [15:52] only about a week's worth [15:52] balloons, this is what I use - http://bazaar.launchpad.net/~canonical-ci-engineering/uci-jenkins-utils/trunk/view/head:/jenkins-dump-config.py [15:52] bregma: actually, I see everything is ok, so nvm :) [15:53] balloons, it has a dependency on 'python-jenkins' from https://launchpad.net/~jenkaas-hackers/+archive/ubuntu/tools [15:55] sil2100: I think if it publishes, then the last two changelog entries that are currently in the archive will be wiped out. [15:55] balloons, I have a script somewhere to push a config.xml file to jenkins as a job configuration. I should get it added to uci-jenkins-utils [15:55] sil2100: A core dev updated libertine underneath this landing. [15:55] ChrisTownsend: no problem, those were quick-fixes, I checked that those are actually 'fixed' in the landing itself [15:55] sil2100: Right, I was just meaning the changelog history. [15:56] Yeah, that's ok [15:56] sil2100: Ok, then I won't worry about it:) Thanks! [15:58] fginther, this looks great thanks. It will at least keep the job configs. I bet python-jenkins can do other fun things with automating job creation. Have any scripts around restoring jobs, or making a set of jobs from a template [16:00] balloons, I've relied on python-jenkins for most of my scripting in the past. It's not perfect, but it has a simpler API for most tasks (vs using curl for example). And yes, we've done some work around templating, this is basically what lp:cupstream2distro-config is for [16:01] balloons, But I am in now way endorsing lp:cupstream2distro-config as a way to solve any current or future problem :-) [16:01] fginther, is cu2d sticking around for the foreseeable? [16:11] robru, hey, does train only push to lp:~ci-train-bot/ on successful builds? [16:12] Saviq: not sure if that changed or not, but in the past it was pushed only on publish [16:12] sil2100, yeah, that changed [16:12] sil2100, https://code.launchpad.net/~ci-train-bot [16:12] ACK [16:13] just wondering when (i.e. I predict a build failure, but that's when I could use the branch ;)) [16:15] sil2100, fginther: anyone know what's up with the calexda-pbuilder instances? they've all been busy for quite a while. trying to build http://s-jenkins.ubuntu-ci:8080/view/click/job/camera-app-click/ and building silo 48 taking forever waiting for builders [16:18] bfiller, There is a large number of builds in progress right now on s-jenkins. All the builders are working right now, just appears to be an unusually high demand [16:19] fginther: ok [16:21] sil2100, okay, thanks. [17:01] sil2100, no disk space problem in silo 8, but there's something wrong with dependencies [17:01] pstolowski: dependencies? [17:04] sil2100, http://pastebin.ubuntu.com/12971383/ [17:05] hmm not sure if it actually breaks anything [17:40] robru: FYI, here https://ci-train.ubuntu.com/job/ubuntu-landing-011-1-build/306/consoleFull I got this [17:40] 2015-10-26 17:14:20,157 INFO Checking bamf for new commits... [17:40] 2015-10-26 17:14:20,382 INFO bamf has no new commits, skipping. [17:40] 2015-10-26 17:14:20,383 INFO Checking compiz for new commits... [17:40] it was a clean build though [17:43] jhodapp: Silo 15 approved [17:43] rvr, yay! [17:43] thanks [17:44] robru, mind publishing silo 15 please? [17:45] rvr, I feel like I asked this of you before but I forget what you said, but do you have publish permission as well? [17:59] cyphermox, ping === alan_g is now known as alan_g|EOD [18:00] jhodapp: if it's all MPs and no packaging changes then you can publish your own [18:01] robru, unfortunately it's not, includes a qtmultimedia source package change [18:01] Saviq: it pushes the branches after a successful merge. [18:01] robru, so if everything is to land in the overlay ppa, then I have permissions...is that accurate? [18:01] jhodapp: ah, you need a core dev then [18:02] yep [18:02] jhodapp: nope, train treats overlay just like real archive, requires same permissions [18:02] robru, oh good, missed it somehow [18:02] robru, then what's the general rule for which I have permission to publish? [18:03] jhodapp: if there silo contains only MPs, no manual sources, and no packaging changes [18:03] robru, ok [18:04] ogra_, you're a core dev, care to publish my silo 15 if you're around? [18:05]