[00:27] <robru> Qa is on fire
[04:34] <Mirv> morning
[05:26] <Mirv> mzanetti: what's the status of https://requests.ci-train.ubuntu.com/#/ticket/19 btw?
[05:27] <Mirv> I guess stalled since the branches aren't approved
=== marcusto_ is now known as marcustomlinson
=== chihchun_afk is now known as chihchun
[06:41] <morphis> robru: ping
[06:41] <robru> morphis: hola
[06:43] <robru> morphis: right let me just look at that branch again
[06:44] <morphis> ok
[06:44] <morphis> robru: there is another one from davmor2
[06:44] <morphis> which adds a autoremove
[06:45] <robru> morphis: ok well we can put them in a silo together
[06:45] <robru> morphis: do you want to make the request or should I?
[06:45] <morphis> robru: so landing through a silo?
[06:45] <morphis> from what I've heard those things need to go into a different ppa
[06:45] <robru> morphis: yeah it's just easier for me that way
[06:46] <morphis> ah ok
[06:46] <morphis> robru: can do that rather quick
[06:46] <robru> morphis: yeah I can copy it to the correct PPA when we're done but just to build the packages it's easiest for me in a silo
[06:46] <robru> just the devil I know
[06:47] <robru> morphis: can you tell me what you're doing with policy-rc thing there? I'm not familiar with that
[06:48] <morphis> robru: you mean https://code.launchpad.net/~morphis/phablet-tools/multiple-silos ?
[06:49] <robru> morphis: no I mean "adb shell "echo 'exit 101' | SUDO_ASKPASS=/tmp/askpass.sh sudo -A tee /usr/sbin/policy-rc.d""
[06:49] <robru> morphis: on https://code.launchpad.net/~morphis/phablet-tools/citrain-changes/+merge/271094
[06:49] <morphis> ah
[06:49] <morphis> basically that prevents us from restart/start/stop any services during the upgrade
[06:50] <morphis> which isn't really what we want and unneeded as we reboot anyway at the end
[06:52] <robru> ok
[06:52] <morphis> robru: dual landing silo?
[06:52] <robru> morphis: yep
[06:53] <morphis> robru: also have a look at https://code.launchpad.net/~morphis/phablet-tools/multiple-silos/+merge/271621
[06:53] <robru> morphis: I just made a comment ;-)
[06:53] <morphis> :)
[06:54] <morphis> robru: fixed
[06:55] <robru> morphis: ok thanks
[06:57] <robru> morphis: uh, just put 'n/a' in the test plan field or something
[06:57] <morphis> robru: just adding a test plan
[06:58] <robru> morphis: I don't know why I made that field mandatory, I am *awful* about just typing garbage in there to appease the check.
[06:59] <morphis> hehe
[07:01] <robru> nooooo
[07:02] <robru> morphis: I guess you'll have to merge the merges yourself and then we'll just put one megamerge into the train
[07:03] <morphis> I see
[07:08] <Mirv> well the test plan being mandatory is a very good thing, all actual components require to have it in there and it also reminds upstreams of "oh did I need to test this?" :)
[07:11] <robru> Mirv: yeah you're right, it just annoys me because I constantly have "fake" landings in staging where I have to fill crap out in there that nobody will read ever
[07:11] <robru> morphis: did you need help merging? I can do it if you want
[07:12] <morphis> robru: done
[07:12] <morphis> https://code.launchpad.net/~morphis/phablet-tools/combined-citrain-changes/+merge/272339
[07:12] <morphis> already building
[07:12] <robru> morphis: oh hah the page must not have refreshed for me
[07:14] <robru> morphis: should we hassle davmor2 to test it?
[07:15] <morphis> robru: why not
[07:19] <robru> davmor2: davmooooooooor
[07:24] <robru> morphis: ok well it's after midnight for me, once davmor2 has tested it and found it to not horribly break everything, get Mirv to hit publish for you, and also copy the package into phablet-tools ppa, and then it should all automerge after that
[07:25] <morphis> robru: sounds great!
[07:25] <robru> morphis: actually come to think of it you should be able to publish it yourself seeing as there's no packaging changes
[07:26] <morphis> would be good to try that :)
[07:29] <robru> morphis: ok but you still need Mirv to copy the package into phablet-tools ppa, that's a manual step
[07:30] <Mirv> well and we'll want to have ~vivid and ~trusty builds in the SDK PPA too...
[07:31] <robru> Mirv: we support citrain tool in trusty?
[07:32] <robru> Mirv: I understand we support SDK in trusty for app devs but I didn't think anybody was using trusty to install silos on their phones.
[07:36] <pstolowski> hey trainguards, may i ask for purging mediascanner2 package out from silo 4 ppa?
[07:48] <robru> pstolowski: ok done (sorry for delay I assumed Mirv would do it)
[07:48] <pstolowski> robru, thanks!
[07:48] <robru> pstolowski: you're welcome
[07:49] <pstolowski> robru, btw, would be great to have it available via a button in bileto, i needed it already a couple of times
[07:50] <robru> pstolowski: yeah, train used to remove packages automatically when you reconfigured them away but we had problems where that wasn't always what we wanted to we had to neuter that
[07:50] <pstolowski> robru, i see, still perhaps a manual action would be ok?
[07:50] <robru> pstolowski: file a bug against lp:cupstream2distro if you want, might be a way off
[07:51] <robru> pstolowski: yeah it makes sense, just like being able to manually retry failed builds, just not a huge priority amongst the other bugs
[07:51] <Mirv> robru: well Pat wanted phablet-tools to be up-to-date in SDK PPA too, so I guess some silo using landers use LTS too
[07:52] <robru> Mirv: humm well that'll require a rebuild
[07:52] <Mirv> robru: sure, that's how the current ones are done, but those can be done manually.
[07:52] <robru> ok
[07:52] <robru> Mirv: can you take care of that pls? ;-)
[07:52] <Mirv> as soon as it lands, I can build ~vivid and ~trusty rebuilds, have them in the testing SDK PPA for a while and then copy
[07:52] <Mirv> robru: yes
[07:53] <robru> Mirv: great, thanks
[07:53] <robru> Mirv: last time I did an update to phablet-tools I didn't update SDK PPA so I guess that's quite old now
[07:58] <pstolowski> robru, https://bugs.launchpad.net/cupstream2distro/+bug/1499633
[07:58] <ubot5> Ubuntu bug 1499633 in CI Train [cu2d] "Provide a button for purging associated silo from bileto" [Undecided,New]
[07:59] <Mirv> robru: me and Zoltan have been updating it occasionally
[08:01] <robru> ah
[08:01] <robru> pstolowski: thanks
[08:07] <mzanetti> Mirv, we're still trying to land it... but it's a tricky one. getting close though
[08:11] <Mirv> ok!
[08:18] <Saviq> psivaa, hey, can you please push mir, qtmir, qtmir-gles, unity-system-compositor through migration?
[08:19] <jibel> we're out of silos to tests :(
[08:19] <jibel> dbarth, can you have silo 40 reviewed and top approved?
[08:20] <jibel> morphis, same for silo 51, MR is not review and top approved
[08:20] <jibel> reviewed*
[08:20] <Saviq> jibel, I'll have one for you soon, waiting for mir to migrate to rebuild a bit and test
[08:20] <Saviq> psivaa, although the boottest failure there is much different
[08:20] <morphis> jibel: robru needs to do that
[08:21] <morphis> or somebody else
[08:22] <psivaa> Saviq: that would be a task for 'trainguards'
[08:22] <robru> psivaa: Saviq not trainguards, release team
[08:22] <jibel> morphis, what is /usr/sbin/policy-rc.d ? It doesn't exist on my phone
[08:23] <Saviq> psivaa, it's only hanging on boottests now
[08:23] <Saviq> afaict?
[08:23] <robru> Saviq: what request?
[08:23] <Saviq> robru, 365
[08:23] <Saviq> https://requests.ci-train.ubuntu.com/#/ticket/365
[08:23] <morphis> jibel: it prevents services from being started/stopped/restarted during the upgrade
[08:23] <Saviq> no UNAPPROVED there
[08:24] <morphis> jibel: which doesn't make sense in the device-upgrade case
[08:24] <morphis> and just gives problems
[08:24] <robru> Saviq: psivaa: yep looks like all boottest failures
[08:25] <psivaa> Saviq: ohh, i was under the impression that boottest was being disabled for proposed migration
[08:25] <psivaa> i wasn't sure if that was already done.
[08:25] <jibel> morphis, okay but the first cp will fail since it doesn't exist, and the mv at the end will fail too because /tmp/policy-rc.d won't have been created by the cp or I'm missing something?
[08:25] <Saviq> psivaa, must've been re-enabled then...
[08:25] <psivaa> Saviq: not sure, but i'll make them 'PASS@
[08:25] <psivaa> *'PASS'
[08:25] <jibel> morphis, so you'll end up with the file that always exit 101
[08:26] <Saviq> psivaa, thanks, I'll test my dependency-fixed silo asap
[08:26] <dbarth> jibel: ack
[08:26] <Saviq> psivaa, you might want to look at those failures, though, as they don't seem to reach the phone at all
[08:27] <Saviq> psivaa, actually just the qtmir-gles one, not sure that's expected
[08:28] <jibel> mzanetti, do you know if silo 19 is still needed https://requests.ci-train.ubuntu.com/#/ticket/19 ?
[08:28] <Saviq> psivaa, "ERROR: No packages to install!", which is correct for qtmir-gles
[08:28] <psivaa> Saviq: qtmir-gles has never passed, we make it 'PASS' manually
[08:28] <Saviq> ok
[08:28] <dbarth> jibel: top approved, and i marked ready for qa; need another flag change ?
[08:28] <morphis> jibel: the original one will be restored
[08:28] <mzanetti> jibel, yes, still trying to land it
[08:28] <jibel> okay
[08:28] <jibel> morphis, the point is that there is no original one
[08:29] <Saviq> psivaa, can't you make it skip? qtmir-gles is only used on the emulator
[08:29] <morphis> jibel: woot?
[08:29] <psivaa> Saviq: not at the moment, the infra does not allow us to skipp
[08:29] <psivaa> easily i mean
[08:29] <morphis> jibel: interesting
[08:29] <morphis> that was the case when I wrote this (some time ago)
[08:30] <jibel> morphis, $ ls /usr/sbin/policy-rc.d
[08:30] <jibel> ls: cannot access /usr/sbin/policy-rc.d: No such file or directory
[08:30] <Saviq> psivaa, shouldn't "no packages to install" be a PASS? doesn't it just mean that the tested package has no packages on the phone and as such, boottest is moot?
[08:30] <morphis> jibel: good finding, let me check for this in the script
[08:30] <Saviq> psivaa, the u-s-c failure is weird fwiw http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-unity-system-compositor/lastBuild/?
[08:32] <jibel> morphis, okay, I'll remove it from the ready queue
[08:33] <jibel> please resubmit once it's fixed
[08:33] <mzanetti> jibel, IMO this should not be low tbh: https://bugs.launchpad.net/ubuntu/+source/ust/+bug/1404302
[08:33] <ubot5> Ubuntu bug 1404302 in Canonical System Image "liblttng-ust0 Error opening shm /lttng-ust-wait-5" [Low,Confirmed]
[08:33] <jibel> dbarth, it's all good, next on the queue
[08:34] <mzanetti> jibel, it's the most annoying thing in our developer experience IMHO
[08:34] <jibel> mzanetti, what's the impact of this bug?
[08:34] <psivaa> Saviq: yea, 'No packages to install' should be a pass, but as of now we dont have that automated
[08:34] <mzanetti> jibel, it makes it really hard for app developers read their logs, as they are completely spammed by this
[08:38] <dbarth> cool
[08:39] <jibel> mzanetti, okay I don't mind increasing the importance, more important is to know who could look at it.
[08:39] <mzanetti> jibel, I agree :D
[08:42] <jibel> mzanetti, assigned to Pat for now until he finds a owner.
[08:52] <Laney> what is going on with boottest? https://jenkins.qa.ubuntu.com/job/wily-boottest-gst-plugins-bad1.0/lastBuild/console
[08:53] <Laney> (twice, and looks like its going to happen for -ugly too)
[08:55] <morphis> jibel: ok, update the MP to to handle that correctly
[08:58] <popey> Mirv: this may be a dumb question, sorry. What reason is there for there being no debs in http://ports.ubuntu.com/pool/universe/q/qtbase-opensource-src-gles/ ?
[09:04] <Laney> popey: this is only built for i386 and amd64, neither of which live on ports.ubuntu.com
[09:05] <popey> Laney: is there some reason why that's the case? (the building, not the hosting)
[09:05] <Laney> don't know
[09:05] <popey> ok, ta
[09:21] <Mirv> popey: it's the OpenGL ES version while the normal x86 version is normal OpenGL. and you know, armhf is already the mobile / OpenGL ES version so it wouldn't make sense to have a double build of the same.
[09:21] <Mirv> popey: it's only needed because emulator requires ES (and because Qt does not yet support runtime switching between the two, coming maybe in Qt 5.7)
[09:22] <Mirv> popey: if something is trying to install those on non-x86, it's doing it wrong - like the boottests are/were doing.
[09:23] <davmor2> mzanetti: more importantly it is taking up valuable space
[09:23] <mzanetti> davmor2, what exactly?
[09:23] <mzanetti> the lttng logging issue?
[09:23] <davmor2> mzanetti: the lttng
[09:24] <mzanetti> yes, that too
[09:24] <davmor2> mzanetti: if it is repeating in every log those few bytes become quite large quickly
[09:25] <mzanetti> davmor2, it is repeated twice every second in roughly 80% of the apps
[09:29] <jibel> davmor2, not that much
[09:29] <jibel> zgrep ltt ~/.cache/upstart/* | wc -c
[09:29] <jibel> 236546
[09:31] <davmor2> jibel: so about 11Mb give or take
[09:49] <Saviq> psivaa, hey, any word on the boottests failures for mir, qtmir, unity-system-compositor?
[09:50] <psivaa> Saviq: battling with them at the moment, a couple of attempts failed to provision,
[09:50] <psivaa> Saviq: i'll let you know once they complete consistently
[09:56] <Saviq> psivaa, hmm I thought you're skipping them because they won't pass (unless you upgrade unity8 along, that is)?
[09:59] <psivaa> Saviq: qrmir had passed in the last attempt on the 22nd http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-qtmir/25/
[09:59] <psivaa> that actually prompted me to re-run that just to make sure
[10:01] <Saviq> psivaa, it's all the same problem as unity8
[10:03] <psivaa> Saviq: ok, let me 'PASS' them then
[10:03] <Saviq> psivaa, that qtmir PASS looks weird, nothing really got upgraded there
[10:03] <Saviq> 0 upgraded, 0 newly installed, 0 to remove and 329 not upgraded.
[10:05] <Laney> psivaa: are you going to fix the provision failures in boottest and retry the ones which hit it?
[10:16] <psivaa> Saviq: u-s-c and qtmir should now get 'PASS' results
[10:17] <psivaa> Laney: I'm not going to do anything right away. There are a lot of them. I'd discuss with the team this afternoon. We were told by Ursinha that boottest were being disabled in p-m.
[10:18] <Laney> Well someone on the release team would need to do that then
[10:18] <Laney> Who did Ursinha talk to?
[10:18] <sil2100> Is the boottest disabling definite already?
[10:19] <sil2100> I though we were waiting for Steve to put in his 5 cents, as he had some objections the first time this came up
[10:19] <psivaa> Not sure, hopefully we'd know it soon enough when she comes online :)
=== psivaa is now known as psivaa-afk
[10:22] <Saviq> psivaa-afk, just to remind mir itself is in the same situation... and sorry for being pushy...
[10:24] <Laney> It's blocking many things
=== psivaa-afk is now known as psivaa
[10:40] <psivaa> Saviq: i'll take care of mir as well
[10:46] <abeato> rvr, ping
[10:54] <penk> ping cihelp
[10:56] <psivaa> penk: hello, ask the question please :)
[10:57] <penk> psivaa: so I have a job setup on jenkins
[10:57] <penk> psivaa: but it's not pulling the bzr branch I configured, but only "bzr pull --overwrite"
[10:58] <psivaa> penk: the link to the job?
[10:58] <penk> psivaa: http://s-jenkins.ubuntu-ci:8080/view/cambridge/job/BQ%20Tarball%20Vivid/39/console
[11:06] <Saviq> psivaa, hmm, qtmir still boottest failed, that's the last one
[11:07] <psivaa> Saviq: sorry about that, was a typo on my part
[11:12] <psivaa> penk: if you use 'Source Code Management' then i think it will only pull, if you'd want to use bzr branch every time, you'd need to use that explicitly inside 'Execute shell' section
[11:13] <penk> psivaa: but the repo is really huge, so I think source code management is the right setting, is there a way to "clean up" current repo?
[11:14] <penk> psivaa: we restricted the project to be run on calxeda-pbuilder
=== alan_g is now known as alan_g|lunch
[11:14] <psivaa> penk: what will be the difference, using 'bzr branch' all the time vs  'bzr pull && clean'
[11:15] <penk> psivaa: so in my case would you suggest using bzr branch in execute shell?
[11:16] <penk> psivaa: I was thinking that the clean would be one-time issue, I'm not aware of the repository status, it might be messed up
[11:16] <psivaa> penk: i'd think so, if you're not happy with bzr pull --overrite
[11:17] <penk> psivaa: I see, I'm going to try that approach now, thanks
[11:17] <Ursinha> Laney, sil2100, the boottest disabling is being discussed and people are in favor of disabling it; I don't know if that's settled or not, but I haven't seen arguments against that
[11:17] <Ursinha> I'm sure this is going to be properly (and widely) announced before it happens
[11:18] <Laney> Ursinha: ok, well in the meantime it seems to have fallen over so is it possible for someone to browse http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and help deal with the failures?
[11:20] <Ursinha> Laney, let me catch up with that discussion
[11:26] <Ursinha> Laney, psivaa, so sil2100 is right that people are waiting for slangasek to return next week to decide if they're disabling boottesting now; psivaa, we have to evaluate the problem today and unblock what's possible
[11:27] <Ursinha> as that's not disabled yet so we should handle it as usual
[11:27] <psivaa> Ursinha: right, i created a card for this: https://trello.com/c/NO2t3x5i/613-vanguard-boottest-failures-needs-attention
[11:28] <rvr> abeato: pong
[11:29] <Ursinha> psivaa, thank you! Laney, ^
[11:30] <Laney> cheers
[11:41] <Mirv> davmor2: dbarth: the ^ 040 claims to be landing only account-plugins but in reality the account-polld was also there still (just removing it from the MP:s doesn't automatically remove the packages from the PPA). do you think it's ok to publish (without account-polld) or do you want to re-test after I remove the account-polld for real?
[11:44] <davmor2> Mirv: Meh account-plugin-facebook account-plugin-flickr account-plugin-google account-plugin-tools account-plugin-twitter account-polld indeed.  The ticket read removed account-polld from the silo for the time being so I only checked for plugin-facebook
[11:45] <davmor2> Mirv: I think if the account-polld was went to be removed we would need to do that and retest, there was obviously a reason it was removed
[11:46] <Mirv> davmor2: yep. dbarth: please confirm and ask us to remove the account-polld for real, then let's have QA re-test the silo.
[11:48] <davmor2> Mirv: hmm unless the changes in account-polld were removed and this is only here to pull in the plugin changes maybe, wait on a reply from dbarth I guess
=== psivaa is now known as psivaa-lunch
[11:49] <Mirv> davmor2: yeah, I won't remove it at the moment until there's some more information on what was supposed to happen.
[12:35] <jibel> morphis, any reason the phablet tools update is not an SRU and is landing through a silo instead?
=== chihchun is now known as chihchun_afk
[12:41] <popey> Mirv: the reason I ask  is because docviewer is trying to use something which I believe is in there. I am trying to build that on my armhf schroot, but can't because I can't fulfil that dependency on armhf. What should I use instead on armhf?
[12:43] <popey> Mirv: line 49 http://paste.ubuntu.com/12553914/
=== karni-away is now known as karni
=== alan_g|lunch is now known as alan_g
[13:16] <Mirv> popey: the normal packages, qtbase5-dev etc
[13:17] <popey> Mirv: I have that installed
[13:17] <Mirv> popey: I'm not sure where you see the dependency to -gles?
[13:17] <Mirv> popey: dpkg -L qtbase5-dev | grep QStorage shows the file being there
[13:18] <popey> so I don't know why cmake isn't finding it :(
[13:18] <Mirv> popey: maybe the include path doesn't contain QtCore, or if it containst include/qt5 maybe the include should be QtCore/QStorageInfo
[13:19] <popey> hmmm
[13:22] <mterry> robru, citrain doesn't seem to accept silo numbers higher than 30?
[13:28] <jgdx> trainguards: is silo 22 being published or should I do that manually?
[13:29] <Mirv> jgdx: it should be published already, but the wily part is in proposed pocket
[13:29] <Mirv> so it hasn't yet merged to trunk
[13:29] <kenvandine> oh... i pushed publish just now :)
=== salem_ is now known as _salem
[13:29] <jgdx> Mirv, kay
[13:29] <Mirv> sudo publish :)
[13:29] <kenvandine> status didn't say it was publishing or anything
[13:30] <kenvandine> guess my page was stale
[13:30] <jgdx> wut
[13:30] <Mirv> now it probably doesn't track it anymore and the silo should be manually merge + cleaned instead
[13:31] <kenvandine> ugh
[13:32] <Mirv> ..or maybe it still does!
=== _salem is now known as salem_
[13:35] <jgdx> [robot voice] it's merged and everything is cool
=== psivaa-lunch is now known as psivaa
[14:06] <morphis> sil2100, kenvandine: can someone do a upload to a silo for me?
[14:07] <sil2100> morphis: sure, what's up?
[15:35] <fginther> sil2100, so, boottest is completely useless right now as there are no usable images on the ubuntu-touch/devel-proposed/krillin.en. Who is the best person right now to waive this as a requirement?
[15:41] <rvr> popey: Is there any reason why reminders requires an space for a notebook's title?
[15:43] <popey> rvr: is this that the OSK doesn't inject the text until you hit space?
[15:43] <popey> rvr: I thought we fixed all those. mzanetti ^
[15:43] <rvr> popey: I can type, but the save button is not activated until I type an space.
[15:44] <popey> OSK input issue by the sounds of it. rvr is this rc-propsoed or OTA-6?
[15:44] <rvr> popey: rc-proposed
[15:44] <rvr> popey: r490
[15:44] <popey> known uitk issues in rc-proposed
[15:45] <popey> we target OTA-6, there's at least one known UITK issue in the versions beyond OTA-6 which are in flight
[15:45] <sil2100> fginther: yeah, so I think we would still like slangasek to get back first
[15:45] <rvr> popey: Oh, target is OTA6
[15:46] <rvr> popey: Please, next time add that info to the silo, otherwise I test with rc-proposed
[15:46] <fginther> sil2100, so I'm asking if we should do anything prior to his return? Is it acceptable to just let those packages continue to be blocked? Nothing can pass right now.
[15:46] <popey> rvr: will do.
[15:46] <rvr> popey: Thanks!
[15:46] <rvr> Ok, flashing OTA6...
[15:47] <fginther> sil2100, I'm happy waiting, just want to know if that's ok for the train as well
[15:47] <sil2100> fginther: until we have a final decision, I would prefer if we continue to skip the boottests... not sure who is the person doing that though
[15:50] <fginther> sil2100, Is there a core-dev that could weigh in on this? Perhaps just to say 'pass everything until the network bug is fixed'?
[15:51] <sil2100> fginther: I think it would have to be someone from the release team - so in slangasek's absence, maybe we could poke infinity with that?
[15:56] <fginther> sil2100, ack. infinity any recommendation on disabling boottest while the base images are unusable due to 1496434 ?
[15:56] <fginther> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1496434
[15:56] <ubot5> Ubuntu bug 1496434 in network-manager (Ubuntu) "network-manager crash on boot on krillin/devel-proposed" [High,Confirmed]
[16:19] <jibel> fginther, do you know how to disable these tests?
[16:20] <fginther> jibel, boottest as a whole can be disabled via a britney rc file
[16:20] <jibel> fginther, you can do it?
[16:21] <jibel> or need someone from ubuntu-archive?
[16:21] <fginther> jibel, I can not do it myself, but I can point someone to it
[16:21] <fginther> jibel, right, need ubuntu-archive member
[16:21] <jibel> fginther, go ahead, disable it.
[16:21] <jibel> or find someone :)
[16:21] <jibel> just boot tests
[16:22] <fginther> jibel, this is all that's needed: http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/431
[16:23] <jibel> infinity, ^
[16:26] <jibel> cjwatson, can you help with disabling boot tests ^
[16:27] <cjwatson> jibel: correction to the above, it needs an ubuntu-release member, not ubuntu-archive; I'm no longer in ubuntu-release
[16:27] <fginther> jibel, if it helps, here's an MP: https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442
[16:27] <jibel> cjwatson, ah sorry
[16:29] <jibel> not many are online.
[16:29] <rvr> popey: Same problem with com.ubuntu.reminders_0.5.490_multi.click and ubuntu-touch/stable/meizu.en #4
[16:29] <rvr> popey: No space, no "save"
[16:29] <jibel> Laney, around?
[16:29] <popey> gah
[16:30] <Laney> hi jibel
[16:30] <jibel> Laney, can you disable boot test until wily phone images are fixed?
[16:30] <jibel> Laney, https://code.launchpad.net/~fginther/britney/disable-boottest/+merge/272442
[16:31] <popey> rvr: okay, sorry I really thought we'd nailed that one :(
[16:31] <Laney> jibel: Is someone working on fixing the image?
[16:32] <jibel> Laney, it's a crash of n-m assigned to awe_ but there is not much movement. bug 1496434 for reference
[16:32] <ubot5> bug 1496434 in network-manager (Ubuntu) "network-manager crash on boot on krillin/devel-proposed" [Critical,Confirmed] https://launchpad.net/bugs/1496434
[16:33] <jibel> Laney, it won't be fixed tonight
[16:36] <awe_> jibel, sorry... I hadn't seen that it'd been assigned, and this is the first time anyone's ping me about it
[16:37] <awe_> jibel, I can take a look.  Currently trying to land some other NM changes into wily.  If I can find what's happening, we might be able to piggy back on the same landing
[16:38] <jibel> awe_, sorry, given John's comment I assumed he did.
[16:38] <awe_> unfortunately not; my bad for not reviewing my asssigned folder...
[16:41] <Laney> jibel: How's this only just started happening if n-m hasn't been uploaded in wily since the 11th?
[16:43] <jibel> Laney, apparently CI used an old image to work around the problem.
[16:43] <rvr> popey: No problem :)
[16:43] <Laney> Oh
[16:43] <Laney> and it expired off the server or something?
[16:43] <jibel> Laney, 191
[16:43] <jibel> Laney, it seems so. system-image says 192 is the oldest image
[16:44] <slangasek> Ursinha, sil2100, fginther: the boot tests are there for the phone product team, not for foundations; they should be the ones to make the call whether to disable boottests
[16:44] <Laney> Seems a process fail that nobody was working on it until it became serious. :)
[16:44] <slangasek> does this mean, btw, that someone bypassed a boottest failure for network-manager, thus causing all boottests to be broken?
[16:45] <sil2100> slangasek: ok, well, I think the product team is generally +1 on getting those disabled, but Pat is away still
[16:45] <sil2100> And I know everyone would like to hear your input here ;)
[16:49] <fginther> There have been no recent boottest passes for network manager, but it's unlikely that boottest would have caught the problem as the bug prevents networking, not booting.
[16:49] <fginther> arguably a flaw in the test. It should maybe test booting AND networking.
[16:50] <kenvandine> sil2100, is it ok to publish silo 57 without QA?  it's just a depends change in the libqofono-dev package, so doesn't affect anything in the phone image
[16:51] <sil2100> kenvandine: it's just a packaging change? I hope it doesn't remove any binaries from our phones
[16:51] <kenvandine> nope
[16:51] <sil2100> kenvandine: +1 ;)
[16:51] <kenvandine> just added a depends to the -dev package
[16:51] <kenvandine> cool
[16:52] <sil2100> barry: hey! system-image server code still hosted on bzr?
[16:52] <sil2100> barry: I have a fix for proposal and I need to know if I can simply do a MP against the usual branches ;)
[16:54] <awe_> jibel, flashing my krillin now; have to run to the store to grab lunch.  will try and reproduce after food...
[16:57] <sil2100> barry: anyway: https://code.launchpad.net/~sil2100/ubuntu-system-image/server-fix-pd-builds/+merge/272445
[17:02] <sil2100> barry: I would poke slangasek about it as it's important, but he's on holidays still ;)
=== alan_g is now known as alan_g|EOW
[17:07] <awe_> jibel, reproduced it.  will follow-up after lunch, and work on getting it in our silo for nm/wily
[17:24] <infinity> slangasek: While I agree that involving the people who (should) care about the tests in the discussion is sane, I'm less convinced that "people should be allowed to drastically increase our burden because they think a broken test is important" is a sane position. :P
[17:49] <barry> sil2100: will look
[17:52] <robru> mterry: wat
[17:54] <mterry> robru, nope.  nevermind.  I had assumed that the help message was because my silo was above the listed max in the help message itself.  It's because I didn't give a password.  That could be made clearer when that happens (and the help message could list a higher max silo number)
[17:55] <mterry> Especially since the password is listed as optional.  So without knowing that's the problem, it really isn't clear what the problem IS
[17:56] <robru> mterry: the help message probably shouldn't say a silo number limit at all considering it's not enforced and sooner or later silonumbers will increase without bound.
[17:56] <mterry> robru, true
[17:57] <robru> mterry: also the password IS optional, in the sense that, if you don't have one, you don't need to specify one. or did the phones make passwords mandatory now?
[17:57] <mterry> robru, no.  I get why the help message indicates that it's optional.  But in combination with not telling me that that was the problem, you can see how entering a command "citrain device-upgrade 33" that the help message indicates is sufficient, is confusing
[17:58] <mterry> robru, I just want it to say that I need a password in this specific case, because it detected it
[18:00] <robru> mterry: hm password is required for device-upgrade
[18:01] <robru> morphis: are you still around? I'm going to add a quick branch to the silo.
[18:01] <sil2100> barry: thanks :)
[18:11] <robru> mterry: https://code.launchpad.net/~robru/phablet-tools/fix-help/+merge/272458 just for you, buddy!
[18:12] <mterry> robru, is that first chunk with a $1 on a line by itself intentional?
[18:12] <robru> mterry: yes, that is how it includes the message in the output
[18:13] <robru> mterry: it's inside a here-doc
[18:13] <mterry> robru, ah, I see.  I missed that it was a function, not the main script.  Figured that was some printf-debugging  or something
[18:13] <mterry> robru, thanks man!
[18:13] <robru> mterry: you're welcome
[18:42] <barry> sil2100: the code looks fine on the face of it, but i really don't know what it does ;)
[18:42] <sil2100> barry: well, the generator does some magic for touch image android parts when importing the rootfs, this change makes sure we also do the same for pd (pocket-desktop)
[18:43] <sil2100> barry: pd is touch + a few packages
[18:43] <sil2100> (it's a new project in cdimage)
[18:45] <barry> sil2100: ok
[18:45] <sil2100> Without this, our generated ubuntu-pd images just don't boot ;p
[18:58] <cjwatson> robru: speaking of which, next LP rollout will allow archive owners to set {build,publish}_debug_symbols, and to enable/disable unrestricted processors (currently only amd64/i386, will expand soon as more scalingstack arches come online, but in any case should be enough to test your API interaction)
[18:59] <robru> cjwatson: cool
[18:59] <cjwatson> robru: that's all we intend to open up for non-admins; you'll need a production case that additionally sets authorized_size, relative_build_score, and require_virtualized
[19:00] <cjwatson> but that can be done in the same .lp_save() as {build,publish}_debug_symbols, so it won't be a big variation
[19:00] <robru> cjwatson: so ci-train-bot will become an lp admin?
[19:00] <cjwatson> robru: will roll that out next week, and as far as I know that will be sufficient for your ephemeral PPA work - just let us know when you have code to review, we'd like to review it before giving extra privileges to your bot
[19:01] <cjwatson> robru: not an LP admin, but ~launchpad-ppa-self-admins
[19:01] <cjwatson> which is minimum necessary privilege
[19:01] <robru> cjwatson: ok will do. It'll be a little while before I get there, I have some big bugs to squash first
[19:01] <cjwatson> yep
[19:02] <robru> cjwatson: will there be an API way to check if I'm self-admin or not? I'd rather make the special case based on actual permissions rather than just hardcoding "production =  yes, staging = no"
[19:03] <morphis> robru: that is fine
[19:03] <cjwatson> robru: it's just a team membership, you can check your own team membership
[19:03] <morphis> robru: can you also look at the latest changes I added to my branch?
[19:04] <morphis> need your review on them
[19:04] <robru> cjwatson: oh ok great
[19:04] <robru> morphis: yeah that change looks sensible but I don't have a device to test with so we really need a QA person to confirm for sure that it works
[19:04] <morphis> robru: two things; 1: don't upgrade lxc-android-config which will always (expected), it needs to be upgraded throug recovery
[19:05] <morphis> 2: keep adb on while running citrain even with screen locked
[19:05] <robru> morphis: doesn't powerd also need to be upgraded through recovery?
[19:06] <morphis> robru: not sure
[19:06] <morphis> lxc-android-config is the only one I know off
[19:06] <morphis> robru: have to drop off, lets talk on this on monday
[19:06] <robru> morphis: ok well whatever. I approved the branch and marked the silo ready for qa
[22:12] <cyphermox> fginther: I intend to finalize an upload through a silo this evening, to fix this issue with the boottests ^