[00:14] <alecu> lol at Known Issues on the topic
[00:22] <alecu> ah, I'm doing it wrong.
[00:28]  * alecu understood a bit better how sync works now
[01:19] <camako> trainguards (or anyone around), silo rtm-20 has landed, and now silo utopic-8 needs to be binary-synced... But how do I initiate this sync?
[01:19] <barry> camako: instructions here: https://wiki.ubuntu.com/citrain/NewbieGuide
[01:20] <camako> barry, thanks...
[01:20] <camako> Ursinha ^^
[01:20] <Ursinha> cool :) solved then
[01:27] <camako> barry, the doc says "now every time someone clicks 'Build' on the sync silo, it will try performing a binary copy of all packages in the source silo PPA", but it seems to be building from source :
[01:27] <camako> https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/91/console
[01:40] <camako> o ok never mind, I think it's doing the binary copy..
[02:09] <imgbot> [02:56] <robru> camako: that log definitely shows a binary copy. Don't be fooled by "grabbing code" or whatever crap it says, if it was rebuilding sources there'd be pages and pages of build logs that just aren't there.
[03:09]  * alecu is enjoying the NewbieGuide.
[03:09] <alecu> I was not aware that we landers are the ones supposed to click on "Merge and Clean"!
[03:10] <robru> alecu: yep. I do it a lot because we're often low, buy the original design was for you to watch the whole process and then click merge when you're ready
[03:11] <alecu> great! I'll do it, no problem. I just didn't want to step on anybody's toes!
[03:27] <rsalveti> slangasek: do you know if the issue with image publishing was fixed already?
[03:27] <rsalveti> just wondering if image 275 will show up at some point
[07:35] <tvoss> good morning
[07:43] <jibel> I'm on rtm 14.09 #4 and cannot install package updates. It's stuck on 'Downloading' and downloads never start. Is it a known issue?
[07:44] <seb128> jibel, yes
[07:44] <seb128> jibel, you can delete your u1 account and add it back
[07:44] <jibel> seb128, what is the bug #?
[07:44] <seb128> jibel, it's due to the sso tokens invalidation from this week
[07:45] <seb128> jibel, bug #1378678
[07:45] <jibel> seb128, thanks
[07:45] <seb128> yw
[07:46] <seb128> jibel, you can delete/add it back, the issue is easy to reproduce by going on th website and invalidating a token from there
[07:46] <seb128> e.g no need to keep the buggy state
[08:09] <brendand> sil2100, so holding calls seems to have broken at some point
[08:09] <davmor2> Morning all
[08:09] <sil2100> Morning
[08:09] <sil2100> brendand: you testing on the latest image?
[08:09] <brendand> sil2100, yeah
[08:11] <ogra_> brendand, try entering a url in the browser ...
[08:11] <ogra_> is the keyboard always sideways for you too or is that only me
[08:12] <Saviq> trainguards, hey, I can has silo for line 61 please
[08:13] <sil2100> o/
[08:14] <ogra_> Saviq, i see the slide issue mainly with the "my music" scope, and the dash is very crashy
[08:14] <Saviq> ogra_, you got a lot of music on your phone do you?
[08:14] <ogra_> Sa34G on SD card
[08:14] <ogra_> bah
[08:14] <ogra_> Saviq, 34 on SD card
[08:14] <ogra_> +G
[08:14] <brendand> ogra_, i think that sometimes just happens
[08:15] <Saviq> sounds like  alot
[08:15]  * Saviq needs a large microSD card...
[08:15] <ogra_> brendand, it always happens for me ... there is no way for me to open a url currently
[08:15] <ogra_> (in portrait ... indeed it works in landscape .. but the kbd is stuck)
[08:16] <ogra_> it comes up fine everywhere else, seems to be only the url bar of the browser
[08:16] <sil2100> Saviq: sooo, I see someone allocated unity8 in silo 13 already
[08:16] <sil2100> Saviq: it seems to be ted!
[08:16] <ogra_> (even input fields in pages work )
[08:16] <sil2100> Saviq: you want an ignore-conflicts here?
[08:16] <Saviq> sil2100, "Integration silo right now, should not block other silos or conflict"
[08:17] <ogra_> sil2100, image builds seems to still be broken
[08:17] <sil2100> ogra_: oh, slangasek mentioned it was fixed...
[08:17] <ogra_> well, he managed to publish the last two that were stuck
[08:17] <ogra_> but there are no new images
[08:18] <sil2100> Ah right, noticed that too, since I noticed we're still on 274 in utopic
[08:18] <ogra_> (neither utopic, nor rtm)
[08:18] <sil2100> But I actually thought it was because of my commitlog scripts b0rking
[08:19] <sil2100> Good to know
[08:19] <ogra_> 93 is the last rtm one
[08:19] <Mirv> nothing new in the morning :(
[08:19] <sil2100> ogra_: stgraber still on holidays?
[08:19] <ogra_> yes
[08:20] <davmor2> brendand: hmm there are 3 I just moved the other with the first 2 are those the ones you want me to take
[08:20] <ogra_> i see we have a fresh rootfs though
[08:20] <brendand> davmor2, no never mind about 15, that just came up
[08:21] <ogra_> heh
[08:21] <ogra_> running import-images manually for system-image at least spills aa new error now
[08:23] <ogra_> http://paste.ubuntu.com/8525648/
[08:23] <ogra_> this is what i get from import-images
[08:26] <ogra_> the code change slangasek did is tiny ... i suspect there are other bits that need to be ported to python3 https://code.launchpad.net/~vorlon/ubuntu-system-image/server-python3
[08:29] <ogra_> "heeey macarena !"
[08:34] <Saviq> ogra_, btw, is your MTP locked on connection if your lockscreen is protected?
[08:34] <ogra_> Saviq, havewnt tested that in a while, but that is how it should be
[08:34]  * Saviq is sometimes getting access to the files without unlocking
[08:35] <ogra_> it should only block on connect ... if you have it locked afterwards it shouldnt care
[08:41] <Saviq> ogra_, btw, can you access the SD card over MTP?
[08:41] <ogra_> yup
[08:42] <Saviq> ogra_, and have you had luck with any music management apps? banshee can't transfer music onto the phone for me
[08:42] <ogra_> oh, i never tried that
[08:42] <ogra_> i only copy via nautilus (if at all, my USB 3.0 SD card reader is way faster)
[08:43] <Saviq> ogra_, could you please record a video of the slowness you're seeing in the dash?
[08:43] <ogra_> Saviq, will try, i have some more pressing issues (we dont have images, builds dont work)
[08:43] <Saviq> ogra_, yeah, sure
[08:44] <ogra_> Saviq, and the constantly crashing dash is also worse than the slowness
[08:44] <Saviq> ogra_, can you check if that's not OOM killing the dash?
[08:46] <ogra_> Saviq, i'd expect it does, but yeah, i only noticed it last night and havent had time to check logs yet
[08:46] <Saviq> ogra_, so yeah, this is all about you having too much music on your device :P
[08:46] <Saviq> ogra_, when you have time, please file a bug with any details you think it's worth
[08:46] <ogra_> Saviq, we are just going through the (very few) smoke test results from last night and see scoperunner crashing a lot there too
[08:47] <ogra_> http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/93:20141008.2:20141008-8ea26ef/544/unity8/ for example
[08:47] <ogra_> (scroll down)
[08:47] <Saviq> ogra_, and this would be a bug against unity8 and unity-scope-mediascanner, as it should limit the number of results
[08:48] <brendand> Wellark, your silo will get looked at today - guess you already know about the Trello board?
[08:48] <Saviq> ogra_, there was a release of scopes api yesterday
[08:48] <Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-api
[08:49] <ogra_> Saviq, there also was unity-plugin-scopes yesterday morning
[08:49] <ogra_> (landed in image 90)
[08:49] <Saviq> ogra_, yeah, wouldn't cause scoperunner to crash, though
[08:49] <Saviq> or at least should not be able to
[08:49] <Saviq> if plugin-scopes crashed, unity8 would, not scoperunner
[08:49] <ogra_> what i see is a black screen saying "Scopes" when it restarts ...
[08:50] <ogra_> is that scope runner ?
[08:50] <brendand> hmm, so there might not be a general problem with holding calls
[08:50] <brendand> maybe it's this sim card
[08:50] <Saviq> ogra_, no, that's dash restarting
[08:50] <Saviq> ogra_, but what *you* see is different from what causes the smoketests problems
[08:54] <Wellark> brendand: what is Trello board?
[08:54] <ogra_> Wellark, read the spreadsheet ;)
[08:54] <ogra_> link is there at the top somewhere
[08:55] <brendand> Wellark, http://bit.ly/1qMAKYd
[08:55] <Wellark> what spreadsheet?
[08:55] <Wellark> I have so many
[08:55] <ogra_> Wellark, the one you put your landings on
[08:55] <Wellark> right.
[08:57] <Wellark> brendand: looks cool
[08:58] <Wellark> brendand: where is the RSS feed for the thing? :)
[08:59] <brendand> Wellark, click on the card > subscribe
[08:59] <brendand> Wellark, it will be by email
[09:22] <popey> ogra_: Yo! I hear you like music! http://people.canonical.com/~alan/music_remix/readme.txt - fancy testing out the new music app remix next time you listen to some. Would be very helpful to us.
[09:47] <ogra_> popey, oooh, cool !
[10:00] <ogra_> bah
[10:00] <ogra_> running import-images under pdb seems to just work :/
[10:01] <ogra_> (we should have 94 soon, but i still cant find the error)
[10:01] <cjwatson> ogra_: slangasek fixed it last night
[10:01] <ogra_> cjwatson, see my mail to ubuntu-phone ...
[10:02] <cjwatson> ok
[10:02] <ogra_> cjwatson, it worked for images that were alkready local ... but it doesnt pull any new ones anymore
[10:02] <ogra_> ARGH
[10:02] <sil2100> Yay, cjwatson to the rescue ;)
[10:02] <cjwatson> no
[10:02] <cjwatson> I'm busy :P
[10:02] <ogra_> and now i know why it works under pdb
[10:02] <ogra_> sigh
[10:02] <cjwatson> pdb3 would be better now that that script is running under python3
[10:02] <ogra_> cjwatson, exactly ...
[10:03] <ogra_> it works fine like that: python -m pdb /srv/system-image.ubuntu.com/bin/import-images
[10:03] <ogra_> with which i'm obviously pushin it back to py2
[10:03] <ogra_> only strikes me now :(
[10:03] <ogra_> but at least we'll get tonights image
[10:04] <ogra_> (if it actually finishes)
[10:05] <cjwatson> well it's possible that it will work with python 2 again now that it's processed the non-ASCII removed files
[10:06] <cjwatson> https://docs.python.org/3/whatsnew/3.0.html#ordering-comparisons explains this failure
[10:06] <cjwatson> I've reverted import-images to python2
[10:08] <cjwatson> so only to the rescue because I can do it with one character ;-)
[10:08] <ogra_> yeah
[10:09] <ogra_> i suspect there is likely even more porting needed before we can make that switch
[10:09] <cjwatson> probably not too much
[10:09] <cjwatson> I expect that slangasek ran the test suite; this is probably a corner case not covered by it
[10:10] <ogra_> hmm
[10:10] <cjwatson> specifically the case where 'base' not in image, around the area at the traceback in your paste
[10:10] <cjwatson> and in fact there must be multiple images some which contain 'base' and some which don't
[10:10] <ogra_> yeah, there are
[10:11] <cjwatson> I mean that that's a necessary condition for the failure
[10:12] <psivaa> Mirv: i ran music_app tests to reproduce the qmlscene crash and yet the mediascanner log is not present: http://pastebin.ubuntu.com/8526076/
[10:19] <cjwatson> I've filed https://bugs.launchpad.net/ubuntu-system-image/+bug/1379274 for the above
[10:21] <Mirv> psivaa: hmm :( can you ping Satoris and ask for ideas?
[10:21] <Mirv> he tends to not be on public irc however unfortunately
[10:24] <imgbot> [10:24] <imgbot> [10:25] <ogra_> ha !
[10:25] <davmor2> ogra_: you fixored it
[10:25] <ogra_> davmor2, nope
[10:25] <ogra_> i just ran it with the wrong debugger :)
[10:26] <brendand> ogra_, isn't it better just to do 'import pdb; pdb.set_trace()'?
[10:26] <ogra_> brendand, that means i need to do code changes
[10:27] <brendand> ogra_, ah you're touching the live system?
[10:27] <ogra_> brendand, right ... i was trying to get proper debug output from the broken live system
[10:27] <ogra_> but clever as i am i didnt run the py3 version :P
[10:29] <sil2100> \o/
[10:29] <sil2100> ogra_: so, you think it will work from now on?
[10:29] <sil2100> Since cjwatson re-enabled python2 again
[10:30] <ogra_> sil2100, with cjwatson's "fix" it will work until any file with non-ascii name gets removed from the image
[10:30] <ogra_> then we'd run into the same issue as yesterday
[10:30] <cjwatson> which is why I filed a bug
[10:30] <ogra_> right
[10:34] <ogra_> sil2100, FYI http://people.canonical.com/~ogra/touch-image-stats/rtm/94.changes
[10:35] <ogra_> (since the bot got cunfused by starting and failing images)
[10:35] <sil2100> ogra_: thanks!
[10:38] <ogra_> Saviq, so with 94 the scopes seem to behave a bit better ... i only see the delay between swipe and action when i *leave* the music scope, not in the other scopes anymore (before it was all scopes that seemsd to have a delay between gesture and actual action)
[10:40] <ogra_> my browser is still broken though :/
[10:41] <Saviq> ogra_, glad to hear, we still need to have a look at improving this of course
[10:41] <ogra_> Saviq, yeah, but it isnt as bad anymore
[10:42] <ogra_> i cant really belive i'm the only one with the keyboard being stuck in landscape when trying to enter something in the browser url bar
[10:43] <Saviq> ogra_, FWIW there wasn't a unity8 release in that image was there?
[10:43] <ogra_> Saviq, nope, click scope though
[10:43] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/rtm/94.changes
[10:43] <ogra_> and UAL
[10:44] <Saviq> ogra_, hmm, let us know if the slowness comes back, no scope alone should've caused that...
[10:44] <ogra_> ok
[10:44] <ogra_> might be that due to the crashyness apport ran in bg ... which would have made it additionally slow
[10:45] <Saviq> well, that's assuming it was actually crashing?
[10:46] <ogra_> well, it was restarting :)
[10:46] <ogra_> (black screen with "scopes" on it and then an empty apps scope that slowly filled over time)
[11:14] <Mirv> sil2100: have you ever thought about raising the amount of utopic silo to 35...
[11:14] <sil2100> Mirv: ...;p
[11:15] <Mirv> bzoltan: is the 1.10. uitk landing going to land in utopic? it's built, not tested, and you have the next landing for rtm already.
[11:17] <Mirv> ^  no they are not yet...
[11:17] <Mirv> wtf
[11:17] <Mirv> sil2100: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-017-2-publish/9/console
[11:18] <Mirv> I'm trying to publish it, yes, but to my understanding it did not
[11:18] <sil2100> Mirv: I ran it already :)
[11:18] <Mirv> ...
[11:18] <Mirv> sil2100: ah! :)
[11:18] <sil2100> Mirv: that's why it errors out!
[11:18] <Mirv> sil2100: it did not error out, it succeeded with an error :)
[11:19] <sil2100> I think it would be anyway better if we fix the messaging in this case ;)
[11:19] <sil2100> Since CI Train right now doesn't really handle pressing publish twice, it should basically say: "already publishing" or something
[11:20] <Mirv> yep
[11:20] <Mirv> so many issues on the spreadsheet again
[11:21] <Mirv> I mean, lines that have something amiss
[11:22] <Mirv> tvoss: is "Land Network Manager WiFi timestamp/scan results fix from tvoss to rtm" line irrelevant nowadays, for rtm? I've asked on 20140925 about the line and no answer, but just double checking.
[11:23] <tvoss> Mirv, I will take a look in a few
[11:23] <Mirv> tvoss: the latest network-manager upload in rtm is from Sep 30 https://lists.canonical.com/archives/rtm-14.09-changes/2014-September/000549.html
[11:23] <Mirv> tvoss: ok, thanks. line 15. I'd just like to remove the line if it's not relevant anymore
[11:24] <tvoss> Mirv, sure, let me double check after I kicked a test
[11:26] <ogra_> Saviq, tvoss, so my unity8-dash is crashing simply because it isnt excuded from app lifecycle mgmt at all http://paste.ubuntu.com/8526308/ ... (see the oom_score_adj value of 802 here)
[11:27] <Saviq> ogra_, s/crashing/being killed/
[11:27] <ogra_> well
[11:27] <ogra_> the user experience is the same :)
[11:27] <tvoss> ogra_, file a bug against unity8
[11:27] <ogra_> tvoss, will do
[11:28] <Saviq> ogra_, and well, I'm not sure that's totally wrong, if your foreground app uses all the memory, shouldn't the dash be killed?
[11:28] <Saviq> ogra_, granted, it should only resume after you focus it again
[11:28] <ogra_> Saviq, everything but the dash imho
[11:28] <ogra_> i have like 20 apps open, not all of them have been killed if the dash dies
[11:29] <ogra_> it should definitely always stay at a lower value than normal apps
[11:29] <Saviq> yeah that I agree with, between normal apps and foreground app
[11:29] <ogra_> so that ... *if* killed at all, it should be the last thing
[11:29] <Saviq> ogra_, and yeah, we need to reduce mem usage in a case like yours
[11:29] <Saviq> ogra_, unity8 and qtmir please
[11:29] <ogra_> oki
[11:31] <Saviq> sil2100, hmm https://ci-train.ubuntu.com/job/ubuntu-landing-019-0-reconfigure/15/console says "Removing unity-notifications from silo.", but then https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/69/console :|
[11:33] <Mirv> ted: landing-017 for your utopic misc fixes. I've force Merge & Clean for indicator-sound (001) so that the trunk is up-to-date, but please follow manually if release team has something against it or will allow it to pass before trying to publish this new silo.
[11:35] <Saviq> trainguards, can you please drop unity-notifications from utopic silo 19, reconfiguration doesn't seem to have done it, even though it said it did
[11:35] <Mirv> Saviq: grudgingly doing so. grumpiness related to CI train.
[11:36] <ogra_> Saviq, tvoss bug 1379296
[11:36] <Mirv> sil2100: better to ask though - I guess we don't have any "prepare" link anywhere, so for real reconfigs one needs to fill in all the fields in prepare-silo job manually? or are some of them optional? nowadays one has fields for lander, MP:s, additional source packages... not just the request id etc
[11:37] <oSoMoN> trainguards: can you please publish RTM silo 17 ?
[11:37] <Mirv> oSoMoN: already done, sorry, I'll m&c it manually in a minute
[11:37] <Mirv> my mistake
[11:38] <Mirv> dbarth: your "webapps fixes" line lacks target distro
[11:38] <Mirv> tvoss: same for your "Fix #1373281 & #1367244"
[11:39] <oSoMoN> Mirv, awesome, thanks
[11:40] <Saviq> Mirv, hmm still there https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+packages ?
[11:40] <Saviq> Mirv, or did you not remove it yet?
[11:41] <Mirv> Saviq: not yet, I was first waiting for sil2100 to answer my question, then handling other train stuff and now doing it the manual route
[11:42] <Saviq> Mirv, ok sorry for pushing :)
[11:43] <Mirv> Saviq: now done :)
[11:43] <Saviq> Mirv, thank youse
[11:45] <sil2100> Mirv: what I do usually is go to the spreadsheet and do the 'Assign silo' button again
[11:45] <sil2100> Mirv: it worked so far
[11:46] <sil2100> Mirv: so you go to the row of interest, click as if you assign a silo but just do a reconfigure instead
[11:47] <Mirv> sil2100: there's no option to reconfig there
[11:47] <Mirv> sil2100: oh, correction
[11:47] <Mirv> it's a "reconfigure" dialog
[11:47] <Mirv> and then it calls prepare-silo!
[11:47] <Mirv> oh joy!
[11:48] <Mirv> sil2100: thanks!!
[11:48] <Mirv> oSoMoN: considering webbrowser-app landed from the 017 as a sync from utopic, is line 36 and its assigned 019 silo a thing of the past?
[11:49] <sil2100> Yeah :)
[11:49] <sil2100> yw!
[11:49]  * sil2100 goes prepare lunch
[11:50] <Mirv> oSoMoN: and to answer to myself, I believe it's still needed as much has happened since 1006 release :) https://code.launchpad.net/~phablet-team/webbrowser-app/trunk
[11:50] <oSoMoN> Mirv, yes indeed, I think it’s still needed
[11:54]  * Mirv is momentarily satisfied with the spreadsheet
[12:02] <Wellark> Mirv: sync silo for line 78 please :)
[12:07] <Mirv> Wellark: done, but can't allocate rtm silo yet since the previous landing is still ongoing
[12:07] <Mirv> or well, that's a sync silo too so I guess I could (trunk already updated)
[12:11] <Wellark> Mirv: <3
[12:18] <Wellark> Mirv: any idea what this is: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-006-1-build/27/console ?
[12:19] <Wellark> Mirv: and why is this failing: https://ci-train.ubuntu.com/job/ubuntu-landing-020-1-build/61/console
[12:20] <sil2100> Wellark: the ubuntu-rtm is a known thing - did you re-sync just now for the second time?
[12:20] <Wellark> sil2100: haven't touched it
[12:20] <Wellark> just tried to rebuild
[12:21] <Wellark> and the utopic silo fails to build arm64 package because:
[12:21] <Wellark> dpkg-buildpackage: host architecture arm64
[12:21] <Wellark> dpkg-checkbuilddeps: Unmet build dependencies: gdb:any
[12:21] <Wellark> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
[12:21] <Wellark> dpkg-buildpackage: warning: (Use -d flag to override.)
[12:21] <sil2100> Ah, ok, so don't worry with the ubuntu-rtm error... once the binary copy gets published this will go away
[12:21] <sil2100> Not sure about the ubuntu one, didn't look yet
[12:21] <Wellark> ack.
[12:22] <sil2100> hmmm
[12:23] <sil2100> The ubuntu one looks like a toolchain issue
[12:23] <Wellark> yep
[12:23] <Wellark> or somebody deteled gdb
[12:24] <Laney> should be fixed now
[12:24] <Laney> ah, still in proposed
[12:25] <Laney> should be fixed *soon* :)
[12:25] <sil2100> The PPA builds with proposed so we should be good ;)
[12:29] <Wellark> sil2100: can I trigger a rebuild on arm64 on the ppa straight or must I go through silo dashboard and rebuild on all architectures?
[12:33] <sil2100> Wellark: we need to do it from the PPA
[12:33] <sil2100> Wellark: we have the power, so let me do that
[12:33] <Laney> wait
[12:33] <Laney> It's not finished building on arm64 yet
[12:33] <ogra_> see #ubuntu-touch
[12:33] <ogra_> :)
[12:33] <Laney> You need rmadison -s utopic-proposed -a arm64 gdb to show you ubuntu4
[12:35] <sil2100> Ah! Ok, I thought that it's build in proposed already
[12:35] <sil2100> k
[12:36] <sil2100> Wellark: silo 20 will still fail, but I'll re-build it again once it's finished ^
[12:37] <cjwatson> yeah, requires Adam to manually kill test processes to let the build complete :-/
[12:37] <cjwatson> waiting for him to show up
[12:38] <cjwatson> Wellark: going through the dashboard will just waste a load of build time on all architectures and not fix this anyway, so don't do that
[12:46] <Wellark> cjwatson: ack. that's why I asked :)
[12:56] <sergiusens> sil2100: I need to reconfig ubuntu-rtm&q=landing-008 (I know it has conflicts with other silos, so will rebuild/reconfigure once it's all good and lined up and lockable)
[12:59] <sil2100> sergiusens: ok, doing
[12:59] <sergiusens> sil2100: iirc, the only conflict is the webbrowser
[13:01] <sil2100> It's reconfiguring, let's see how it goes
[13:01] <sil2100> Yeah, webbrowser is the only one, but I ignored conflicts
[13:06] <alecu> trainguards, ping about ubuntu/landing-030
[13:08] <sil2100> alecu: oh! Looking
[13:08] <alecu> trainguards: I jumbled a bit with ubuntu/landing-030, and got that error message, but I tested packages in the ppa and they seem to be the right version, so I think the sync worked after all
[13:09] <sil2100> alecu: yeah, it's a specific citrain issue... usually when you see this just wait some time and re-run, it'll fix itself
[13:09] <alecu> sil2100: also, I followed the test plan, and it passed ok, so I wonder what needs to be done to land it.
[13:09] <sil2100> Let me re-run
[13:09] <sil2100> alecu: ok, the packages are correct, I just need to do a watch_only build now
[13:09] <alecu> great
[13:09] <sil2100> So, it's on my radar, but due to the lack of time it's actually pushed back...
[13:10] <alecu> sil2100: no hurries, thanks!
[13:12] <alecu> yay
[13:17] <sil2100> \o/
[13:41] <sil2100> psivaa: we have full results from smoketesting, right?
[13:44] <lool> thanks for putting https://wiki.ubuntu.com/citrain/LandingProcess together
[13:44] <lool> it would be nice to link it from http://people.canonical.com/~platform/citrain_dashboard/
[13:45] <lool> so that I can find it again  :-)
[13:47] <sil2100> lool: yw! I'll try adding that later today :) There are still things that I need to put inside there though
[13:47] <sil2100> brendand was the person doing the QA sign-off part
[13:48] <camako> sil2100, is everything ok with the rtm silo 20 migration?
[13:48] <ogra_> sil2100, 93 looks pretty complete to me
[13:49] <ogra_> hmm, i thought filemanager was fixed
[13:49] <ogra_> and calculator lately has issues it didnt have in the last images
[13:49] <ogra_> (in rtm)
[13:50] <ogra_> music and gallery too :(
[13:50] <kgunn> cjwatson: rtm silo20 was released by qa y'day ~ 5pm my time...~16hrs ago....but dash board showing it's still in migration
[13:50] <ogra_> looks liek something migrated that broke them (i know we had this in utopic but never in rtm)
[13:50] <kgunn> any thots ?
[13:58] <sil2100> camako: let me take a look
[13:59] <kgunn> sil2100: thanks...it's been like 16hrs
[14:01] <camako> sil2100, also during sync of rtm silo 20 to utopic silo 8, unsupported architectures make the build fail, but packages for supported apps are in the ppa, so it's ok to ignore this error, I think? Just thought I'd report it as a good samaritan..
[14:01] <thostr_> davmor2: just wanted to verify that rtm silo 18 is indeed next on your sign-off list?
[14:02] <camako> sil2100, s/supported apps/supported arches
[14:02] <cjwatson> kgunn: seems to make ubuntu-touch uninstallable
[14:02] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/update_output.txt
[14:02] <cjwatson> (just the bit at the end)
[14:02] <davmor2> thostr_: yeap whatever is at the top is always next
[14:03] <sil2100> cjwatson: but it actually tries installing qtmir and qtmir-gles at once, while qtmir-gles I guess is not touch specific, right?
[14:03] <cjwatson> sil2100: no that's not quite what that means
[14:03] <cjwatson> it's effectively test-upgrading the archive and checking for resulting new uninstallable packages
[14:03] <cjwatson> it does not mean it's trying to coinstall all binaries from all the listed sources
[14:04] <thostr_> davmor2: thanks
[14:04] <sil2100> Ah, ok
[14:04] <cjwatson> not yet quite sure what the problem is though
[14:05] <cjwatson> probably NBS somewhere
[14:05] <kgunn> NBS ?
[14:05] <davmor2> thostr_: when that will be is another matter altogether but it will be next ;)
[14:06] <camako> cjwatson, there was a similar problem during QA testing... where ci-train-upgrade didn't work because it pulled in only mesa libs
[14:06] <cjwatson> not built from source
[14:06] <cjwatson> ubuntu-touch depends: libmirclientplatform-android, libmirplatformgraphics-android
[14:06] <cjwatson> neither of which is in the new version of mir
[14:06] <camako> cjwatson, yes that...
[14:07] <cjwatson> has this change also landed in utopic?
[14:07] <camako> cjwatson, but it worked when the relevant packages were installed
[14:07] <camako> cjwatson, no
[14:07] <kgunn> landing in reverse
[14:07] <cjwatson> camako: yes because nothing forces the old binaries out, but proposed-migration checks for this
[14:07] <cjwatson> it would be a lot easier to get this into utopic and then we can update ubuntu-touch-meta in the usual way
[14:08] <kgunn> so i wonder, is landing in reverse just not a good method for core components ?
[14:08] <camako> cjwatson, it's in silo 8 for utopic..
[14:08] <cjwatson> kgunn: depends on the changes
[14:08] <cjwatson> if we have to do it this way round then I'm going to have to temporarily branch ubuntu-touch-meta in rtm
[14:09] <camako> cjwatson, so can we hold this off, and finish testing the sync silo 8 on utopic first, and then rtm? testing on silo 8 is abt done.
[14:09] <cjwatson> sure
[14:10] <cjwatson> kgunn: major package restructurings are going to be a little problematic that way round
[14:10] <camako> cjwatson, rtm testing is done already (using the apt-get install method, not train-upgrade).
[14:10] <cjwatson> ok I don't need to know :)
[14:10] <cjwatson> I think you have what you need now?
[14:10] <camako> ok I'm not saying :-)
[14:11] <camako> cjwatson, yep
[14:11] <cjwatson> somebody will just have to bump the ubuntu-touch seeds once this is landed in utopic
[14:11] <cjwatson> and upload ubuntu-touch-meta
[14:11] <camako> sil2100 ^^
[14:11] <cjwatson> then we binary-copy ubuntu-touch-meta to rtm
[14:11] <cjwatson> (once it's built)
[14:13] <sil2100> camako, cjwatson: ok, thanks! So, let's get it tested for utopic and ready to release
[14:13] <sil2100> Then we can ask for instance ogra_ to update the seed
[14:14] <camako> sil2100, sounds good
[14:14] <ogra_> jdstrand, i see a lot of apparmor denials in image 93 ... for gallery and calculator tests
[14:15] <ogra_> jdstrand, http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/313/artifact/clientlogs/ubuntu_calculator_app/syslog/*view*/ and http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/311/artifact/clientlogs/gallery_app/syslog/*view*/
[14:16] <ogra_> and music suddenly cant read its gsettings schemas anymore (it could in 88 )
[14:17] <ogra_> ted, did you test your XDG changes with rtm under pahblet-test-run ?
[14:17] <ogra_> 88+ has a lot of new errors we never had before ... partially gsettings related
[14:18] <ted> ogra_, No, I didn't test with phablet-test-run, I used adb shell.
[14:18] <ogra_> you should have used phablet-test-run
[14:18] <ted> ogra_, Is that before or after the xdg changes landed?
[14:18] <ogra_> which is what we use in testing everywhere
[14:19]  * alecu merges and cleans
[14:19] <ogra_> ted, http://people.canonical.com/~ogra/touch-image-stats/rtm/89.changes ... 88 was all fine ...
[14:19] <ogra_> since 89 we have issues it seems
[14:19] <psivaa> sil2100: ugh, with rtm 94 both devices had flashing issues, i'm running it again
[14:20] <ogra_> ted, though i dont think it is the XDG change but rather UAL (which landed in the same image)
[14:21] <ted> ogra_, Yes, I think UAL caused it. But that image doesn't have the XDG fix.
[14:21] <ted> ogra_, That's in the next touch-session update
[14:21] <ted> ogra_, https://code.launchpad.net/~phablet-team/ubuntu-touch-session/trunk
[14:21] <ted> ogra_, Not until 1007
[14:21] <ogra_> ted, there is no "next" one in rtm
[14:21] <ogra_> ted, note that phablet-test-run (or any other non interactive tool) will not treat adb shell as login shell
[14:22] <bzoltan1> davmor2:  I see you have started to validate the uitk. Is there anything I can help you?
[14:22] <ted> ogra_, Wait, I'm confused. So which revision of ubuntu-touch-session do you think rtm89 has?
[14:22] <ogra_> your "fix" will only affect any interactiver shells anyway
[14:23] <ogra_> which we use nowhere
[14:23] <ogra_> 0.108+14.10.20141006.1-0ubuntu1 ...
[14:23] <ogra_> oh, indeed, that doesnt have yur hack
[14:24] <sergiusens> sil2100: can I get a new reconfig for rtm silo 8?
[14:24] <ted> The hack fixed the utopic results.
[14:24] <sil2100> sergiusens: ACK
[14:24] <sergiusens> ty
[14:24] <davmor2> bzoltan: no thanks bud, I'm marching through it
[14:24] <ogra_> ted, http://ci.ubuntu.com/smokeng/utopic/touch/mako/274:20141008.1:20140929.1/10857/
[14:24] <ogra_> ted, doesnt look like it did (would also be surpising ... since as i said, you only change interactive shell behavior)
[14:25] <ted> ogra_, http://ci.ubuntu.com/smokeng/utopic/touch/mako/273:20141008:20140929.1/10844/ubuntu_clock_app/
[14:25] <ogra_> ted, see gallery and calculator
[14:25] <ted> ogra_, Clock app went from 50% to 100%
[14:26] <sil2100> sergiusens: ok, indicator-transfer is already allocated by silo 21 as well - I reconfigured, but please make sure it's coordinated
[14:26] <ogra_> ted, hmm, so that was a clock only fix ?
[14:27] <ted> ogra_, I don't think so, but looking at the 274 gallery results
[14:27] <ted> ogra_, Where do you see the gsettings failure there?
[14:27] <ogra_> yeah, gallery is probably a bad example as it has apparmor issues
[14:27] <ogra_> calculator has the gsettings messages in its log
[14:28] <ogra_> http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/313/artifact/clientlogs/ubuntu_calculator_app/application-click-com.ubuntu.calculator_calculator_1.3.329.log/*view*/
[14:29] <ogra_> gallery http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/311/artifact/clientlogs/gallery_app/application-click-com.ubuntu.gallery_gallery_<IP_ADDRESS>4.log/*view*/ has only a few gsettings messages
[14:29] <ted> ogra_, Those are dconf not being able to read the file, that's not the same.
[14:29] <ted> ogra_, The clock one was segfaulting
[14:29] <ogra_> (but ignore that we should get apparmor fixed there first)
[14:29] <ogra_> ok
[14:29] <ted> I'm pretty sure we don't want apps reading that file.
[14:29] <ogra_> ted, i'm just worried because we didnt have any issues with either app before image 89
[14:29] <ogra_> (in RTM that is)
[14:30] <jdstrand> ogra_: the fakeenv policy needs to be updated for the calculator
[14:30] <ogra_> jdstrand, ah
[14:30] <ogra_> jdstrand, what about gallery ?
[14:30] <jdstrand> balloons: ^
[14:31] <jdstrand> balloons: representative denial: apparmor="DENIED" operation="mkdir" profile="com.ubuntu.calculator_calculator_1.3.329" name="/home/phablet/autopilot/fakeenv/tmpqn1fqd0e/.cache/QML/" pid=NNN comm="qmlscene" requested_mask="c" denied_mask="c" fsuid=32011 ouid=32011
[14:31] <ogra_> oooh
[14:31] <ogra_> i didnt notice the path
[14:31] <ogra_> thats ricmm land :)
[14:31] <ted> ogra_, I agree, I think the UAL landing broke them. And I think the ubuntu-touch-session fixes them. Which is why I was so hot to get it in :-)
[14:32] <jdstrand> ogra_: leaf-net is 1378805. networkmanager is 1376408
[14:32] <jdstrand> ogra_: /usr/bbc/ is wrong :)
[14:32] <balloons> jdstrand, hmm.. it's inside fakeenv, why the sudden denial?
[14:33] <jdstrand> balloons: I'd have to look at the policy again, but .cache/QML/ is a new path for the precompiled qml work from ricmm
[14:33] <jdstrand> balloons: can you point me at the policy and I can give you a rule to add?
[14:33] <ogra_> ted, so land it already 11!!
[14:33] <ogra_> :)
[14:34] <ogra_> (i still doubt .profile helps with non.interactive shells though, but happy to be proven wrong)
[14:34] <jdstrand> ogra_: yelp is 1376416
[14:35] <jdstrand> ogra_: /home/phablet/.local/share/applications/ is 1378817
[14:35] <ogra_> lol
[14:35] <ogra_> you know your bug list very well it seems :)
[14:35] <jdstrand> ogra_: /usr/share/applications/ is also 1378817
[14:35] <jdstrand> indeed
[14:36] <jdstrand> I am getting daily pings
[14:36] <ogra_> heh. sorry
[14:36] <jdstrand> no worries
[14:36] <jdstrand> the QML one is legit-- needs to be fixed
[14:36] <ogra_> yeah
[14:36] <ogra_> just an oversight
[14:36] <jdstrand> well, they all need to be fixed, but the QML one is new :)
[14:36] <balloons> jdstrand, ahh.. Well, the policy stuff is all in aa-click. Perhaps it's solvable by us creating the dir and not changing the policy
[14:37] <jdstrand> it isn't in click-apparmor, I remember it is in autopilot
[14:37] <jdstrand> let me look at it
[14:38] <balloons> yep, you are correct. We do create quite a nest of directories during the test setup as well
[14:38] <ogra_> jdstrand, now the million dollar question ... if apparmor doesnt allow my app to write to that precompiled QML dir ... why is it actually working in real life ?
[14:38] <jdstrand> balloons: ok, so, yes, you need to create the directory, but /usr/share/autopilot-touch/apparmor/click.rules needs this rule:
[14:39] <ogra_> i would expect AA also blocks in real usage too ?
[14:39] <jdstrand> no, I fixed that already
[14:39] <ogra_> if we dont have the dir
[14:39] <ogra_> ah !
[14:39] <jdstrand> oh, yes
[14:39] <ogra_> k
[14:39] <jdstrand> apps can't create that dir
[14:39] <jdstrand> but, they can create their application-specific dir under it
[14:40] <ogra_> yeah
[14:40] <jdstrand> someone should make sure that dir exists
[14:40] <jdstrand> otherwise we will have reports where it sometimes works and sometimes doesn't
[14:41] <ogra_> well, something creates it
[14:41] <ogra_> i know i didnt create it manually
[14:41] <jdstrand> (eg, launch messaging app first (unconfined), all is ok. launch weather app first (confined), it won't work right)
[14:41] <ogra_> ricmm, what creates the ~/.cache/QML dir ?
[14:41] <jdstrand> I'm making some assumptions here that it isn't happening
[14:42] <jdstrand> happening outside of the app that is
[14:42]  * ogra_ thought thats UAL
[14:42] <jdstrand> if UAL is doing it, then shouldn't be an issue
[14:42] <jdstrand> just so long as the app isn't doing it
[14:44] <jdstrand> balloons: so, the dir to create is @{HOME}/autopilot/fakeenv/*/.cache/QML/Apps/
[14:44] <jdstrand> balloons: and the rule to add to autopilot rules is:
[14:44] <jdstrand> owner @{HOME}/autopilot/fakeenv/*/.cache/QML/Apps/@{APP_PKGNAME}_@{APP_APPNAME}_@{APP_VERSION}/** mrwkl,
[14:45] <jdstrand> balloons: once both of those is done, the calculator should start working again
[14:45] <jdstrand> s/working/passing/
[14:48] <john-mcaleely> is it possible to know where ubuntu/landing-003 is in the queue for signoff/landing in image?
[14:49] <john-mcaleely> I need to do a device tarball update after it...
[14:49] <john-mcaleely> cihelp ^
[14:50] <sil2100> john-mcaleely: ubuntu landing 003?
[14:50] <sil2100> john-mcaleely: it didn't get tested by the lander yet
[14:50] <Ursinha> john-mcaleely: that is a question for trainguards, but I'd guess QA signoff dashboard
[14:51] <john-mcaleely> sil2100, aha, ok
[14:51] <john-mcaleely> Ursinha, thanks! will cruise those links
[14:52] <barry> john-mcaleely: the dashboard is your friend: http://people.canonical.com/~platform/citrain_dashboard//#?distro=ubuntu&q=
[14:52] <Ursinha> john-mcaleely: no problem :)
[14:52] <john-mcaleely> barry, thank you. looking now.
[15:02] <balloons> jdstrand, thank you. I'll make those tweaks
[15:10] <Mirv> Saviq: not approved https://code.launchpad.net/~aacid/unity8/noDashContentScale/+merge/237626
[15:10] <Saviq> Mirv, oups, sorries
[15:12] <Saviq> Mirv, done
[15:12] <dbarth> hey, i have a dependency problem in a silo
[15:12] <dbarth>  ubuntu-system-settings-online-accounts : Depends: libmirclient8 (>= 0.8.0+14.10.20141005) but 0.7.3+14.10.20140918.1-0ubuntu1 is to be installed
[15:13] <dbarth> it's an rtm silo
[15:13] <dbarth> does that sound normal?
[15:13] <dbarth> the same silo build yesterday was installing ok
[15:13] <Saviq> dbarth, there's an issue with Mir landing from rtm silo 20
[15:13] <Saviq> dbarth, i.e. things are stuck in propose
[15:13] <Saviq> d
[15:14] <dbarth> Saviq: ah, but so i can take silo 20 on top, and that should work
[15:14] <dbarth> Saviq: thanks; i will try
[15:15] <Saviq> dbarth, yeah
[15:19] <jdstrand> ogra_: oh, music-app and gsettings. apps are not allowed to use gsettings (they never have). I added some explicit denies for dconf to the ubuntu-sdk template, but that doesn't change anything: a) they were denied before and b) music-app uses the unconfined template (which can use gsettings, but shouldn't if it is ever going to be confined)
[15:19] <brendand> oSoMoN, your webbrowser-app silo is 4th in our queue. it should get tested later today or early tomorrow. see the trello board for status: https://trello.com/b/AE3swczu
[15:20] <ogra_> jdstrand, hmm
[15:20] <jdstrand> ie, it shouldn't have anything to do with apparmor
[15:20] <oSoMoN> brendand, thanks for the update, I’ll be watching the trello board
[15:45] <Mirv> yeah EOD is overrated
[15:47] <bfiller> Mirv: just had a problem with a silo landing on rtm, and then ubuntu but it never merged the changes to trunk
[15:47] <bfiller> Mirv: any ideas why?
[15:47] <bfiller> was silo 21 on ubuntu and was silo 3 earlier today on rtm
[15:47] <bfiller> telepathy-ofono never got merged back to trunk
[15:48] <bfiller> Mirv, sil2100: ouch, none of the MR's on those silos got merged back
[15:49] <jfunk> psivaa: hey :) I think asac was asking you to help jibel & rhuddie with test plans on the promoted images, not with silo testing, asac correct me if I am wrong
[15:49] <jfunk> brendand: ^
[15:50] <Mirv> bfiller: sil2100: I'm not sure what happened here https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-3-merge-clean/25/console
[15:50] <bfiller> sil2100, Mirv: line 15 and 16 on the sheet
[15:50] <ogra_> Mirv, whats that EOD thing ? "exhaust or die" ?
[15:51] <Mirv> bfiller: sil2100: oh, that one only was content-hub silo, are you sure the rtm was 003?
[15:51] <bfiller> Mirv: trying to remember the silo..
[15:51] <Mirv> bfiller: sil2100: ok, this was the problematic m&c https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-3-merge-clean/24/console
[15:51] <Mirv> ogra_: something like that
[15:53] <bfiller> Mirv: hmn, how can we fix? we did a rebuild after rsalveti landed another version of telepathy-ofono should that should have been ok
[15:53] <brendand> ogra_, EOD is what you call 'going to sleep'
[15:53] <Mirv> bfiller: by merging manually form https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-2-publish/25/console
[15:53] <rsalveti> bfiller: it seems for some reason we got a version clash on tp-ofono
[15:53] <Mirv> bfiller: telephony-service should be fixed
[15:54] <ogra_> brendand, oh, you mean FhK !
[15:54] <sil2100> huh
[15:54] <ogra_> (Forehead hits Keyboard)
[15:54] <rsalveti> bfiller: Mirv: should I just merge tp-ofono by hand?
[15:55] <rsalveti> let me get some food first
[15:55] <Mirv> rsalveti: bfiller telepathy-ofono also now merged manually, but please check the result
[15:55] <sil2100> I wonder why CI Train was unable to auto-merge that
[15:56] <brendand> ogra_, mind your language
[15:56] <ogra_> lol
[15:57] <Mirv> sil2100: could it be changed it wouldn't be "success" m&c if there's an error?
[15:57] <sil2100> I guess this might be some problem caused by Robert's refactoring, since I'm pretty sure in the past it wasn't succeeding
[15:58] <Mirv> sil2100: I worry if we have missed other similar cases
[15:59] <Mirv> bfiller: messaging-app, history-service and dialer-app also now pushed
[15:59] <sil2100> Mirv: thanks for doing it manually!
[15:59] <bfiller> Mirv: thank you!
[16:01] <bfiller> Mirv: is ok that the rev that got merged shows only 1 merged branch even though there were multiple branches that were merged? the diff looks correct.. see https://code.launchpad.net/~phablet-team/messaging-app/trunk latest rev
[16:02] <Mirv> bfiller: it's the ci train's combined branch, which is always pushed when publishing: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-2-publish/25/console - so it _should_ be ok
[16:02] <bfiller> ok
[16:02]  * sil2100 will look to fix the 'succeeding' problem
[16:02] <Mirv> bfiller: that's funny thought that it marks it like that while in reality I merged that ~ps-jenkins branch
[16:03] <Mirv> but it's probably a LP limitation when making such a manual merge
[16:22] <psivaa> jfunk: i'll double check about that
[16:40] <davmor2> popey, brendand, ogra_, sil2100: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1379296 steps added can you all confirm
[16:41] <davmor2> Saviq: ^ it's all your fault ;)  should be easily reproducible now too hopefully
[16:41] <ogra_> confirmed
[16:42] <ogra_> (well, not in the bug status since it is already trigaed)
[16:42] <Saviq> davmor2, but it scrolls faster now!
[16:42] <ogra_> haha
[16:43] <davmor2> Saviq: but oom score kills dash possibly the last thing that should ever die ;)
[16:43] <Saviq> davmor2, no, the shell is the last thing that should ever die ;P
[16:43] <davmor2> Saviq: apps open quicker too
[16:43] <Saviq> and the foreground app should die after dash
[16:44] <davmor2> Saviq: technically upstart is the last thing that should ever die :P
[16:44] <Saviq> davmor2, Debian disagrees :P
[16:45] <davmor2> Saviq: hahaha
[16:46] <davmor2> Saviq: there are at least nice reproducible steps now :)
[16:51] <popey> ogra_: https://bugs.launchpad.net/five-letters :D
[16:52] <dbarth> Saviq: did the mir situation improve btw? installing silo 20 didn't work so well on my krillin
[16:56] <camako> sil2100, testing is done successfully... please publish utopic silo 8, then rtm silo 20..
[16:57] <camako> cjwatson ^^
[16:57] <sil2100> camako: hmm
[16:58] <sil2100> camako: did you notice that the arm64 builds failed for mir?
[16:58] <camako> sil2100, that's an unsupported platform..
[16:58] <camako> sil2100, I think it's a sync bug
[16:59] <sil2100> It was supported earlier I think, since the utopic archive has arm64 binaries of it
[16:59] <dbarth> line 82 actually
[16:59] <sil2100> Let me rebuild the package in the PPA, it seems to be an unit test failure
[17:01] <camako> sil2100, I only see amd64, armhf, and i386 on the RTM silo for mir
[17:01] <sil2100> camako: yeah, but I'm talking about utopic
[17:01] <sil2100> camako: silo 008 ;)
[17:01] <sil2100> camako: utopic has arm64 and we need to make sure that all platforms are buildable that were buildable before
[17:01] <camako> sil2100, do we build a different set of archs in utopic vs rtm?
[17:02] <sil2100> camako: yeah, RTM has less architectures
[17:02] <camako> sil2100, gotcha
[17:02] <sil2100> Otherwise it would get blocked in proposed
[17:03] <camako> sil2100, ok I see, the unit test failure is a known intermittent failure that we have a bug for..
[17:04] <barry> dbarth: please confirm the dupes: https://ci-train.ubuntu.com/job/prepare-silo/2683/console
[17:04] <sil2100> Ok, so a rebuild of the arch might help then :)
[17:04] <psivaa> jfunk: so that's test plan work with jibel
[17:04] <camako> yea I'm hoping
[17:05] <bzoltan2> ogra_: rsalveti: That phablet-tools and SDK PPA issue could be easily solved. Just ping me when you release an update for Trusty in the phablet-tools PPA and I will take that package into my testing/releasing queue.
[17:05] <jfunk> psivaa: yes, that's what I siscussed with asac
[17:05] <psivaa> jfunk: ack
[17:06] <bzoltan2> ogra_: rsalveti: The automatic/brainless regular copy would be only viable if all package in that PPA would be released after testing them with the SDK.
[17:07] <dbarth> trainguards: o/ can i get that silo on line 82 please?
[17:08] <sil2100> dbarth: I think barry was handling that ^
[17:08] <sil2100> dbarth: I think he wanted to confirm from you something
[17:08] <barry> dbarth: you need to confirm that the collisions with the other silo are okay
[17:08] <barry> dbarth: https://ci-train.ubuntu.com/job/prepare-silo/2683/console
[17:09] <asac> jfunk: psivaa: jibel: plars: can we arrange a briefing call on the testing?
[17:09] <barry> dbarth: otherwise you could overwrite the changes in that other silo
[17:09] <asac> i think everyone who is in that testing effort should be there
[17:09] <asac> so details how things are arranged, managed etc. are clear
[17:09] <psivaa> asac: +1
[17:09] <ricmm> ogra_: jdstrand ah good point
[17:09] <ricmm> its the app actually
[17:10] <ricmm> technically unity8 creates it first
[17:10] <ricmm> as it is the first QML app to launch
[17:10] <plars> asac: I'd like that, I caught a bit of an earlier conversation that makes it sound as if I was asked to do one thing but the expectation is another. So I'd like some clarification
[17:10] <ricmm> so it will be ok
[17:10] <jfunk> asac: iahmad will be the one taking over from jibel
[17:15] <cwayne> hi, why is rtm silo 10 not on the trello board?
[17:15] <cwayne> it looks as though it's been signed off as tested...
[17:16] <kenvandine> thostr_, did you publish rtm silo 6?
[17:18] <kenvandine> barry, someone published rtm silo 6, it wasn't tested or ready to publish
[17:21] <barry> kenvandine: hmm.  looks like it can't publish it anyway, right?  i hope it wasn't me, but i only push the button when i see all blue in the dashboard
[17:22] <kenvandine> barry, yeah, it wasn't checked as tested
[17:22] <kenvandine> but it uploaded
[17:22] <barry> crap
[17:22] <kenvandine> and it really isn't ready :)
[17:22] <barry> ;)
[17:23] <kenvandine> not even sure why it was built in an rtm silo, the comment said not to allocate until it landed in utopic
[17:23] <taiebot> Are the images broken i am asked to upgrade to 275? but i have already upgraded. Done it twice today but it still looks like i am on r274 (on the abot page)
[17:24] <dbarth> barry: ack; cause we need to get started testing; howver is there a lock to prevent us to land a silo that would ne rebuilding after a previous one landed?
[17:24] <barry> kenvandine: i wonder if it was somehow mistakenly blue in the dashboard.  either mistakenly marked as tested or no q/a signoff needed.   i don't remember pushing that publish, but maybe i was a bad monkey
[17:24] <kenvandine> barry, but if it wasn't checked as tested, it shouldn't even let you
[17:24] <kenvandine> weird
[17:24] <barry> yeah
[17:24] <kenvandine> bugs in the tools ?
[17:24] <barry> that's possible i 'spose
[17:25] <kenvandine> it's in proposed
[17:25] <kenvandine> can we kill it quickly?
[17:25] <kenvandine> before it goes to release
[17:25] <barry> dbarth: mark it as qa testing needed and then it should not get published until qa signs off, unless of course kenvandine's gremlins bites you too :/
[17:25] <barry> kenvandine: tell them in #ubuntu-release.  they should be able to kill it
[17:26] <dbarth> ugh, i hope they won't bite me ;)
[17:28] <kenvandine> barry, ok, i made my plea
[17:29] <kenvandine> i hope someone sees it quick enough
[17:29] <barry> kenvandine: ping infinity
[17:29] <kenvandine> promotions in rtm seem to happen quickly
[17:32] <cwayne> sil2100: any idea why rtm silo 10 isn't in the trello board?
[17:33] <robru> Mirv: just reading scroll back. You need to use "landing team tools > assign to silo" from the spreadsheet and it will do the reconfigure on steroids. The "reconfigure" link in the individual cells is the unprivileged one that non-train guards can use.
[17:38] <kenvandine> barry, if we can get testing verified on my new rtm silo 23, could we just force an upload which doesn't include the bad upload?
[17:38] <kenvandine> or i guess maybe a manual upload to squash it
[17:40] <camako> sil2100, it failed again in the same test... We don't have a convenient way of developing/fixing on arm64 _and_ verifying that what we did actually works.. Who do we talk to to exclude it from the list of supported archs?
[17:43] <camako> cjwatson ^^
[17:45] <robru> barry: kenvandine: there's no check in the tools to prevent publishing a silo that isn't marked as tested. The only thing I'd that the dashboard doesn't say "you can publish" until it's marked as tested. The train will allow publishing anything in state "packages built"
[17:45] <kenvandine> bfiller, did you forget to add an rtm line to the spreadsheet for content-hub?  the utopic landing has a comment "sync to rtm"
[17:45] <kenvandine> robru, bummer... i thought you'd have to add some flag or something to ignore it
[17:46] <barry> robru: right.  i never publish anything that isn't blue and says "tested, you can publish"
[17:46] <kenvandine> robru, what's the preferred method of reverting?
[17:46] <barry> robru, kenvandine but it's entirely possible my evil monkey twin (of which i have 12) did it behind my back
[17:46] <robru> kenvandine: nah because that info is only in the spreadsheet, and the train doesn't read anything from the spreadsheet, ever. Only the dashboard does that.
[17:47] <robru> kenvandine: for a revert I'd say do a manually upload with a higher version like "foo.is.bar" with the contents of the lower version
[17:47] <barry> robru: concur
[17:47] <barry> kenvandine: apologies for the derailment
[17:48] <camako> kgunn ^^ see my last comment to sil
[17:48] <robru> kenvandine: if you branch lp:cupstream2distro, there's a script called citrain/reverter.py but i never used it, can't speak to it's efficacy
[17:48] <kenvandine> barry, would you mind doing the revert?  i'm in the middle of testing several things for people
[17:49] <kenvandine> now i need to get my head back on straight... and start breathing :)
[17:51] <barry> kenvandine: please remind me of the source packages to revert?
[17:51] <kenvandine> ubuntu-system-settings :)
[17:51] <barry> kenvandine: also, be aware, i am leaving for a drs appointment in a few minutes.  slangasek will cover for me, so he'll have to babysit it
[17:51] <kenvandine> barry, thx
[17:52] <kenvandine> thankfully i don't think we're in the middle of an rtm image build :)
[17:52] <barry> kenvandine: ubuntu-rtm only, right?
[17:52] <kenvandine> yeah
[17:52] <kenvandine> utopic is cool
[17:52]  * barry runs the script...
[17:53] <barry> kenvandine: IndexError :(
[17:53] <barry> kenvandine: what version should we downgrade to?
[17:54] <kenvandine> 0.3+14.10.20141007-0ubuntu1
[17:54]  * barry tries again
[17:58] <barry> kenvandine: the script didn't fail, but it also hasn't completed yet.  i am out of time.  please coordinate with slangasek in my absence
[18:13] <slangasek> kenvandine: ok, so we still want a revert of ubuntu-system-settings to 0.3+14.10.20141007-0ubuntu1, which is the version in utopic at the moment?
[18:13] <slangasek> kenvandine: is there a bug to reference or anything?
[18:13] <kenvandine> slangasek, nope
[18:14] <slangasek> "or anything" :-)
[18:14] <slangasek> I'm not uploading a revert without knowing why ;-)
[18:14] <kenvandine> there is a newer version in utopic-proposed right now
[18:14] <kenvandine> slangasek, it wasn't meant to be published
[18:14] <kenvandine> never marked as tested
[18:14] <slangasek> oh, so all you need is ubuntu-system-settings 0.3+14.10.20141009-0ubuntu1 not in utopic-proposed?
[18:14] <kenvandine> barry published the silo
[18:14] <kenvandine> slangasek, no... not that
[18:15] <kenvandine> we need 0.3+14.10.20141007-0ubuntu1 in 14.09
[18:15] <slangasek> currently 14.09 has 0.3+14.10.20141007.2-0ubuntu1
[18:15] <kenvandine> i was just mentioning there is a new version close to promotion for utopic
[18:15] <kenvandine> yeah, that's what we are reverting
[18:15] <slangasek> ok
[18:15] <slangasek> so what does the utopic-proposed have to do with it?
[18:16] <kenvandine> i was just mentioning there is a new version close to promotion for utopic, making sure you didn't grab that :)
[18:16] <brendand> ogra_, ricmm - didn't anyone run the autopilot tests with silo 19??
[18:16] <davmor2> sil2100: brendand: tomorrow morning we might be without electric for the first 3 hours while the sparkies run second fix, so I might not make the morning meeting just a heads up on that
[18:16] <slangasek> kenvandine: mmk.  So what you *do* want is ubuntu-rtm/14.09 reverted to 0.3+14.10.20141007-0ubuntu1 ?
[18:16] <brendand> ogra_, ricmm - i mean QA should no way have to do that for sign-offs
[18:16] <kenvandine> slangasek, yes please
[18:16] <slangasek> kenvandine: I need some explanation of "why" to put in the changelog
[18:17] <kenvandine> ok, reverting an unintended upload?
[18:19] <slangasek> kenvandine: ok.  So it hasn't specifically shown any bugs, we just want to revert it quickly before they have a chance to be found the hard way? :)
[18:19] <kenvandine> slangasek, yeah, that silo was not ready to be uploaded, and we actually know it doesn't work
[18:19] <slangasek> ok
[18:20] <kgunn> slangasek: hey, so camako and i are scratching heads, we're trying to approve and land a mir silo...that for some reason is failing on arm64
[18:20] <kgunn> https://launchpadlibrarian.net/186930478/buildlog_ubuntu-utopic-arm64.mir_0.8.0%2B14.10.20141005-0ubuntu1_FAILEDTOBUILD.txt.gz
[18:20] <kenvandine> i don't even know why a rtm silo was created for it... the utopic silo was just experimental with a comment to that affect
[18:20] <kgunn> but slangasek we're not sure why it's building for arm64 all of the sudden
[18:20] <AlbertA> trainguards: can I get a silo for line 85?
[18:20] <kenvandine> slangasek, which might explain my panic here when i saw it got published to rtm :)
[18:21] <slangasek> kgunn: mir has successfully built on arm64 before
[18:21] <kgunn> slangasek: so did something under our feet change? b/c this same code was
[18:21] <asac> kenvandine: hmm. why do you need an experimental silo?
[18:21] <camako> slangasek, it's a new test that was added
[18:21] <asac> that has no landing intend?
[18:21] <kgunn> just built y;day in an rtm silo
[18:21] <kgunn> qa approved and in package migration
[18:21] <camako> kgunn, rtm doesn't have this arch
[18:21] <kenvandine> asac, thostr_ had created it for experimenting with the apneditor
[18:21] <kgunn> ....we're landing in reverse
[18:22] <kenvandine> asac, which we think is close to being ready
[18:22]  * asac wonders if experimental silos are standing practice
[18:22] <asac> kenvandine: and that silo got accidentially synched to rtm?
[18:22] <slangasek> kgunn: arm64 is not enabled for rtm and is enabled for utopic
[18:22] <kenvandine> asac, yes... and published
[18:22] <kenvandine> but not to utopic
[18:22] <kenvandine> just to rtm
[18:22] <slangasek> "just"
[18:22] <sil2100> Well, if it got published, it had to be marked as tested
[18:22] <kenvandine> asac, without being marked as tested
[18:22] <sil2100> hmm
[18:22] <kenvandine> unless someone changed it twice :)
[18:22] <sil2100> kenvandine: which silo was that?
[18:22] <asac> sil2100: slangasek: so i am not sure, but i feel just using comments to mark something taht shouldnt go in might be a bit error prone
[18:23] <kenvandine> it's also marked as requires QA
[18:23] <asac> wonder if we can do something different
[18:23] <asac> iirc we talked once to create a separate ppa tool for experimental silos etc.
[18:23] <kenvandine> silo 20 for utopic
[18:23] <kenvandine> was silo 6 for rtm
[18:23] <asac> not sure
[18:23] <kgunn> slangasek: so question, this is backing us up...long story, it won't land in rtm, stuck in proposed, until it lands in utopic
[18:23] <kenvandine> i don't even know why someone created an rtm silo
[18:23] <asac> i know we discussed, but that was long ago
[18:23] <kgunn> is there any way around ?
[18:23] <kgunn> and if not,
[18:23] <asac> like a cisandtrain :)
[18:23] <kenvandine> hehe
[18:23] <kgunn> how do we test/verify quickly on arm64 ?
[18:24]  * kgunn notes another reason not to land in reverse
[18:24] <sil2100> kenvandine: was that ubuntu-system-settings?
[18:24] <kenvandine> sil2100, yes, apneditor
[18:25] <sil2100> kenvandine: I see barry published thatm, maybe he got struck by the dashboard having a glitch ;/
[18:25] <slangasek> kgunn: sorry, give me one second, still working on this revert for kenvandine - I can explain the "why's it like that" with half a brain, but need my whole brain to answer "how do we fix it" :-)
[18:25] <kenvandine> he said he didn't publish anything that wasn't blue on the dashboard
[18:25] <sil2100> I noticed that sometimes the dashboard doesn't instantly indicate the status of the silo and a refresh ir required
[18:25] <sil2100> And has some broken lefrover states on it...
[18:25] <kenvandine> sil2100, yeah... sometimes
[18:25] <sil2100> Anyway, ouch...
[18:26] <kenvandine> slangasek, thx for helping, i really need to focus on other stuff atm
[18:26] <slangasek> sil2100: is this a dashboard glitch that will be fixed when we move off the spreadsheet?
[18:29] <Ursinha> slangasek: the dashboard fetches the information from spreadsheet/jenkins json, maybe it's something that needs to be revisited in the dashboard side when changing it to talk to ticket system
[18:29] <slangasek> kgunn: so I haven't quite worked it out yet from the history, but I clearly see that someone explicitly included arm64 in the list of targets for mir to build on
[18:30] <kgunn> slangasek: right, my bad...i just looked in rtm ppa's and made a bad conclusion
[18:30] <kgunn> slangasek: but we landed in reverse, e.g. rtm first...then copied to utopic
[18:30] <Ursinha> sil2100: hey, is https://code.launchpad.net/~sil2100/cupstream2distro/cu2d-duallanding-new/+merge/237131 ready for review or I should consider the description that says it's not? :)
[18:30] <kgunn> since that was being advertised to us as a way to get to rtm faster
[18:31] <kgunn> but now we're here....so lots of days have gone by now :)
[18:31] <kgunn> slangasek: anyway...what are our options
[18:31] <slangasek> kgunn: apparently arm64 was listed in the architecture list of the mir package from the beginning... so it doesn't seem to be an accident.  Shouldn't you just be fixing whatever's causing the test to fail on arm64?
[18:31] <camako> slangasek, our devs don't have arm64 hw, how do we fix errors on arm64? some chroot/emulator thing?
[18:31] <slangasek> kgunn: who was advertising this as an option?  the rtm and utopic builds should at most be happening in parallel
[18:32] <kgunn> slangasek: asac
[18:32] <kgunn> and others
[18:32] <sil2100> Ursinha: just wanted the CI to kick in and make sure all is ok ;)
[18:32] <slangasek> camako: well, I have an RT open for porter-arm64.canonical.com which is supposed to be happening RSN, but that doesn't help you today. :/  if it's urgent, talk to dannf about getting hardware access
[18:32] <asac> slangasek: check with sil2100; we had a pilot
[18:32] <asac> with phonedations
[18:33] <slangasek> asac: but kgunn isn't phonedations, so this seems to have progressed beyond the pilot :)
[18:33] <Ursinha> sil2100: okay :) let me know when that's up for review then :)
[18:33] <camako> slangasek, since we don't have a way to verify the code/fixes, should we be supporting this arch?
[18:33] <kgunn> olli_: ^
[18:33] <sil2100> Ursinha: so, most of the pieces there are ready for review more or less - there might be some changes still, but I guess most of it is ready
[18:33] <asac> slangasek: yeah, he had troubles and i suggested he might wanted to check if with LT if thats ok to try
[18:34] <asac> slangasek: in general i dont know how the pilot was implemented. i fully agree it should build on bothh targets at tsame time
[18:34] <Ursinha> sil2100: got it
[18:34] <asac> what phonedations i thought is doing is just focus on testing on rtm first
[18:34] <asac> and publish rtm first
[18:34] <asac> but sil2100 knows details
[18:34] <slangasek> camako: that's a question for the mir team to decide, not me - I don't know why arm64 was put in the architecture list in the first place
[18:34] <sil2100> asac: isn't that what everyone that's landing first in RTM doing?
[18:34] <asac> slangasek: ^^ :)
[18:34] <asac> seems the pilot was rolled out
[18:35] <asac> sil2100: are we doing this everywhere now?
[18:35] <kgunn> olli_: so long story made short, i'm concerned about lock-down keeping this mir landing out...we landed in reverse, but the delayed discovering arm64 no workie
[18:35]  * asac doesnt mind if it works and if slangasek is also happy'ish
[18:35] <camako> slangasek, fair enough... who do we talk to to get arm64 out of the arch list for mir?
[18:35] <asac> sil2100: so id dint realize we rolled the pilot out to more teams
[18:35] <kgunn> olli_: so i'm gonna ask that altho the mir landing isn't critical, that we have some grace into friday for the lock down, and let us land
[18:35] <asac> would have expected an announce
[18:35] <slangasek> camako: er, the mir team should make that change
[18:35] <asac> so we are all on same page
[18:36] <slangasek> camako, kgunn: I'm perfectly happy with the mir team saying that arm64 shouldn't be in the supported architecture list; what I don't want is for this to be a flip-flop
[18:36] <asac> kgunn: is it built?
[18:36] <slangasek> where we remove the package one day and re-add it the next
[18:36] <slangasek> however, there are also reverse-dependencies on mir in the archive that would need to be dealt with
[18:37] <olli_> kgunn, I think that's fine
[18:37] <kgunn> qtmir, platform-api, unity-sytsem-compositor
[18:37] <jdstrand> balloons: fyi, approved the MP
[18:38] <AlbertA2> slangasek: can I get a silo for line 85?
[18:38] <balloons> ack
[18:38] <camako> kgunn, slangasek, qtmir, and papi don't support arm64
[18:38] <camako> only u-s-c
[18:38] <asac> sil2100: so is it still a pilot or is it an option :)?
[18:38] <sil2100> asac: we didn't, it happened automatically
[18:39] <asac> so you lost control :P
[18:39] <sil2100> asac: it just changed into an option, noticed that people started landing this way without any problems so yeah ;)
[18:39] <kgunn> camako: xmir ?
[18:39] <camako> which is another reason to not support arm64... since what do you do with mir if you don't have others in place
[18:39] <kgunn> sorry, just being complete
[18:39] <slangasek> camako: the list that needs to be sorted through is here: http://paste.ubuntu.com/8528438/
[18:39] <asac> slangasek: so ... guess above is evolution :)
[18:39] <asac> not sure we want to row back?
[18:39] <sil2100> asac: as long as changes get synced up to utopic, which is what we're making sure, then we don't care on the process
[18:39] <slangasek> sil2100, asac: we need to reel this back in.  No one should be building in rtm first.
[18:40] <camako> kgunn, dunno abt xmir
[18:40] <sil2100> hm, I guess people that were present on the meeting a few weeks ago misunderstood that, right?
[18:40] <slangasek> sil2100: no, this goes to the discussion we had about not having n-way "sync" handling in the citrain
[18:40] <asac> so i think its the combo of sync
[18:40] <asac> and rtm first
[18:40] <asac> that causes headaches for slangasek
[18:41] <slangasek> syncs should always be built in ubuntu->rtm, not the other way around
[18:41] <slangasek> and we should support having these tested in parallel
[18:41] <asac> but shouldnt britney catch it in utopic? isnt rtm first actually safer because we have britney there, but not rtm?
[18:41] <sil2100> Ok, anyway this will be invalid tomorrow, as the stuff for the dual-landing as per slangasek recommendations is ready
[18:41] <slangasek> asac: we have britney in both, and how would *not* having britney make something safer?
[18:41] <asac> slangasek: but in practice utopci to rtm sync is also not aalways true and only proposed migration would catch the casese where a sync isnt right, correct?
[18:42] <sil2100> slangasek: as already mentioned during our discussion, during that meeting no one said 'don't build rtm first', so people started doing that
[18:42] <sil2100> slangasek: when rsalveti came up with this idea
[18:42] <asac> slangasek: yeah i was saying its afer to sync to utopic if rtm doesnt hafve brtney
[18:42] <asac> slangasek: instead of synching from utopic into non-britney rtm, but its moot ifthere is britney in both
[18:42] <asac> sil2100: note that sync wasnt the default then
[18:42] <asac> so uits a mix up
[18:42] <sil2100> asac: it wasn't?
[18:42] <asac> no
[18:42] <sil2100> asac: it was
[18:43] <asac> we worked on it
[18:43] <asac> i dont think we said we would binary sync his rtm stuff
[18:43] <sil2100> asac: no no, it was already there, I remember that because we were discussing with landers about how they like the syncs
[18:43] <asac> slangasek: so in general i think its not that risky with same toolchain on both sides, and britney, but i think i even asked you directly in our sync how we can do both directions :)
[18:43] <asac> slangasek: guess we misundestood
[18:43] <balloons> ogra_, jdstrand where are you seeing the apparmor issues at? And is only calc affected? from the looks I things I assume calendar and a few more that do similar things would also have the same issue
[18:44] <sil2100> Then I might have either misunderstand the decisions, same for others
[18:44] <sil2100> Anyway, did this cause any issues right now?
[18:44] <asac> slangasek: i am in general concerned about syncing tbh
[18:44] <asac> reproducibility etc.
[18:44] <asac> sil2100: we dont know, but we should imo take a step back and think through exactly what what means
[18:45] <sil2100> asac: but is there a problem caused by this right now?
[18:45] <sil2100> Or are we discussing this as a principle?
[18:45] <sil2100> As I understand that it might be 'not too good' by principle, but I want to know if we noticed a real problem regarding that right now
[18:46] <asac> sil2100: right. i personally thinhk we should not judge out of principle what direction works
[18:46] <asac> and we shouldnt dismiss rtm to utopic synching
[18:46] <asac> however, i dont think we should do it without thinking hard either
[18:46] <asac> also we shouldnt do it by letting landers just adopt a pilot
[18:46] <asac> without us not enforcing that its not established procedure
[18:47] <sil2100> As I mentioned, we will introduce anyway a new scheme tomorrow that will no longer use this 'broken' approach anyway
[18:47] <slangasek> rtm to utopic syncing is a problem because we have a mess of confusing options implemented in spaghetti code on the train to support this
[18:47] <sil2100> Since CI Train now will simply build for utopic and publish to both 14.09 and utopic
[18:47] <asac> ok, if thats the only concern then thats not so worrying. i was more worrida bout archive integrity / bustag etc.
[18:47] <asac> :)\
[18:47] <sil2100> None issues got reported, but I agree with slangasek that it can lead to potential problems
[18:48] <asac> anyway, i dont want to really make a call on this. all i know is that we had a pilot and that pilot not well executed
[18:48] <asac> and i dont think thats the way to do it
[18:48] <slangasek> sil2100: ok, the above conversation with kgunn is an issue that's being reported
[18:48] <jdstrand> balloons: I was only pointed to the calculator. anything that uses fakeenv would be affected (though I don't know what all that was)
[18:48] <jdstrand> s/was/is/
[18:48] <sil2100> slangasek: the arm64 build failure on utopic?
[18:48] <slangasek> sil2100: that they are finding late as a result of trying to sync from rtm to utopic, yes
[18:48] <asac> let me know what you agreed and what the way forward is
[18:49] <balloons> jdstrand, ok. I'm just curious who's trying to land this and be pointed at the results they got. I know more than calc must be affected
[18:49] <asac> i dont think there is a big problem besides letting a confineed pilot go loose without making a team decision etc.
[18:49] <asac> but thats a pretty big problem for my hat :)
[18:50] <asac> sil2100: the ricmm AP regression ... what packages are affected?
[18:50] <asac> seems only balloons  packages are afected?
[18:50] <asac> that feels oddish as above
[18:50] <sil2100> I might have not gated that correctly, but as I am no manager I do not know what management decisions have been made
[18:50] <asac> sil2100: you have big  authority
[18:50] <sil2100> So every landing into RTM first I thought was decision somewhere ;p
[18:50] <sergiusens> asac: sil2100 iirc, you asked me how the pilot was going, I said it was going fine, but most of my stuff was golang and then came an announcement email
[18:50] <asac> i doubt someone came to you telling you that management decided to land first everywhere
[18:51] <asac> sil2100: you are the authority about the landing engine
[18:51] <asac> sil2100: noone makes decision about changing this witout talking to you
[18:51] <asac> so just reject anyone saying that in futrue
[18:51] <kgunn> what really hurt us is that our project jenkins doesn't test it, rtm didn't test it, only utopic landing....so we didn't know for a long time
[18:52] <asac> or if you feel there might be a decision, thats not the case
[18:52] <asac> until someone talks to you
[18:52] <asac> sil2100: ^^
[18:52] <asac> hope that helps
[18:52] <asac> giving you backup
[18:52] <sil2100> Ok, anyway seems to be my bad then, but there was only a limited number of people landing first to RTM as well
[18:52] <asac> sil2100: no its fine
[18:52] <asac> small bad :)
[18:53] <sil2100> And from what I know this did not become a problem in overall, since otherwise we would stop the line
[18:53] <sil2100> kgunn's problem is the first we saw
[18:53] <asac> just figure with steve what we do now :)
[18:53] <sil2100> And even this doesn't seem to be super bad
[18:53] <asac> without being unpragmatic i guess
[18:53] <sil2100> asac: well, we already have an evil scheme that's just waiting in a branch
[18:53] <asac> sil2100: is that agreed?
[18:53] <asac> what is that scheme?
[18:53] <asac> well, i dont mind
[18:54] <asac> as long as your team and steve are aligned and all  the landers are happy with what is coming
[18:54] <asac> or at least are not unhappy :)
[18:54] <sil2100> asac: it came up with a discussion with slangasek, so yes - it's much safer, much more convinient
[18:54] <sil2100> And less resource-usage
[18:54] <asac> ok
[18:54] <sil2100> As basically we'll only use utopic silos
[18:54] <sergiusens> asac: sil2100 wasn't the rtm image supposed to be our fallback for when the ubuntu archive froze?
[18:54] <slangasek> mmm
[18:54] <sergiusens> and avoid the FFe?
[18:55] <slangasek> does anyone here know how I actually upload to ubuntu-rtm?
[18:55] <asac> sil2100: i assum thats only for the sync case?
[18:55] <asac> sil2100: i guess for diverged trees it makes sense to use rtm silos
[18:55] <asac> anyway
[18:55] <sil2100> slangasek: you need to change your dput.cf
[18:55] <asac> slangasek: no way, only through silo :)
[18:55] <sergiusens> and play nicer with the community
[18:55] <asac> sil2100: dont tell :P
[18:55] <asac> hehe
[18:55] <slangasek> sil2100: yeah, do you have a config for that?
[18:55] <asac> j.k.
[18:55] <sil2100> slangasek: yeah, pastebining int now
[18:56] <sil2100> slangasek: http://paste.ubuntu.com/8528507/
[18:56] <rsalveti> sil2100: asac: the main issue is that we don't have a clear definition about what people should do :-)
[18:56] <sil2100> asac: ;)
[18:56] <rsalveti> so they just assume stuff
[18:56] <rsalveti> but yeah, doing binary copies from rtm to ubuntu is not a great idea
[18:56] <slangasek> sil2100: thanks
[18:56] <sil2100> rsalveti: yeah, that's why we started working on the LandingProcess document as well
[18:56] <slangasek> kenvandine: revert uploading
[18:56] <asac> rsalveti: i dont buy that
[18:56] <rsalveti> my idea was landing first in RTM and then landing the src package in utopic
[18:56] <kenvandine> slangasek, thanks!
[18:56] <asac> rsalveti: folks just tried, LT missed or thought it was ok
[18:56] <sil2100> rsalveti: oh, source copy then?
[18:56] <asac> and then folks copied that approach
[18:57] <asac> like floodgating
[18:57] <sergiusens> I don't like the binary copy fwiw
[18:57] <sergiusens> and mentioned it a couple of times
[18:57] <asac> everyone knew that utopic first was the standard
[18:57] <sil2100> Damn
[18:57] <asac> i at least talked to everyone twice about that
[18:57] <rsalveti> asac: right, but not having a well defined process makes people to assume stuff
[18:57] <asac> because they came all to me complaining
[18:57] <rsalveti> or copy behavior from others
[18:57] <asac> :P
[18:57] <sil2100> Then why did everyone tell me that source copies are bad?!
[18:57] <asac> i dont complain
[18:57] <kenvandine> can someone confirm line 86 is an isolated bug fix?
[18:57] <kenvandine> diff https://code.launchpad.net/~ken-vandine/content-hub/lp1373086/+merge/237459
[18:57] <slangasek> sil2100: because I don't agree with sergiusens ;)
[18:57] <sil2100> ;p
[18:58] <asac> sergiusens: no
[18:58] <rsalveti> it all depends on the package
[18:58] <asac> sergiusens: we will revisit next week
[18:58] <sergiusens> what did I say? :-)
[18:58] <slangasek> sil2100: I think treating something as a *sync* when it's not binary is bad
[18:58] <slangasek> sergiusens: <sergiusens> I don't like the binary copy fwiw
[18:58] <asac> sergiusens: will you fallback to rtm when utoic is frozen :)
[18:58] <rsalveti> for sensitive ones (that gets easily affected by gcc and such), it might not always be a good idea to do binary copy
[18:58] <asac> answer is "yes, if its a critical bug approved"
[18:58] <sil2100> I... I'm confused, I think that it's time for me to EOD now ;p
[18:59] <sil2100> Anyway, tomorrow a new approach will be available in the train which I hope will become the default
[18:59] <sil2100> We'll discuss that more tomorrow I guess after it's deployed in production
[18:59] <sergiusens> slangasek: oh, right ;-) that's fine to disagree on and I'm not making a fuss :-P
[18:59]  * sil2100 really needs to go now
[18:59] <sil2100> o/
[18:59]  * sergiusens should of kept his mouth shut or fingers tied :-)
[18:59] <asac> imo we just need faster builds
[18:59] <asac> then push it into both
[18:59] <asac> oh, but then we have theversion problem
[18:59] <asac> *shrug*
[18:59] <rsalveti> exactly
[18:59] <rsalveti> no simple solution that works for everyone
[18:59] <asac> we could start using a universal versioning scheme
[19:00] <asac> that encodes package version with the nice archive :P
[19:00] <asac> hash
[19:00] <sergiusens> asac: rsalveti only good solution is for everyone to know about packaging and do their own packaging branches ;-)
[19:00] <rsalveti> sergiusens: there is still an issue of publishing them into 2 archives
[19:00] <sergiusens> but I think that's what most core devs complained about when using the train
[19:01] <rsalveti> the only sane way is not branching rtm so early in the process
[19:01] <rsalveti> and make it a more 'stable-only' thing
[19:01] <asac> rsalveti: right, thats the plan
[19:01] <asac> rsalveti: every two weeks product team meets, checks if we are feature ready for another feature release
[19:01] <sergiusens> still, I thought rtm was going to be a fork to make life easier and gain speed, turned to be the other way around
[19:01] <asac> if we are, we branch, bug fix only, 2 weeks before market we branch a minibranch for critical only
[19:01] <asac> the stable branch continues so we can feed more stable updates from that
[19:02] <asac> until w ahve the neds feature wave
[19:02] <rsalveti> right
[19:02] <asac> simple
[19:02] <asac> :)
[19:02] <rsalveti> yeah
[19:02] <asac> every 2-3 month we cut from feature branch; 1 month stabilization 2 weeks productization :)
[19:02] <sergiusens> asac: you will only see how painful the train is until you use it ;-)
[19:03] <sergiusens> asac: you can be the next lander for mir or dbus-cpp ;-)
[19:03] <asac> sergiusens: i dont need to
[19:03] <asac> i know the world before the train
[19:03] <Ursinha> asac: I think you do :)
[19:03] <asac> very well
[19:03] <asac> and i know the train makes big difference without even trying :P
[19:03] <asac> positive
[19:03] <slangasek> camako, kgunn: ok, dropping mir on arm64 requires sourceful uploads of glmark2, gtk+3.0, trust-store, and ubuntu-system-settings-online-accounts to remove their use of mir on arm64 (i.e., to bring them in line with powerpc, ppc64el architectures); and binary removals from the archive of unity-system-compositor
[19:03] <asac> and yes, it would be amazing if its airline
[19:04] <jdstrand> slangasek: "I think treating something as a *sync* when it's not binary is bad". I think it depends on your perspective. I thought of the source syncs as akin to Debian syncs, since ubuntu and ubuntu-rtm are different distros. I also can see the counterpoint to that
[19:04] <camako>  slangasek, ack we will do that
[19:04] <Ursinha> sergiusens: we're working on replacing the spreadsheet right now, next step will be probably the dynamic PPA creation and assignment... citrain will become less horrible overtime, until it becomes the airline :)
[19:04] <Ursinha> and I'd love to find another name, I don't like "airline" hehe
[19:05] <AlbertA2> Ursinha: "rocketship" to go with the whole space theme we got going in canonical
[19:05] <AlbertA2> :)
[19:05] <Ursinha> haha, I kinda like it
[19:06] <asac> slangasek: can i in theory land everything too?
[19:06] <asac> slangasek: like offer to serve as a slave for kgunn if he pays me to? or do i need special powers?
[19:07] <asac> sergiusens: it might actually happen :)
[19:08] <sergiusens> asac: lol, acting as a trainguard != lander ;-)
[19:08] <asac> sergiusens: that i land stuff ... just need to sleep over the idea :P
[19:08] <asac> sergiusens: no, actually landing for folks
[19:08] <Ursinha> asac: the only way to get full access is being a coredev, and you still need a QA person to signoff your changes
[19:08] <Ursinha> as a lander
[19:09] <asac> Ursinha: i want to land, not be a trainguard
[19:09] <asac> right
[19:09] <asac> thats fine
[19:09] <Ursinha> asac: as a lander :)
[19:09] <asac> just as lander
[19:09] <asac> wonder if the merge back into mir etc. would work
[19:09] <asac> but guess so
[19:09] <Ursinha> asac: you can't cheat the system, try to use it as is :)
[19:10] <Ursinha> asac: https://wiki.ubuntu.com/citrain/NewbieGuide
[19:10] <asac> i wouldnt cheat; i would do a challenge and sacrifice my blood for the sake of a much greater goal :P
[19:10] <asac> but i have to check and first learn so i dont risk the mielstones
[19:10] <sergiusens> wtf
[19:11] <sergiusens> train procedures broke again
[19:11] <sergiusens> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/48/console
[19:11] <sergiusens> I thought a rebuild was an empty MP
[19:11] <sergiusens> now it's just "nothing to do, goodbye"
[19:12] <asac> Ursinha: that newbieguide is for trainguards, right? not landers
[19:12] <asac> ah yeah it says it right on top
[19:12] <Ursinha> :)
[19:12] <asac> is there something similar for landers?
[19:12] <asac> wanna-be-landers
[19:13] <slangasek> AlbertA2: silo 006 assigned, sorry for the delay
[19:13] <AlbertA2> slangasek: awesome thanks!
[19:14] <slangasek> asac: "land everything"? in reference to the mir fix?
[19:14] <Ursinha> sergiusens: I'm trying to understand what changed to justify that
[19:14] <slangasek> asac: these are mostly source package changes, which could reasonably bypass the silo in favor of direct core-dev uploads (since they're packaging-only changes)
[19:14] <sergiusens> Ursinha: I added an "rebuild" debian/changelog to get something going
[19:15] <slangasek> AlbertA2: oh, hang on, something failed
[19:15] <asac> slangasek: i have nothing specific in mind; just wondering if i could offer folks to land their stuff if they pay me :)
[19:15] <slangasek> heh
[19:15] <asac> i will tell you tomorrow
[19:15] <asac> hope you talk me out of it :)
[19:16] <sergiusens> asac: I'll stop complaining when the creators of process live through it, is that payment enough? :-P
[19:19] <slangasek> AlbertA2: sorry, I appear to not know what I'm doing with the train; I thought this was a bit more straightforward than it seems to be
[19:19] <slangasek> robru: sorry, if you're still around, can you lart me in the direction of how to get a request_id for a new silo?
[19:19] <slangasek> robru: n/m, I know what I'm doing now
[19:20] <AlbertA2> slangasek: np
[19:20] <Ursinha> slangasek: I think you need to go to the spreadsheet line and choose the option from the menu
[19:20] <Ursinha> oh, you found that already
[19:20] <slangasek> yeah
[19:24] <sergiusens> Ursinha: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/48/parameters/
[19:25] <sergiusens> Ursinha: force rebuild wasn't necessary before; I guess I could of accomplished the same
[19:25] <Ursinha> sergiusens: if that follows logic you shouldn't need that now as you have a small diff
[19:26] <Ursinha> sergiusens: can we retry that with debug on?
[19:26] <slangasek> AlbertA2: ^^ there, *now* the silo is assigned
[19:26] <AlbertA2> slangasek: cool thanks!
[19:29] <sergiusens> Ursinha: it's too late, it's no longer an empty commit and building already ;)
[19:30] <Ursinha> sergiusens: empty commit?
[19:30] <sergiusens> Ursinha: sorry, empty merge
[19:30] <sergiusens> Ursinha: no diff MP
[19:31] <Ursinha> sergiusens: I thought the MP was this one, https://code.launchpad.net/~sergiusens/unity-scope-click/rebuild/+merge/237838 and when I saw it it already had a diff
[19:32] <Ursinha> sergiusens: empty MPs used to work before? that was kind of a bug disguised as a feature hehe
[19:32] <sergiusens> Ursinha: yes, but look at the build log when I tried, rev was 284, it's now 285 ;-)
[19:33] <sergiusens> Ursinha: well it's the only way to trigger a rebuild on the train and what trainguards recommended
[19:33] <Ursinha> sergiusens: if you move too fast while asking for help, people trying to help might get confused :)
[19:33] <sergiusens> Ursinha: oh, I said it was broken and on the next line I said I would be circumventing that :-)
[19:36] <Ursinha> sergiusens: I'm not really questioning the trainguards recommendation, it's that ignoring empty MPs is kinda "expected" hence my comment :) I'll talk to lukasz once he's back to understand what changed there
[19:45] <camako> slangasek, I'll have to start over. Can you please help me abandon the utopic silo 8 and rtm silo 20 please?
[19:45] <slangasek> camako: why start over, vs. pushing an additional commit to drop arm64 from the arch list?
[19:46] <slangasek> camako: (forgive me if this is a stupid question - but it doesn't seem to me that you should need to reset things)
[19:46] <camako> slangasek, please educate me... this is a sync silo and rtm part is in proposed.. So they won't have the same code...
[19:46] <slangasek> ah
[19:47] <slangasek> right, I don't want to try to disentangle this if it's a sync silo :)
[19:47] <camako> and qtmir, is abt to get another silo, which will probably get ahead
[19:48] <camako> and invalidate our testing anyways
[19:49] <asac> Ursinha: sergiusens: so i know from old didrocks times that empty MPs _was_ a bandaid feature in old days to allow self-serviced rebuilds
[19:49] <asac> we were quite happy that it kind of came for free and we had many other issues to solve :P
[19:49] <Ursinha> asac: I thought so, want to know when it got "fixed"
[19:49] <asac> not sure if we have something better
[19:49] <asac> if so its surely worth killing :P
[19:50] <Ursinha> it's probably fixed by accident
[19:50] <robru> Ursinha: empty MP's are the official way to trigger no-change rebuilds in the train, and can also be used to effect a trunk release in the event that somebody pushed to trunk manually without doing a train release
[19:50] <asac> Ursinha: i think its a bug if there is no equivalent available to trigger self-serviced rebuilds now
[19:50] <asac> its a feature that you can rebuild :)
[19:51] <asac> right, so i think its a bug because thought its a fix
[19:51] <asac> someone
[19:51] <Ursinha> robru, asac, I'm not disagreeing with you :) I just pointed that it's kind of a bug in essence, but if it's used like that and the "bug got fixed" we need to revert it :)
[19:51] <asac> thats the problem with these magic
[19:51] <asac> ack
[19:51] <asac> we should surely bring that or something better back though
[19:52] <asac> guess bring back and improve later
[19:52] <asac> or right after
[19:52] <Ursinha> asac: +1 on that
[19:52] <Ursinha> we're improving while replacing
[19:52] <asac> guess the new frontend will fix this ?
[19:53]  * asac wonders if citrain has a bugtracker :)
[19:53] <Ursinha> asac: I believe that would be cu2d project in launchpad (bugs against that project)
[19:54] <Ursinha> robru: I'm afraid of asking questions and engaging you on conversations when you should be somewhere !irc :)
[19:55] <sergiusens> Ursinha: I'll wait on this one
[19:55] <sergiusens> Ursinha: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/51/console
[19:55] <sergiusens> Ursinha: trying to rebuild content-hub fails
[19:55] <sergiusens> not clear why
[19:55]  * asac wonders if the term cu2d will die eventually as new pieces land:)
[19:56] <slangasek> camako: ok, so I can clean these silos; after that, you'll let me know when you need new silos?  Are you going to still do this as a sync from rtm->utopic?
[19:56] <Ursinha> asac: yes, it'll be one of the latest pieces to die but it will
[19:56] <Ursinha> s/latest/last/
[19:56] <camako> slangasek, sure Ill let you know.. it'll be utopic first this time then rtm
[19:56] <slangasek> ok
[19:56] <Ursinha> sergiusens: I'm looking
[19:57] <sergiusens> Ursinha: fwiw, the ppa shows it's building still
[19:57] <camako> slangasek, what's gonna happen to the rtm landing stuck in rtm-proposed?
[19:57] <slangasek> camako: oh. why is it stuck in rtm-proposed?
[19:58] <slangasek> camako: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/update_excuses.html says it's a valid candidate
[19:58] <camako> because of some packaging issue we had. sil2100, and cjwatson were aware..
[19:58] <slangasek> camako: ah.  right, it's stuck because some uninstallable reverse-dependencies.  Well, those packages will still be there
[19:58] <camako> slangasek, the plan was to land utopic and then it would land on rtm
[19:58] <barry> hi folks, i'm back
[19:58] <slangasek> camako: I /can/ remove the packages from 14.09-proposed, but there's no need to.
[19:59] <Ursinha> sergiusens: failed to build?
[19:59] <camako> slangasek, since we didn't land on utopic, I'd rather remove them
[19:59] <sergiusens> Ursinha: no, it's still building in the ppa
[19:59] <sergiusens> Ursinha: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-008/+build/6448067
[19:59] <sergiusens> Ursinha: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-008/+build/6448066
[19:59] <slangasek> camako: I'd rather just not worry about them, they aren't harming anything and won't get in anywhere that it affects people until the rest of the packaging is sorted?
[20:00] <barry> kenvandine: did things get straightened out with rtm?
[20:00] <barry> (fwiw, the script failed again)
[20:00] <kenvandine> barry, yup, slangasek took care of it
[20:00] <camako> slangasek, by the time we are ready to land again, we'll have different code.. don't wanna fork..
[20:00] <kenvandine> thx
[20:01] <barry> kenvandine: cool.  thanks slangasek
[20:01] <Ursinha> sergiusens: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-1-build/51/console , right?
[20:02] <kenvandine> barry, sil2100 suspected you might have been bit by the dashboard getting out of sync
[20:02] <kenvandine> sometimes it shows blue when it shouldn't, briefly
[20:02] <barry> kenvandine: ah.  okay, that's good to know
[20:02]  * barry will be a mellow monkey not an eager beaver
[20:03] <dbarth> guys, is mir landed finally? i have a silo full of fixes stuck on a mir dependency
[20:03] <slangasek> camako: there's no need to fork... I'm saying you can ignore the packages that are in 14.09-proposed and behave as if they didn't happen, unless you think there's a risk that they'll make it into 14.09
[20:03] <dbarth>  ubuntu-system-settings-online-accounts : Depends: libmirclient8 (>= 0.8.0+14.10.20141005) but 0.7.3+14.10.20140918.1-0ubuntu1 is to be installed
[20:03] <slangasek> anyway, if you really need them out of there I'll have a look after lunch
[20:03] <kenvandine> barry, i guess when in doubt, look at the spreadsheet :)
[20:03] <barry> kenvandine: now i am full of doubt ;)
[20:04] <camako> slangasek, that's what I'm afraid of.. them getting promoted by mistake.. but if you think it's ok .. it's ok by me.
[20:05] <camako> dbarth, long story.... we had to give up both mir silos...
[20:05] <dbarth> camako: so i just need to rebuild mine, rihgt?
[20:05] <camako> yeah.. just base it on 0.7.3
[20:06] <sergiusens> Ursinha: yes
[20:07] <dbarth> camako: wdym? i just have an otopn to rebuild; do i need to update the packaging in the branches?
[20:07] <dbarth> camako: or something in the silos themeslves?
[20:08] <Ursinha> sergiusens: man, this is a mess. some packages failed to build and the build job returned failed, but there are packages still building there, though
[20:08] <camako> dbarth, lemme check
[20:08] <dbarth> camako: this is rtm silo 2
[20:09] <dbarth> camako: i just triggered a rebuild, but if chceck the ppa, you can't install the ussoa package because of that dep issue
[20:09] <cjwatson> camako,kgunn,slangasek: I went to some effort to get mir/arm64 building a while back, as part of a general effort to simplify packaging by having our stack building more consistently in more places so that we have fewer manual architecture exclusions littered all over the place
[20:09] <cjwatson> if you need to remove packages temporarily, I would prefer it if we just removed binaries as needed rather than excluding them from the packaging
[20:09] <Ursinha> sergiusens: is it expected that unity-scope-click fails to build there?
[20:09] <cjwatson> then it's easier for a porter to come along later and fix things
[20:09] <sergiusens> Ursinha: yes
[20:09] <camako> dbarth, I see.. so we gave up our silo... but mir 0.8 is still in proposed... I think it needs to be removed probably
[20:10] <Ursinha> sergiusens: okay
[20:10] <camako> dbarth, rtm-proposed that is
[20:10] <camako> dbarth, and then you just rebuild I guess
[20:10] <dbarth> camako: yes
[20:10] <dbarth> camako: but can mir be removed from proposed?
[20:10] <sergiusens> Ursinha: simple rebuild wasn't enough as it seems the download manager is fully mocked there...
[20:10] <cjwatson> dbarth: why does it need to be removed?
[20:11] <cjwatson> you can surely just upload over it later
[20:11] <camako> dbarth, yes.. see my convo a few mins back with slangasek
[20:11] <dbarth> cjwatson: i have a silo stuck on a dependency that is not available; so the silo does not install
[20:11] <cjwatson> well aware but why does that need removal?
[20:12] <cjwatson> we agreed a strategy for that earlier today
[20:12] <dbarth> ah, not aware sorry
[20:12] <dbarth> camako:  ^^
[20:12] <camako> cjwatson, it's picking up mir0.8 which doesn't exist
[20:12] <dbarth> so how do i get my silo back to clean state?
[20:12] <cjwatson> well just wait
[20:12] <camako> or rather, shouldn't any more
[20:13] <cjwatson> camako: so where's the mir/utopic landing?
[20:13] <camako> cjwatson, withdrawn
[20:13] <Ursinha> sergiusens: so your problem is that the build script failed? content-hub is still building there, but script failed because of unity-scope-click (it seems)
[20:14] <cjwatson> camako: yeah, foolish reasons IMO
[20:14] <camako> cjwatson, see scrollback
[20:14] <cjwatson> I think we should put it back in, strip arm64 binaries out of the archive as needed, move on
[20:14] <cjwatson> slangasek: ^-
[20:14] <sergiusens> Ursinha: but it was told to only build for content-hub in the parameters
[20:15] <camako> kgunn ^^
[20:15] <cjwatson> dbarth: also there's no reason for this to hard-block your silo; we can have it build against non-proposed
[20:15] <tvoss> trainguards, could someone reconfigure rtm silo 5
[20:15] <tvoss> ?
[20:15] <lool> hey trainguards, I've updated silo 5 to list a missing package, would you mind reconfiuring it?
[20:15] <lool> as to sync the extra package (ubuntu-location-provider-here)
[20:15] <cjwatson> dbarth: which silo is this?
[20:15] <dbarth> cjwatson: it's rtm-002
[20:15] <barry> tvoss: sure thing
[20:15] <dbarth> i just took a bad dependency, cause the initial build this morning was fine
[20:15] <tvoss> barry, great, thank you
[20:16] <Ursinha> sergiusens: hm, okay, one moment
[20:16] <barry> tvoss: row 65, right?
[20:16] <cjwatson> dbarth: uh it appears to have built?
[20:16] <cjwatson> at least on amd64
[20:16] <sergiusens> Ursinha: your explanation can make sense though; but there is no indication (clear one) of that being the reason
[20:16] <dbarth> cjwatson: i triggered another rebuild a few minutes ago
[20:16] <tvoss> AlbertA, ^
[20:16] <cjwatson> dbarth: to achieve what?
[20:16] <tvoss> AlbertA, see barry's question
[20:17] <dbarth> cjwatson: try to get rid of the dependency; but that won't work since mir is still in proposed
[20:17] <cjwatson> so hammering on rebuild without understanding
[20:17] <cjwatson> yay citrain :-/
[20:17] <dbarth> cjwatson: the silo is yours to reconfigure if you can fix that
[20:17] <barry> tvoss, AlbertA: there are silo conflicts.  should we override? https://ci-train.ubuntu.com/job/prepare-silo/2694/console
[20:17] <dbarth> ;)
[20:18] <cjwatson> dbarth: the silo is now configured to build not against -proposed.  rebuilding it now should be effective when it wasn't earlier
[20:18] <dbarth> cjwatson: was following camako's remarks
[20:18] <Ursinha> sergiusens: what I see is that it tried to build unity-scope-click and failed, if expected behavior is to ignore all other packages when you provide specific names then this should be the problem (should rebuild selectively but it's not)
[20:18] <dbarth> cjwatson: thank you sir! :)
[20:18] <Ursinha> sergiusens: I'm looking at the code here to see if it's a bug or jenkins misbehaving
[20:18] <bfiller> barry: could I have a silo for line 87 please?
[20:19] <sergiusens> Ursinha: well, the success value there might indicate everything is good in the big picture
[20:19] <sergiusens> Ursinha: so it can make sense; but only if you are very very familiar with the train ;-)
[20:19] <kgunn> camako: yeah kind of following...so i think cjwatson and slangasek aren't saying the same thing
[20:19] <cjwatson> we are not
[20:19] <cjwatson> so we need to have it out :)
[20:19] <kgunn> :)
[20:19] <AlbertA> barry: yes ignore landing-001
[20:19] <sergiusens> Ursinha: so one log line can do worlds there before failing; and it could wait for the build status of content hub to return, as it does in other cases
[20:19] <Ursinha> sergiusens: build job #51 failed, where is the success you're seeing?
[20:20] <barry> bfiller: yep, after AlbertA & tvoss
[20:20] <barry> AlbertA: cool
[20:20] <cjwatson> my position is that packages should only have explicit architecture limitations when there is no viable alternative, and simple build failures aren't a good enough reason for that awkwardness
[20:20] <bfiller> barry: thanks
[20:20] <sergiusens> Ursinha: I said "might"
[20:20] <sergiusens> Ursinha: and "could"
[20:20] <cjwatson> and that if a package is long-term failing to build and that we believe it to be an unreasonable cost/benefit trade-off to fix, it's reasonable to remove the outdated binaries from the archive without blacklisting the architecture from the packaging
[20:21] <sergiusens> Ursinha: meaning, not talking about the silo itself, but the logic the train might have ;-)
[20:21] <Ursinha> sergiusens: haha, okay, sorry :) the problem is probably it's not considering the right list of packages, we could try to rebuild with debug on
[20:21] <cjwatson> but in general not having the architecture limitation means that the failures are surfaced to porters who may wish to deal with them, rather than artificially hidden
[20:24] <dbarth> barry: it's about that line 82 ;) i'd still like to get a silo for it; if that's cool with kenvandine's other landings
[20:26] <slangasek> cjwatson: did you also see the list of a half-dozen reverse-dependencies that need to be fixed to not reference mir on arm64?  I don't think, for an architecture-specific package like mir, upstream should be at the mercy of porters to get their landings done
[20:26] <slangasek> cjwatson: also, mir does have an architecture list in debian/control already, it's just that arm64 is in it - when upstream doesn't have any way to support that
[20:26] <barry> dbarth: is that a question? :)  does kenvandine need to approve it, or should i go ahead and give you a silo?
[20:28] <slangasek> cjwatson: so I think I would be ok with having mir binaries removed, and not dropping arm64 from the list, but then we still need to deal with the revdeps, and I think architecture exclusion is the right way to do that unless upstream is willing to support mir on arm64
[20:28] <dbarth> barry: gimme, i'll make a deal with kenvandine
[20:29] <barry> dbarth: okie dokie!
[20:29] <dbarth> barry: i just know i need to rebuild tomorrow morning
[20:29] <cjwatson> slangasek: those revdeps should just build-depend on the appropriate things so that they'll harmlessly dep-wait if mir isn't up and running
[20:29] <cjwatson> slangasek: we can just remove those binaries too for now - we don't need to change the packaging
[20:30] <barry> dbarth: i'm going to ignore the conflict on unity-webapps-qml: https://ci-train.ubuntu.com/job/prepare-silo/2697/console
[20:30] <cjwatson> mir has built on arm64, and it was using the mesa frontend so I dispute that it is a fundamentally horribly architecture-dependent thing
[20:30] <cjwatson> slangasek: I'm fairly sure most of those rdeps didn't build at all until I first got mir/arm64 building, but would be happy to be corrected in detail
[20:31] <slangasek> cjwatson: the revdeps are things that need to build a subset of functionality on non-mir archs; e.g., we shouldn't not build glmark2-es2 on arm64 due to a lack of mir
[20:31] <camako> problem is when the developers don't have easy access to this arch to fix bugs, I don't think this should be on the supported list of archs... It's an oversight on our part.
[20:31] <slangasek> cjwatson: the list of affected revdeps that I saw was glmark2, gtk+3.0, trust-store, ubuntu-system-settings-online-accounts
[20:32] <cjwatson> camako: it would have been nice if people had said that when I was apparently wasting my time doing the porting work
[20:32] <cjwatson> I'm quite annoyed by that
[20:32] <dbarth> barry: only webbrowser-app conflicts afaict
[20:32] <barry> dbarth: yep, that's it
[20:32] <cjwatson> camako: given that I was looking ahead to the entirely plausible future involving arm64 phones
[20:33] <camako> cjwatson, I see the good intention on your part. Yeah arm64 is pretty close..
[20:34] <cjwatson> slangasek: ok, I can certainly see that those would need to be adjusted; though ideally we might come up with some hack that uses mir if it exists in the archive for a given architecture and not if it doesn't ...
[20:34] <cjwatson> it's pretty terrible to have to go around hardcoding this
[20:35] <cjwatson> SharedLibraryProber, huh?  That test doesn't sound difficult to fix from a porter box
[20:36] <slangasek> "From a porter box" - but we don't have one of those today
[20:36] <camako> cjwatson, someone is already testing a fix as we speak... that's not the point... It's that we would have to commit the fix and rebuild in a sync silo..
[20:36] <camako> we are doing it in sbuild/emulator
[20:36] <cjwatson> camako: wouldn't have to sync this to rtm just yet
[20:36] <camako> this was an rtm->utopic sync, so rtm was in proposed
[20:36] <cjwatson> camako: and I'm afraid I don't see the horribleness of having to upload a fix :)
[20:37] <cjwatson> camako: so we upload a newer version to utopic
[20:37] <cjwatson> that is not a big deal
[20:37] <camako> cjwatson, that woulda caused a fork on our side which we don't wanna do... mir is changing quite a bit daily
[20:37] <cjwatson> it's not a fork, you're just running utopic a little ahead
[20:38] <cjwatson> I'm sorry but nobody had a problem with this kind of thing before citrain!
[20:38] <camako> plus, since this was a sync silo I don't even know that was possible
[20:38] <cjwatson> all you'd be doing is taking an extra revision on top
[20:38] <cjwatson> you've already given up the silo
[20:38] <cjwatson> any synciness of the previous silo is no longer relevant
[20:39] <camako> cjwatson, so the mir in rtm-proposed can still be promoted?
[20:39] <cjwatson> all we need to do is to get something into utopic that has the new package names
[20:39] <cjwatson> build ubuntu-touch-meta
[20:39] <cjwatson> sync it
[20:39] <cjwatson> done
[20:39] <cjwatson> it is fine if it's a bit ahead of rtm
[20:39] <camako> cjwatson, that's what we are gonna do then
[20:40] <cjwatson> slangasek: we had am1 and am2 for ages; not proper porter boxes but often usable as such.  are they perma-dead?
[20:41] <cjwatson> dbarth: those builds in rtm silo 2 are looking better
[20:41] <cjwatson> dbarth: just give me a shout when you finish with that silo so that I can put it back in its canonical configuration
[20:42] <camako> cjwatson, what if someone else builds against mir in rtm silo (like qtmir)? won't they be picking up the rtm-proposed qtmir?
[20:42] <cjwatson> camako: we can do the same thing for them that I just did for dbarth
[20:43] <camako> kgunn ^^
[20:43] <cjwatson> PPAs have a config option for whether they build against -proposed or not
[20:43] <camako> ok
[20:43] <dbarth> cjwatson: hopefully yes; alex-abreu is going to test them next this evening; will ping back tomorrow
[20:43] <cjwatson> silos have it on by default because otherwise library transitions are impossible, but we can switch it off on request
[20:44] <cjwatson> camako: ok, so I've remembered how to get at real arm64 hardware if you need it
[20:44] <cjwatson> camako: send me a patch and I can possibly test it faster
[20:45] <Ursinha> sergiusens: so the part of citrain that watches the ppa and returns the build script isn't really considering the sources you specified, I wonder if that ever worked without failing
[20:45] <camako> cjwatson, there are other things in the silo though (qtmir, u-s-c, papi).. I am just not sure if this won't cause problems..
[20:45] <cjwatson> camako: they will build against the PPA itself
[20:45] <Ursinha> sergiusens: I mean, if that ever worked when there was a package failed to build in the ppa
[20:45] <cjwatson> that's basically always wanted
[20:45] <camako> I mean in the rtm-proposed..
[20:46] <cjwatson> camako: I'm sorry but you're going to have to make this concern rather more concrete for me before I can understand it
[20:46] <alex-abreu> barry, could you help reconfi silo rtm 009 ?
[20:47] <barry> alex-abreu: sure
[20:47] <camako> cjwatson, I have 4 packages in rtm-proposed... and I need to get those 4 on a utopic silo... and then land them on utopic... before rtm can be promoted.. In the meantime others may be landing things on those projects.
[20:47] <cjwatson> camako: they'll build in other silos
[20:48] <cjwatson> camako: oh you mean inter-silo conflicts in ubuntu?
[20:48] <cjwatson> camako: we'll just have to get this done first and everyone else will have to rebuild; I don't see a way around that
[20:49] <camako> cjwatson, ok we''ll get a utopic silo with a fix and no rtm sync silo this time... and then build and land and then rtm-propsed can get unblocked
[20:49] <cjwatson> surely this is the inevitable consequence of failing to lock the components for ubuntu first :)
[20:50] <cjwatson> camako: do let me know if you need me to test this branch.  is it lp:~kdub/mir/fix-1379478 ?
[20:50] <alex-abreu> barry, oh I think I managed to do it myself
[20:50] <cjwatson> it's possible sbuild/qemu won't be up to the job
[20:50] <alex-abreu> I Haz The power
[20:50] <camako> cjwatson will do... lemme check
[20:50] <cjwatson> I have to go for some family time now though
[20:50] <cjwatson> back in an hour or two
[20:51] <camako> cjwatson, yep that's it
[20:51] <camako> cjwatson, thanks for your insight
[20:55] <Ursinha> sergiusens: robru says you should be able to publish even if the build job fails..
[20:55] <robru> sergiusens: just need to set ignore-step
[21:01] <Ursinha> sergiusens: that's a bug that got exposed by a recent refactoring we're making, should be easy to fix it making the script consider only the requested packages.. while it's not there just ignore_step and carry on
[21:08] <camako> cjwatson, this is the branch... You were right, it's failing for us on sbuild/emulator. Could you give it a try please? ---> lp:~kdub/mir/fix-1379478
[21:14] <slangasek> cjwatson: am1/am2 aren't perma-dead... one of them is in transit to become porter-arm64, the other is still available but horribly manual in its management.  "First get yourself VPN credentials, then talk to this guy in hyperscale" doesn't scale, hyper or otherwise, and I definitely don't think the mir team should be blocked on this
[21:15] <slangasek> cjwatson: (but if there's already a fix in flight now, then ignore me)
[21:16] <bfiller> barry: need a silo for line 91 when you can
[21:16] <barry> bfiller: ^^ :)
[21:16] <bfiller> you rock
[21:18] <slangasek> camako, cjwatson: grabbing lp:~kdub/mir/fix-1379478 to am2
[21:24] <balloons> fginther, will you be able to fix the xserver issue on core apps jenkins today? That calc mp needs to land
[21:28] <fginther> balloons, ack, I'll try to fix it now
[21:48] <cjwatson> slangasek: are you building it now?  I just got back and my chroot's upgraded now
[21:48] <slangasek> cjwatson: I'm happy to let you take it from there if you have an up-to-date chroot
[21:48] <cjwatson> I agree we need a porter box, obviously :-/
[21:49] <cjwatson> (or better, virt builders)
[21:50] <cjwatson> it's a dirty chroot but it should do the job
[21:57] <lool> ubuntu-qa, hey, I'm wondering whether you'd have an ETA for testing of rtm landing-005?
[21:59] <ToyKeeper> lool: There's a good chance it'll at least get started in the next 8 hours or so, but it's currently #3 in the queue and I'm mostly alone during this time zone.  If things go wrong with the other two, it might take longer (or could go faster).
[21:59] <lool> ToyKeeper: so ETA for QA pass is at best in my morning then
[22:00] <lool> ToyKeeper: so I should get to bed and look at the results tomorrow, thanks  :)
[22:00]  * lool waves
[22:02] <ToyKeeper> lool: Does it include links/info about the crashes it fixes, and about installing the custom tarball?  At a glance, those seem like the most likely hangups.
[22:05] <ToyKeeper> lool: Also, any idea if the trust-store packaging issue is likely to affect OTA updates?  If so, it probably shouldn't land without the packaging fix.
[22:06] <cjwatson> camako,slangasek: ok, building now
[22:06] <lool> ToyKeeper: yes
[22:07] <lool> ToyKeeper: packaging issue wont affect OTA upgrades
[22:07] <lool> ToyKeeper: only image builds
[22:07] <lool> or manual upgrades
[22:12] <veebers> barry: ping, how are you? I'm looking to get autopilot release with a critical fix (<-- balloons)
[22:19] <veebers> cihelp; perhaps I should ask you? ^^
[22:19] <Ursinha> veebers: maybe trainguards?
[22:21] <veebers> Ursinha: ah right, cheers /me should read the topic better :-)
[22:21] <veebers> trainguards: same question :-) ^^
[22:33] <Ursinha> :)
[22:40] <barry> veebers: oops, was getting some dinner.  what can i help you with?
[22:41] <veebers> hi barry, actually sorry false alarm on my part. Looks like I don't need to release right now :-)
[22:41] <barry> veebers: okay!  i'll be here for about another 30m
[22:43] <veebers> barry: ack thanks, sorry for the false alarm
[23:35] <cjwatson> camako,kgunn,slangasek: that branch builds cleanly on am2 (I also commented on the MP)
[23:39] <slangasek> \o/