[02:04] <imgbot> [03:34] <imgbot> [03:34] <imgbot> [06:43] <oSoMoN> hi all, what’s the status of the CI train, are we in traincon-0 as announced by Łukasz on Friday?
[07:26] <dbarth> good morning
[07:26] <dbarth> is it possible to get a silo for line 27?
[07:27] <dbarth> i ask because of traincon-0
[07:38] <dbarth> hi sil2100
[07:38] <sil2100> dbarth: hello!
[07:38] <dbarth> i was wondering a few minutes ago
[07:38] <dbarth> is it possible to get a silo for line 27?
[07:38] <dbarth> i ask because of traincon-0
[07:42] <sil2100> dbarth: just checked the spreadsheet and the problem with line 27 is that u-s-s is already locked by some silos...
[07:42] <sil2100> So assigning a silo there would mean that there would be even more confusion
[08:00] <dbarth> sil2100: ok, fixing those to let silo 13 land fully, that should unblock things on line 27 then
[08:09] <sil2100> dbarth: ok, thanks :)
[08:10] <sil2100> hm, test results are not bad, although gallery app seems to have caused regressions
[08:10] <sil2100> psivaa: hi! 2 questions: what's up with mantas? And could you re-run gallery-app to see if the failures are reproducible?
[08:11] <psivaa> sil2100: manta's: 2 of them were down. restarted them in the one available
[08:11] <psivaa> sil2100: i'll rerun the gallery app
[08:11] <sil2100> psivaa: thanks :)
[08:12] <psivaa> np :)
[08:15] <ogra_> sil2100, apart from no system-settings tests running anymore in the last image ... and apart from the constantly crashing mediascanner ... they look good apart from that, yeah :P
[08:17] <ogra_> oh, seems the missing system-settings were a dashboad glitch ... they just appered on reload
[08:17] <ogra_> bah
[08:17] <ogra_> i thought the new system-image was supposed to fix the crash with the logs !
[08:18] <ogra_> oh, wait, thats a completely new crash there
[08:19] <ogra_> yeah, new crash in system-image since 152
[08:20] <ogra_> (the "can not open logfile" one is gone now though ... somethng at least : ) )
[08:20] <ogra_> sil2100, ^^^^
[08:20] <sil2100> uh
[08:20] <sil2100> lalalalala
[08:21] <sil2100> I don't hear you
[08:21] <sil2100> lalalalaalala
[08:21] <ogra_> lol
[08:21] <sil2100> We just promote
[08:21] <sil2100> lalala
[08:21] <sil2100> ;)
[08:21]  * ogra_ goes ot make meeting coffee
[08:56] <sil2100> thostr_: hey! Are you the right manager to poke about mediascanner? :)
[08:57] <thostr_> sil2100: yes
[08:59] <davmor2> thostr_: it's very broken
[09:00] <thostr_> with the newest merge?
[09:00] <thostr_> we just tested it... :(
[09:00] <ogra_> since a few images ...
[09:00] <ogra_> 3-4
[09:00] <sil2100> thostr_: not sure what caused it, but if you look at the dashboard (or use the latest image) you will see mediascanner crashes everywhere :<
[09:00] <sil2100> thostr_: and it's causing no media, so you can't even listen to any music
[09:00] <thostr_> sil2100: link?
[09:01] <ogra_> so it started with image 150
[09:01] <sil2100> http://ci.ubuntu.com/smokeng/utopic/touch/mako/154:20140728:20140725.1/9323/ <- if you click on any test suite with a crash, you'll find mediascanner there
[09:01] <ogra_> the new mediascanner landed in 149 though ...
[09:01] <sil2100> thostr_: even in notes-app, which doesn't seem to use media at all!
[09:02] <ogra_> there must be something transitional in image 150 that causes the crashes
[09:02] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/150.changes
[09:02] <thostr_> sil2100: will take care
[09:02]  * ogra_ puts his bets on url-dispatcher or unity8
[09:03] <sil2100> http://people.canonical.com/~lzemczak/landing-team/150.commitlog <- yeah, url-dispatcher might indeed be the thing responsible
[09:03] <sil2100> But...
[09:03] <davmor2> ogra_: url-dispatcher it has a crash on my system on every fresh install
[09:03] <sil2100> Not sure why it would crash even for test suites that don't use media
[09:04] <davmor2> sil2100: can't you add images to notes
[09:04] <davmor2> sil2100: I'm sure you could copy an image to them
[09:05] <sil2100> Oh, you can do that?
[09:05]  * sil2100 checkes
[09:05] <sil2100> That would be neet
[09:05]  * ogra_ wouldnt know how 
[09:05] <sil2100> *neat
[09:06] <ogra_> i cant ... and actually if i hold my thumb on the note while it is in editing mode i see the copy/paste disalog being cut off completely (i can only see the top few pixels)
[09:08] <mhr3> sil2100, is anyone looking at the actual errors even?
[09:08] <mhr3> terminate called after throwing an instance of 'std::runtime_error'
[09:08] <mhr3>   what():  Could not look up user name: Permission denied
[09:08] <mhr3> mediascanner ^
[09:08] <ogra_> how does it look up the user name ?
[09:09]  * ogra_ hopes not by opening /etc/passwd
[09:09] <ogra_> (since it doesnt live there anymore)
[09:10] <ogra_> mterry, ^^^^
[09:10] <mterry> ogra_, odd...  anything going through nss would find the right spot...
[09:10] <ogra_> well it probably doesnt go through nss
[09:10]  * ogra_ doesnt know the code)
[09:10] <mterry> ogra_, I would expect so (like anything that does getpwnam would)
[09:11] <ogra_> right, doe it use that ?
[09:11] <ogra_> :)
[09:11] <ogra_> *does
[09:11] <mterry> ogra_, who parses passwd manually!?  :)
[09:12]  * mterry looks at mediascanner source
[09:13] <ogra_> http://paste.ubuntu.com/7883030/
[09:13] <davmor2> ogra_: oh so it's your fault that mediascanner doesn't work ;)
[09:13] <ogra_> in src/daemon/scannerdaemon.cc
[09:13] <mterry> lp:mediascanner is ancient...
[09:14] <mterry> ogra_, what's the branch?
[09:14] <ogra_> i used lp:mediascanner2
[09:14] <ogra_> i wonder if geteuid() is the issue there
[09:15] <davmor2> ogra_: could be I know it check who owns the videos and music and only displays those owned by the current user
[09:16] <ogra_> davmor2, right, and geteuid (vs just getuid) might behave differently towards nss
[09:16] <ogra_> mterry, ^^
[09:16] <mterry> ogra_, permissions on files looks fine...
[09:17] <ogra_> err
[09:17] <ogra_> lol
[09:17] <mterry> ogra_, ?
[09:18] <ogra_> ah, sorry, i thought i had fornd something ... i was wrong
[09:18] <ogra_> *found
[09:18] <mterry> bummer
[09:19] <ogra_> so according to the manpage getpwuid properly uses nsswitch.conf
[09:19] <ogra_> i see no mention of that in geteuid
[09:20] <ogra_> (nor in getuid though)
[09:21] <mterry> ogra_, in python, I can do pwd.getpwuid(os.getuid()) just fine
[09:21] <mterry> And same with euid
[09:21] <ogra_> does it have an equivalent to geteuid
[09:21] <ogra_> ?
[09:21] <ogra_> ah, k
[09:21] <ogra_> hmm
[09:22] <mhr3> perhaps there's something missing in the apparmor profile?
[09:22] <mterry> ogra_, I'm expecting that for mediascanner2, geteuid returns the same as getuid, right?
[09:22] <ogra_> it should
[09:22] <ogra_> the effective uid and the uid should be the same
[09:23] <mterry> mhr3, there was an apparmor fix to allow access to /var/lib/extrausers files...  But that should have already landed I thought
[09:23]  * mterry double checks
[09:23] <mhr3> mterry, suppose it didn't land to mediascanner's profile?
[09:24] <mterry> mhr3, ogra_: or it looks like it didn't land yet...
[09:24] <mterry> I was told it would land shortly
[09:24] <mterry> a while ago
[09:24] <mterry> jdstrand, do you remember we talked about adding apparmor allowances for /var/lib/extrausers/{group,passwd}?
[09:28] <bzoltan> sil2100: May I ask for a silot to the line29?
[09:29] <sil2100> bzoltan: sure, assigning
[09:30] <sil2100> thostr_: oh, while we're at it... landing-017, I see it's a bugfixing branch, but are those isolated bugfixes? Are there any risky changes? Any new features?
[09:31] <thostr_> sil2100 mostly bug fixes
[09:32] <thostr_> one api addition to return artist which is needed for local music scope
[09:32] <thostr_> tested and independent of the other issue you pointed out... which is permission problem
[09:43] <ogra_> [ 1004.223602] type=1400 audit(1406540577.399:167): apparmor="DENIED" operation="open" profile="/usr/bin/mediascanner-service-2.0" name="/var/lib/extrausers/passwd" pid=8205 comm="mediascanner-se" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[09:43] <ogra_> [ 1005.025909] type=1400 audit(1406540578.190:168): apparmor="DENIED" operation="open" profile="/usr/bin/mediascanner-service-2.0" name="/var/lib/extrausers/passwd" pid=8211 comm="mediascanner-se" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
[09:43] <ogra_> mterry, there we go ^^^
[09:43] <ogra_> definitely apparmor then
[09:43] <ogra_> sil2100, ^^^
[09:43] <mterry> ogra_, yeah makes sense without the apparmor patch
[09:44] <ogra_> well, i'm surprised the function actually opens the file ... i thought that was more abstracted
[09:44] <mterry> ogra_, also we can't seem to write to /var/lib/extrausers files with the file-bindmounts
[09:45] <ogra_> hmm, you should ... you cant write to the dir though
[09:45] <mterry> ogra_, like cached somewhere in the kernel?
[09:45] <mterry> ogra_, well I'm sure we could write, but I mean the tools refuse to
[09:45] <ogra_> or via libc somehow ... dunno :)
[09:46] <ogra_> mterry, well, a boot hook and making the whole dir writable again should fix that
[09:46] <mterry> ogra_, maybe it's intentionally so dynamic to allow for backends that change often
[09:47] <mterry> And that don't emit 'i changed' signals like /etc/shadow would
[09:47] <mterry> That's something that nss is missing -- accountsservice listens to those files and had to be updated to also listen to extrausers files.  But if nss just said "passwd changed" that would be nice
[09:53] <davmor2> popey_: what's with the tail dude?
[09:53] <davmor2> popey_: can you confirm https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1349326 please
[09:53] <davmor2> sil2100: bug number 1 ^
[09:58] <popey> davmor2: confirmed
[10:00] <davmor2> popey: another confirm please, sil2100 this is a none blocker but I'm going through the list
[10:00] <cjwatson> sil2100: gallery-app seems OK on mako now?  I wanted to check whether I was safe to remove the libexiv2-12 dependencies from ubuntu-touch-meta yet, in order to unblock that transition
[10:00] <davmor2> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1349329
[10:00] <davmor2> ogra_: did you say that the previous reports had a bug already?
[10:01] <davmor2> ogra_: or just that bdmurray was aware of it?
[10:01] <ogra_> i know he is aware of it and would be surprised if there wasnt a bug open
[10:01] <cjwatson> sil2100: (since I see that the new click package has been approved in the store)
[10:01] <ogra_> but i dont know
[10:01] <davmor2> ogra_: ta
[10:09] <davmor2> sil2100: bug number 2 https://bugs.launchpad.net/ubuntu-website/+bug/1349332
[10:09] <davmor2> I've added the 3 projects to it I don't care who fixes it ;)
[10:11] <camako> Edges intro cannot be disabled in recent images. Is this a known problem? This is causing Mir test runner issues...
[10:11] <camako> sil2100 ^^
[10:13] <davmor2> dbarth: ^ that bug might be of interest to your team, apparently popey has confirmed that the link opens on the desktop but it does take a while, but it never seems to render on the phone at all it may eventually.
[10:18] <davmor2> sil2100: bug 3 https://bugs.launchpad.net/messaging-app/+bug/1349342
[10:19] <davmor2> Saviq: is it unity8 that I file the power dialog against or is there a specific project?
[10:21] <davmor2> popey: ^ another cofirmation on that one if you would be so kind please
[10:22] <Saviq> davmor2, u8
[10:22] <davmor2> Saviq: thanks
[10:22] <Saviq> davmor2, did you maybe find some steps to repro?
[10:23] <dbarth> davmor2: ah ok, let me read
[10:25] <davmor2> Saviq: no, for me it just seems to appear if you leave the phone to auto sleep, leave it for a minute, then tap the power button and wait on the welcome screen But I'm running some tests now to see if that is reproducible, but it is happening more often than not here
[10:41] <davmor2> Saviq, sil2100: these steps seem to work quite well for me https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349362
[10:42] <davmor2> Saviq: I've noticed that it doesn't always appear immediately on wake but if you leave it on the welcome screen then it appears more reliably
[10:42] <Saviq> davmor2, thanks, that's very useful
[10:48] <popey> davmor2: confirmed the keyboard one
[10:48] <popey> also added screenshots
[10:48] <davmor2> popey: thanks
[10:48] <davmor2> I was just trying to get them all filed initially :)
[10:49]  * mvo_ is off to lunch and then trainguard afterwards
[10:58] <Saviq> davmor2, I wonder, though, I can't reproduce on qtcomp (silo 6), think you could have a try?
[10:59] <Saviq> install instructions in https://wiki.ubuntu.com/Unity8/QtComp (dist-upgrade will fail due to missing ubuntu-touch update)
[10:59] <davmor2> Saviq: I'll give it a go in a minute.  Let me just make sure I've filed all the bugs
[11:00] <ogra_> davmor2, i think your bug #3 shouldnt be against webbrowser but against the website instead
[11:00] <ogra_> haha
[11:00] <ogra_> indeed i meant bug #1349342
[11:00] <ogra_> grrr
[11:01] <ogra_> bug 1349332 then
[11:01] <ogra_> so number 2 instead :)
[11:01] <davmor2> ogra_: I added settings, web-browser and the site. To ensure all the teams that touched it were informed
[11:01] <ogra_> ah, k
[11:02] <davmor2> ogra_: but being as it is working on desktop (very slowly) and not on the phone as far as I can tell I'm assuming it is actually the browser hence pointing dbarth at it initially
[11:03] <ogra_> it probably exhasusts the memory :)
[11:04] <davmor2> ogra_: could well be but being as it is a legal requirement it might be a little important.  But to be honest I should just be an ubuntu page with text shouldn't be that bad even if there is a lot of text.
[11:05] <ogra_> yeah
[11:05] <ogra_> and i still think we should ship it on the device
[11:05] <davmor2> ogra_: agreed but would it fit if it makes the browser die ;)
[11:06] <ogra_> hehe, it might be a lot smaller if you ship it as a static page, who knoes
[11:06] <ogra_> *knows
[11:07] <davmor2> ogra_: of course then it needs to become a package and would need a system update if the data in it changes I quess that wouldn't be so good
[11:07] <ogra_> it should just be shipped as part of system-sttings
[11:09] <davmor2> ogra_: would you want to rebuild the whole of system setting for a line of text in a legal doc.  I would do a legal-devices-doc package and any docs that are required could be added to that package and then there is basically just a doc package to update
[11:10] <ogra_> well, it doesnt really matter since you need to build a complete image for it anyway
[11:10] <ogra_> no matter which of the packages you update for it
[11:10] <davmor2> ogra_: indeed
[11:12] <davmor2> popey: the messaging indicator message for an update can you trigger the settings app to open recently if you click on the top right cog for that now?
[11:19] <popey> davmor2: ah, i noticed that over thw eeekend
[11:19] <popey> davmor2: but I can't trigger it now because i have no updates
[11:19] <davmor2> popey: yeah same here so that got introduced at some point
[11:20] <popey> some time at the end of last week because I know I did use that earlier in the week
[11:21] <davmor2> popey: it worked friday I think to get to 150 so I'm assuming 151<
[11:21] <popey> sounds plausible
[11:26] <davmor2> ogra_: any idea of which package I would be looking at for that message?
[11:27] <ogra_> i would start with either system-image or indicator-messages
[11:27] <davmor2> ogra_: or is this another one that might be affected by the user password fix?
[11:27] <ogra_> no
[11:27] <ogra_> it didnt work before that change
[11:28] <ogra_> (i dont think it ever worked)
[11:28] <davmor2> ogra_: are you sure?  it was working but only if you clicked the cog in the top right after selecting the message
[11:28] <davmor2> ogra_: because that is so obvious, not!
[11:29] <popey> davmor2: want me to flash back to 149 to see?
[11:30] <davmor2> popey: if you have the time that would be great and then I can start looking at silo006 and see if fixes the power popup issue
[11:30] <popey> yeah, will flash back while lunch cooks
[11:38] <ogra_> popey, system-image got updated in 152
[11:39] <davmor2> ogra_: that might be the one then
[11:39] <davmor2> ogra_: that was saturday right?
[11:39] <ogra_> yeah
[11:39] <ogra_> landed late on friday
[11:39] <davmor2> ogra_: that would be about right then
[11:40] <ogra_> but there were also multiple system-settings since thu.
[11:52] <bzoltan> sil2100: does the TRAINCON-0 effect the desktop packages too?
[11:53] <ogra_> only if they touch touch
[11:53] <ogra_> :)
[11:57] <sil2100> bzoltan: yeah, only if we use any of them in touch images
[11:57] <bzoltan> ogra_: sil2100: The QtC plugin does not touch touch :)
[12:00] <popey> flashing to 149 is no good davmor2 ogra_ because I get no notification unless a new image appears, right?
[12:01] <ogra_> oh, yeah
[12:01] <ogra_> well
[12:01] <ogra_> there is a new image
[12:01] <popey> so will leave this on #149 until the next image comes up
[12:01] <ogra_> open system-settings once
[12:01] <popey> ok
[12:01] <ogra_> i think that triggers it
[12:05] <popey> nah, i'm getting no notification, i suspect the trigger is somewhere else
[12:05] <popey> server side
[12:05] <davmor2> push notifications then I bet
[12:06] <ogra_> it works here
[12:06] <ogra_> weird, probably just a co-incidence
[12:08] <ogra_> i cant squeeze any info aout of system-settings about the crash :(
[12:08] <ogra_> nothing in any logs :(
[12:12] <ogra_> popey, oh, while you're on older images, can you also check when the crashing started ?
[12:13] <popey> which crash?
[12:13] <davmor2> ogra_: ^
[12:13] <popey> the os -> back -> somewhere else one?
[12:13] <ogra_> going back from os version to the about page and then tapping something with expander
[12:14] <ogra_> (i.e. storage or licenses)
[12:14] <popey> doesn't happen in 149
[12:14] <davmor2> ogra_: or developer mode
[12:14] <ogra_> davmor2, cant be, thats my chane ... my changes dont break things :P
[12:15] <ogra_> (because i also nevor typo ... )
[12:15] <ogra_> :P
[12:16] <davmor2> ogra_: no, no or going into developer mode after the os info crashes it too, it is any page that expands from settings app after going into os info page
[12:17] <ogra_> yeah, but *i* added that expander cant break on this one :P
[12:17] <sil2100> cjwatson: most probably you already know the answer, but the latest gallery-app seems to be fine - at least the one we got in the latest image
[12:18] <davmor2> blame ogra_ .com
[12:18] <ogra_> heh
[12:19] <ogra_> hmm, so if it breaks in 151 too its my fault ... if it only breaks in 152 it isnt
[12:19]  * ogra_ flashes 151 
[12:22] <sil2100> ogra_: wasn't 151 b0rken?
[12:22] <sil2100> Ah, it was only for updates
[12:22] <ogra_> sil2100, only for upgrades
[12:22] <ogra_> 151 and 152 both had system-settings changes
[12:30] <cjwatson> sil2100: I didn't, thanks, that's useful
[12:51] <ogra_> sigh ... seb128 so i suspect bug 1349326 is caused by my dev mode changes (i dont see why though ... and ken landed that together with https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/call_forwarding/+merge/227761) ...
[12:52] <ogra_> mandel, ^^^ ... any idea what could be wrong with my code that might cause this ? ....
[12:52] <ogra_> https://code.launchpad.net/~ogra/ubuntu-system-settings/developer-mode/+merge/227822 was the merge
[12:52] <seb128> ogra_, did you get a backtrace?
[12:53] <ogra_> not yet ...
[12:53] <ogra_> i first wanted to nail it down to the package version ... we had so many changes in system-settings recently
[12:57] <seb128> could also be Laney's changes (it's the other recent change to this panel iirc)
[13:00] <ogra_> seb128, these landed before 151
[13:00] <seb128> k, I don't know when your issue started
[13:00] <ogra_> 149 was fine ... i can repro it in 151
[13:00] <seb128> having a bt should be easy
[13:01] <seb128> that would also tell you more on the issue
[13:01] <ogra_> yeah, trying to get ddebs
[13:01] <ogra_> i suspect something isnt properly freed
[13:01] <ogra_> or some such
[13:01] <seb128> valgrind might be useful then
[13:04] <ogra_> Reading state information... Done
[13:04] <ogra_> E: Version '0.3+14.10.20140725.3-0ubuntu1' for 'ubuntu-system-settings-dbgsym' was not found
[13:04] <ogra_> sigh ...
[13:04] <ogra_> well, the newer one crashes too ...
[13:05]  * ogra_ installs that instead
[13:05] <seb128> ogra_, http://ddebs.ubuntu.com/pool/universe/u/ubuntu-system-settings/ubuntu-system-settings-dbgsym_0.3+14.10.20140725.3-0ubuntu1_armhf.ddeb
[13:05] <ogra_> seb128, well, already unpacking
[13:05] <seb128> k
[13:07] <davmor2> Saviq, sil2100, ogra_: good news install silo 006 couldn't reproduce the issue with the power dialog
[13:07] <Saviq> davmor2, ok cool, thought so, it changes input handling quite a lot
[13:08] <Saviq> davmor2, we'll still apply a safety hatch that I think would fix it on current stuff
[13:10] <davmor2> Saviq: Then why tempt me with silo 006 damn you ;) Your such a tease.....Look what this does......but you can't have it :D
[13:10] <Saviq> davmor2, huh? I meant either way, we're landing silo 6 today if I can help it, too
[13:11] <Saviq> davmor2, my previous sentence probably lacked "anyway"
[13:11] <davmor2> Saviq: traincon0 dude so it needs QA sign off :)  May as well stick with silo 006 :)
[13:11] <ogra_> seb128, hmm, i cant convince the app to continue under gdb
[13:12] <seb128> ogra_, just do "c" in gdb?
[13:12] <davmor2> Saviq: how close is is silo 006 I can carry on testing it if it is about to land
[13:12] <ogra_> yeah, doesnt make it go to the about page
[13:12] <Saviq> davmor2, well well, it does fix the issue, so it meets traincon 0 ;)
[13:12] <ogra_> oh
[13:12] <seb128> ogra_, can you interact with the ui at all then?
[13:12] <ogra_> no i cant and i just see there was a segfault i missed
[13:12] <sil2100> \o/
[13:13] <davmor2> Saviq: still requires QA sign off which I'm offering to do for you, if it is actually completed
[13:13] <Saviq> davmor2, oh yeah it needs QA sign of for sure
[13:14] <ogra_> seb128, http://paste.ubuntu.com/7884671/ thats all i get
[13:14] <Saviq> davmor2, but we need to land it in sequence (gotta NEW qtmir/-gles first)
[13:14] <Saviq> so waiting for Steve to show up
[13:14] <seb128> ogra_, not very useful :/
[13:14] <oSoMoN> sil2100, hey, can silo 5 be landed? it’s a truly minor and risk-free one, with no functional changes at all
[13:14] <ogra_> not at all
[13:14] <seb128> can you valgrind it?
[13:15] <sil2100> oSoMoN: ok, so those are rather isolated fixes?
[13:15] <sil2100> mvo_: ok, I'm publishing oSoMoN's and bzoltan silos now
[13:15] <oSoMoN> sil2100, yes
[13:15] <ogra_> seb128, hmm, dunno, how do i start something that runs under ubuntu-app-launch in valgrind mode ?
[13:15] <seb128> tedg, ^
[13:15] <bzoltan> sil2100: thanks
[13:16] <seb128> ogra_, you can valgrind system-settings --desktop-file_hint=/usr/share/...
[13:16] <seb128> I guess
[13:16] <mvo_> thanks sil2100
[13:16]  * ogra_ tries if he can :) 
[13:17] <davmor2> oSoMoN: I don't believe devs that say risk free ;)  Low risk I can handle :)
[13:17] <sil2100> mvo_: ok, so... could you maybe publish 005 instead ;) ? I requires a packaging ACK but the package is in main ;p So I can't publish it without a core-dev +1 anyway
[13:18] <oSoMoN> davmor2, heh, just assume that risk-free translates to low-risk in dev tongue, and we’re good :)
[13:19] <oSoMoN> sil2100, for info, the packaging change in 005 was submitted by mvo_ himself :)
[13:19] <sil2100> AH!
[13:19] <sil2100> hahah ;)
[13:19] <mvo_> make the ACK even easier :-D
[13:19] <sil2100> Now I see it, hah
[13:22] <ogra_> seb128, hmm, i cant even start it without valgrind ... there must be special magic to it
[13:22] <ogra_> phablet@ubuntu-phablet:~$ system-settings
[13:22] <ogra_> QUbuntu: Could not create application instance
[13:22] <ogra_> Aborted (core dumped)
[13:23] <mandel> ogra_, looking
[13:24] <ogra_> mandel, i suspect the bug is actually in the "os version"but, but my addition triggers it
[13:25] <mandel> ogra_, well, I'm sure it can be fixed :)
[13:25] <mandel> ogra_, I'll take care
[13:25] <ogra_> *the "os version"bit
[13:26] <mvo_> sil2100: fwiw, its published according to jenkins
[13:26] <sil2100> \o/
[13:26] <sil2100> mvo_: thanks :)
[13:26] <mvo_> yw
[13:26] <mvo_> I haven't seen anything from the bot yet though
[13:26] <ogra_> sil2100, are we publishing changes unrelated to ttraincon ?
[13:27] <sil2100> ogra_: yeah, traincon allows landing isolated bugfixes that don't include features and/or unrelated to touch
[13:27] <ogra_> after QA signoff, no ?
[13:27] <sil2100> ogra_: no, small isolated bugfixes do not require sign-off, only bigger ones (not isolated) and/or with features need sign-off
[13:27] <ogra_> (webbrowser-app is surely touching touch ... )
[13:28] <sil2100> Iiiit's complicated
[13:35] <Saviq> davmor2, so, if you have silo 6 installed, we'd gladly take QA testing
[13:35] <Saviq> I'm doing my own in the mean time
[13:35] <sil2100> hmmm
[13:36] <sil2100> Saviq: so, silo 006 fixes the power menu issue? Is there a chance for this to get fixed by a smaller upload first?
[13:36] <sil2100> Saviq: I know that 006 has been tested for long and might even have QA sign-off, but still... it's a big thing
[13:36] <Saviq> sil2100, there's a *chance* yes, but if possible we'd just go for silo 6 already
[13:37] <Saviq> I understand it's a huge change, but that's why we do so much testing, QA signoff etc.
[13:37] <seb128> ogra_, did you use the desktop_file_hint=/usr/share/applications/system-settings.desktop parameter to the command?
[13:37] <ogra_> seb128, yes
[13:37] <seb128> and it's not starting?
[13:37] <ogra_> even fails if i just run it without valgirnd
[13:37] <ogra_> right
[13:37] <sil2100> Would prefer to land an isolated fix, build an image, try promoting and then land 006 (we can land it even if we won't have a promotion)
[13:37] <seb128> ogra_, did you typo the parameter?
[13:38] <seb128> iirc it's --desktop_file_hint=/usr/share/applications/system-settings.desktop
[13:38] <ogra_> hablet@ubuntu-phablet:~$ system-settings --desktop-file_hint=/usr/share/applications/ubuntu-system-settings.desktop
[13:38] <ogra_> system-settings: unrecognized option '--desktop-file_hint=/usr/share/applications/ubuntu-system-settings.desktop'
[13:38] <ogra_> QUbuntu: Could not create application instance
[13:38] <ogra_> Aborted (core dumped)
[13:38] <mhr3> sil2100, silo for #30 pls? need those fixes for pes guys
[13:38] <ogra_> oh
[13:38] <seb128> ogra_, it's _ and not -
[13:38] <mhr3> mvo_, eh, ^^
[13:38] <ogra_> seb128, yeah, i copy/pasted from your question above :P
[13:39] <oSoMoN> sil2100, once silo 5 lands and is freed, I’m gonna need a silo for a huge webbrowser-app MR; I understand that it cannot land while we’re in traincon-0, but I’d need it today to allow for extensive testing
[13:39] <seb128> ogra_, I had the ... because I never remember the correct form and I was not giving the exact option
[13:39] <ogra_> heh
[13:39] <ogra_> works now
[13:39] <seb128> great
[13:39] <mvo_> mhr3: those are self-contained fixes and all that? we are in traincon so I can only land save stuff
[13:40] <ogra_> geeez, thats slooooow
[13:41] <sil2100> mvo_: remember that silo assignment can still be done normally, just usually leave 1-2 free silos in case some blocker fixes are needed :)
[13:41] <mhr3> mvo_, things those branches fix aren't used yet in the official images, so kinda safe
[13:41] <mhr3> mvo_, we'll test it anyway of course
[13:42] <mvo_> mhr3: thanks, I assign
[13:42] <mvo_> sil2100: ok, will do
[13:42] <sil2100> oSoMoN: ok, we'll try to have a silo for you, but since we're in traincon-0 we can soon be low on silos
[13:43] <oSoMoN> sil2100, understood
[13:43] <oSoMoN> sil2100, I filed the landing request on line 32
[13:47] <ogra_> seb128, mandel http://paste.ubuntu.com/7884925/ ...
[13:47] <ogra_> so it crashes somewhere in a dbus access it seems
[13:48] <seb128> do you have the full log?
[13:48] <seb128> especially invalid read/write before?
[13:48] <seb128> or free
[13:48] <ogra_> sure ... let me upload that somewhere
[13:48] <seb128> thanks
[13:48] <mandel> ogra_, sweet, I should be able to fin the reason with full logs
[13:49] <ogra_> oh man
[13:49] <ogra_> ==4768== More than 1000 different errors detected.  I'm not reporting any more.
[13:49] <ogra_> ==4768== Final error counts will be inaccurate.  Go fix your program!
[13:49] <ogra_> valgrind is a moaner !!!
[13:49] <seb128> lot of false positive likely
[13:49] <seb128> you have suppr files to clean those
[13:54] <ogra_> seb128, mandel http://people.canonical.com/~ogra/ubuntu-touch/valgrind.log
[13:56] <seb128> ogra_,
[13:56] <seb128> ==4768== Invalid write of size 4
[13:56] <seb128> ==4768==    at 0xDACE682: ???
[13:56] <seb128> can you look in maps from settings what is at this address?
[13:56] <ogra_> how, where ?
[13:57] <seb128> in /proc/`pidof system-settings/maps
[13:57] <seb128> or in the apport-unpack dir
[13:58] <seb128> ogra_, did the android, hybris, etc stuff changed?
[13:58] <seb128> those bts and logs and errors are a bit weird
[13:58] <ogra_> a few times recently, yeah
[13:58] <seb128> like errors in ld
[13:59] <ogra_> oh, in fact it changed in image 150
[13:59] <seb128> if you take 149 and upgrade settings, does it bug?
[13:59] <seb128> it seems more likely a bug in the android side than in settings to me
[13:59] <ogra_> thats another 30min for me to download 149 first
[14:00] <ogra_> (i am on 151 here, popey  tested 149)
[14:01] <ogra_> but yeah, i guerr i need to invest that time
[14:01]  * ogra_ re-flashes ... time for a break then ... (sometimes i like my slow  DSL :P )
[14:02] <mhr3> seb128, it's fine if i just directly push to trunk when trunk is not synced with distro, right?
[14:02] <seb128> mhr3, yes
[14:02] <seb128> well, you push the diff of what got uploaded in distro, right?
[14:02] <ogra_> bah
[14:02] <ogra_> danmed .. i had 149 downloaded already ...
[14:02] <mhr3> seb128, yea, that
[14:02] <ogra_> no break :P
[14:03] <seb128> mhr3, k, it's fine yes
[14:31] <camako> fginther, just FYI, the failures we've seen on mir/0.5 are due to welcome screen not being disabled by the test runner script... I guess smth else did it for mir/devel so we got away with it, but not on 0.5. Testing my fix now...
[14:32] <fginther> camako, is that a fix for the test runner script?
[14:32] <camako> fginther yes
[14:35] <ogra_> seb128_, FYI no change when upgrading the app on 149 ... same crash
[14:35] <seb128_> ogra_, so it's settings?!
[14:35] <ogra_> yes
[14:36] <ogra_> i dont get why my code addition onl ymakes bugs in other elements manifest
[14:36] <balloons> fginther, were you able to run reminders now in the dashboard?
[14:37] <balloons> I'm hoping we can land your branch and get reminders into the dashboard testing
[14:38] <fginther> balloons, sorry. I ran into problem testing this on Friday and haven't had a good run yet
[14:38] <fginther> balloons, I'll try again today. I should have the problems resolved now as long as the latest image still works
[14:39] <balloons> fginther, awesome.. just keep me informed ;-)
[14:56] <Saviq> rsalveti, that failure looks like some intermittent UITK issue
[14:57] <Saviq> rsalveti, PageHeadStyle and below is UITK
[14:57] <Saviq> t1mp, any idea https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349444 ?
[14:59] <cjwatson> Can I upload ubuntu-touch-meta to drop the libexiv2-12 dep?
[15:00] <cjwatson> And I guess for the udisks2 change
[15:00] <cjwatson> Oh, haha, rsalveti already did
[15:10] <davmor2> seb128: hey dude the system setting crash says it has been uploaded I'm assuming to errors.ubuntu.com
[15:10] <seb128> davmor2, hey, guess so?
[15:11]  * ogra_ wonders if that will have more info than the valgrind run
[15:26] <kalikiana> fginther: ping
[15:26] <kgunn> sil2100: so, not sure i've ever been here...but if we've got a blocker fix, can we land ?
[15:27] <kgunn> in traincon0
[15:27] <fginther> kalikiana, pong
[15:27] <kgunn> i mean i assume thats how its supposed to work
[15:27] <sil2100> kgunn: sure! :) If it's a blocker fix, then you're first in the queue!
[15:27] <kgunn> sil2100: ok, silo6 will fix bug 1349362
[15:28] <sil2100> kgunn: ah ;)
[15:28] <kgunn> sil2100: i think we just need to do one last sanity test on that silo
[15:28] <kgunn> we'll mark as tested as soon as done
[15:28] <sil2100> kgunn: ok, so regarding this - we're thinking, and most probably will, whitelist this blocker as per some discussions we had
[15:28] <sil2100> kgunn: since we know it's fixed in 006 and it's not something that breaks your phone
[15:29] <kalikiana> fginther: can you help me enable ci on lp:ubuntu-push-qml including Jenkins running on MRs? it's a new branch with QML bindings for lp:ubuntu-push; I'm in the process of adding test cases (the ones in the branch are empty shells)
[15:29] <kgunn> sil2100: ah ah ah...already marked blocker, no take backs :)
[15:29] <sil2100> ;)
[15:32] <fginther> kalikiana, sure, but in the future please ping the Vanguard for general help (I'm not always here)
[15:34] <oSoMoN> sil2100, how often is the check-publication-migration job run?
[15:36] <davmor2> oSoMoN: once a decade did you want it quicker than that?
[15:36] <sil2100> oSoMoN: let me check
[15:36] <bfiller> popey: do you know if the gallery-app I uploaded this weekend got approved yet in the store?
[15:37] <oSoMoN> davmor2,  :)
[15:37] <bfiller> sil2100: I need a silo for line 33 please when you have a chance
[15:37] <popey> bfiller: should be, image 154 has a new gallery app http://people.canonical.com/~ogra/touch-image-stats/154.changes click:com.ubuntu.gallery from 2.9.1.1009 to 2.9.1.1025
[15:37] <sil2100> oSoMoN: every 5 minutes, but... it seems robru's redeployment on Friday broke it I see
[15:38] <bfiller> popey: great thanks!
[15:38] <sil2100> oSoMoN: as he redeployed with latest, untested changes, and I guess it stayed there...
[15:38] <sil2100> So I see it's failing since some time
[15:38] <sil2100> *sighs*
[15:38] <bfiller> cjwatson: updated gallery landed in image, so next steps can proceed now..
[15:38] <kalikiana> fginther: okay. sorry about that
[15:39] <popey> bfiller: np
[15:39] <sil2100> oSoMoN: yeah, it seems he didn't revert everything correctly
[15:39] <camako> fginther, so I checked in a fix for the 0.5 CI problem and it works... Also now we are getting ready to branch 0.6... Can you set up the jenkins config for 0.6 plz? Note that we don't have the branch yet.
[15:41] <sil2100> Jeez... his redeployment caused so much chaos
[15:41] <oSoMoN> sil2100, ok, I was asking because the status silo 5 still says that packages are in proposed, but they have already been promoted to the release pocket a while ago, would it be safe to merge and clean now, or do I need to wait for check-publication-migration to run again?
[15:42] <sil2100> oSoMoN: yeah, that's exactly where the check-publication is failing :| Give me a few seconds and I'll fix it
[15:42] <oSoMoN> ok
[15:42] <bzoltan1> rsalveti: ping
[15:42] <rsalveti> bzoltan1: pong
[15:43] <bzoltan1> rsalveti:  would you please help me to release the uitk-gles?
[15:43] <rsalveti> bzoltan1: oh, they are not in sync
[15:43] <rsalveti> bzoltan1: let me check that
[15:44] <bzoltan1> rsalveti: they are horrible out of sync and I am sure that is the reason of this https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349444
[15:44] <sil2100> oSoMoN: ok, it should be good now
[15:45] <oSoMoN> sil2100, excellent, thanks!
[15:45] <sil2100> oSoMoN: sorry for that, and thanks for noticing it!
[15:48]  * ogra_ wonders why the missing -gles rebuilds would have impact only starting with 152
[15:50] <rsalveti> mako 149
[15:50] <rsalveti> the build id is not in sync
[15:50] <ogra_> oh
[15:51] <ogra_> yeah then that matches
[15:53] <sil2100> hmmm
[15:53] <sil2100> rsalveti: so, the reason are missing -gles rebuilds during UITK landing?
[15:53] <rsalveti> could be, I'm syncing them as we speak
[15:53] <sil2100> But I made a check that's actually making sure it's not released without it
[15:53] <ogra_> the "suspected" reason :)
[15:54] <sil2100> Did someone skip that ;p?!
[15:54] <ogra_> i think i saw a discussion about skipping it
[15:54] <sil2100> !
[15:54] <sil2100> BAD BAD BAD
[15:54] <rsalveti> bzoltan1: ^^^
[15:54] <rsalveti> :P
[15:55] <sil2100> bzoltan1: did you guys skip the -gles 'twin' counter-part upload during UITK landing? ;)
[15:55] <bzoltan1> sil2100: errr...
[15:55] <ogra_> -queuebot/#ubuntu-ci-eng- Silos: landing-015 (bfiller) Can't build: Some projects are missing their 'twin package' uploads (e.g. their -gles counter-parts): ubuntu-ui-toolkit-gles. (address-book-app, dialer-app, messaging-app, ubuntu-keyboard, ubuntu-ui-toolkit)
 I guess I can ignore that for now as it was ignored in the last (failed) build pass
[15:55] <ogra_> seems that was colin
[15:55] <sil2100> Ah ha!
[15:55]  * bzoltan1 is thinking about a goo lie 
[15:55] <ogra_> ah, dang ... i should have waited to hear the good lie first
[15:57] <bzoltan1> ogra_:  I go with the sunspot activity
[15:57] <Chipaca> who can unstick the ps jenkins bot? got a needs fixing because of a missing commit message, and now i'm stuck with it
[15:59] <rsalveti> sil2100: bzoltan1: https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit-gles/0.1.50+14.10.20140724.2-0ubuntu1
[15:59] <rsalveti> quite a big diff
[15:59] <rsalveti> should probably be what is causing the issue
[15:59] <sil2100> Most probably
[15:59]  * sil2100 waits for it to finish building
[16:00] <sil2100> Anyway, we can build an image in the meantime I guess, as these bits anyway don't land in touch images
[16:00] <sil2100> And we're almost sure that it's nothing on our side breaking it
[16:00] <bzoltan1> rsalveti: the diff suppose to be big
[16:01] <rsalveti> wait for the gles packages to land first
[16:01] <rsalveti> otherwise the emulator image will still be broken
[16:01] <elopio> sil2100: I have another meeting right now, and brendan is on holidays. So please ping me if you need something from us.
[16:01] <sil2100> elopio: ok :)
[16:02] <Chipaca> any chance of me getting a silo for row 35?
[16:03] <Chipaca> ah, i guess there are more outstanding than silos available. sigh.
[16:03] <bzoltan1> rsalveti: sil2100: ogra_: keep in mind that the UITK or any other projects have _ZERO_ autopilot tests run against the emulator
[16:04] <ogra_> autopilot is overrated anyway
[16:04]  * ogra_ hides from QA 
[16:06] <balloons> oO
[16:07] <Chipaca> ogra_: while you're hiding, ... :)
[16:11] <cjwatson> bfiller: Yep, next steps are in progress, thanks
[16:12] <rsalveti> bzoltan1: sil2100: built successfully at least, wait it to be published and trigger a new image
[16:12] <cjwatson> ogra_: well, yeah, I figured I was just transferring the previous instruction
[16:12] <cjwatson> that check should be applied on publish, not just on build
[16:12] <cjwatson> I didn't realise it wasn't
[16:13] <ogra_> if it notifys yu on build you dont lose time and can start the other build in parallel
[16:13] <ogra_> but yeah it should block publishing additionally
[16:13] <ogra_> sil2100, ^^^
[16:13] <cjwatson> ogra_,sil2100: Saviq ignored it before I did - https://ci-train.ubuntu.com/job/landing-015-1-build/111/console
[16:14] <ogra_> yeah
[16:14] <ogra_> i dont want to point fingers and we obviously have a flaw in the infrastructure here
[16:15] <cjwatson> Yup, not pointing fingers, just suggesting whom to check with for more detailed history :)
[16:15] <oSoMoN> sil2100, now that silo 5 landed, can I have a silo for line 32, please?
[16:16] <ogra_> you are aware that we are in traincon-0 ?
[16:16] <ogra_> (only bugfixes and only after QA review, no ? )
[16:17] <mterry> sil2100, did everything get tested / squared away about the mediascanner2 fix?
[16:17] <ogra_> mterry, we'll build an image asap
[16:17] <t1mp> Saviq: PageHeadSections was added last week
[16:17] <ogra_> (with that fix)
[16:17] <mterry> ogra_, cool!
[16:17] <mterry> thanks
[16:17] <t1mp> Saviq: are you using import Ubuntu.Components 1.1?
[16:17] <ogra_> that still leves two other issues though
[16:21] <Saviq> t1mp, yeah, and it's obviously working outside of the emulator...
[16:22] <bzoltan1> rsalveti: thank you
[16:22] <t1mp> Saviq: I added a new comment for the bug, PageHeadSections is in the Components (not the Theme as I said first)
[16:22] <Saviq> t1mp, hmm, sounds like -gles UITK package isn't there?
[16:23] <t1mp> uhhmm.. I don't know about the -gles package
[16:23] <t1mp> bzoltan1: ^^ you were busy with that last week right?
[16:23] <Saviq> rsalveti, right, I can see you just published uitk, it will fix unity8 on emulator
[16:24] <rsalveti> hopefully, yeah
[16:25] <Saviq> cjwatson, right, I did ignore it for that silo (as you effectively *have* to ignore it once, to build from the same source), but I completely agree that check should be there on publish (and it should check the version of the two packages)
[16:25] <Saviq> (to be in sync)
[16:26] <Saviq> at least the part before -ubuntu
[16:26] <sil2100> Oh, and firefox crashed, lovely
[16:28] <davmor2> sil2100: oh the policy things it appears that the webbrower fails to render it which is why it isn't visible on the device so that needs fixing :)
[16:30] <bzoltan1> t1mp: Saviq: the problem is addressed by rsalveti and the fix is on its way.
[16:30] <t1mp> rsalveti, bzoltan1 awesome :)
[16:30] <ogra_> already uploaded any building
[16:30] <Saviq> bzoltan1, yup, saw that, no comment on the bug though! ;P
[16:30] <ogra_> it is one of the traincon-0 issues
[16:30] <bzoltan1> t1mp:  not so awesome if you ask sil2100 or ogra_ :D
[16:31] <Saviq> sil2100, I have to launch a private window before launching a real one in my firefox for a few weeks now
[16:31] <ogra_> bzoltan1, hey, it made us find a flaw in the process ... sil2100 just needs to fix it now :)
[16:31] <rsalveti> didn't yet comment on the bug because we don't yet know if that fixed or not the issue
[16:31] <Saviq> rsalveti, well, at least we'd know something's happening ;)
[16:31] <rsalveti> we hope it'll fix it
[16:32] <rsalveti> Saviq: right, my bad, added something now
[16:33] <bzoltan1> ogra_:  well... at least I would be the first one complaining about a non functional emulator image :)
[16:34] <robru> sil2100, ah indeed, prepare-silo is hard-coding spreadsheet columns. Fortunately, queuebot and prepare-silo are both python and both using csv, so it should be simple to adapt my queuebot code to make prepare-silo adaptable. I'll submit a branch for that shortly.
[16:45] <sil2100> robru: \o/
[16:53] <robru> sil2100, ok https://code.launchpad.net/~robru/cupstream2distro/stop-hardcoding-spreadsheet-column-numbers/+merge/228540 I'll deploy this now and see how it goes ;-)
[16:53] <sil2100> Wait!
[16:53] <sil2100> I'm redeploying the deploy job now
[16:53] <robru> lol
[16:53] <sil2100> And it's having some problems o_O
[16:54] <sil2100> I mean, redeploying the redeploy ;p
[16:54] <sil2100> ugh
[16:54] <robru> sil2100, yes that looks like a fun failure.
[16:54] <davmor2> sil2100: you're redeploying the redploy of the deploy job
[16:55] <robru> davmor2, this redeploy of the redeploy of the redeploy job is just a ploy! and boy is my face red...
[16:57] <ogra_> sil2100, we should also avoid seed changes (or at least the accompanying meta uploads for them) during TRAINCON ... take that on your suggestion list too
[16:58] <robru> sil2100, hey what's the deal with your redeploy change? my change should be orthogonal, if I just slip that in it won't hurt you will it?
[16:58] <sil2100> robru: I think yes, I guess it's just a problem with authorization in jenkins o_O
[16:58] <robru> sil2100, ok, gimme a sec to deploy my thing ;-)
[16:59] <sil2100> Aaand since I don't see how to fix it, I think I'll just silently hack around it and worry about it some other time ;p
[16:59] <sil2100> (just don't tell anyone!)
[16:59] <robru> sil2100, wait, where does it ask me what branch to deploy from?
[17:00] <sil2100> robru: soooo, for that, hah, you need to wait! Since it failed redeploying the jenkins job ;)
[17:00] <sil2100> robru: but you want to redeploy prod, right?
[17:00] <robru> sil2100, ooooooohhhhhhhhhhhhhhhhhhhhhhhhh
[17:00] <ogra_> just redeploy it then
[17:00] <sil2100> Or preprod first?
[17:00] <robru> sil2100, I want to deploy it right to prod, since it's the prepare-job
[17:00] <sil2100> robru: if you want to use preprod, then give me a moment to modify the jenkins job manually ;p
[17:00] <robru> sil2100, i can only test it by assigning silos for people
[17:01] <sil2100> robru: so, merge in your merge into lp:cupstream2distro and redeploy prod ;)
[17:01] <robru> sil2100, oh.... ok
[17:03] <robru> sil2100, https://ci-train.ubuntu.com/job/deploy-citrain/74/console you broke it good. anyways I pushed to trunk
[17:04] <sil2100> Yeah, don't use deploypreprod now ;p SInce it's no longer a bool!
[17:04] <sil2100> Changing this right now
[17:04] <sil2100> Just check 'deploy prod' and you're fine ;)
[17:06] <bzoltan1> sil2100: robru: i could land the next round of the QtCreator tomorrow moring if I get a new silo for line36
[17:06] <robru> bzoltan1, ok, we've lost the ability to assign silos at the moment, one sec
[17:07] <sil2100> robru: so, is your branch in trunk right now?
[17:07] <robru> sil2100, yes
[17:07] <robru> sil2100, https://ci-train.ubuntu.com/job/deploy-citrain/76/console yeah I dunno what you did there
[17:07] <sil2100> robru: since if yes, you can just deploy with DEPLOY_PROD_CITRAIN and it should pull in trunk
[17:07] <sil2100> Uh
[17:07] <sil2100> Typo..?
[17:07] <sil2100> Wait
[17:08] <sil2100> AH
[17:10] <sil2100> hmmm
[17:10] <sil2100> Wait, something's not right
[17:11] <sil2100> Ah, ok, nvm
[17:12] <oSoMoN> sil2100, robru: sorry if I sound insistent… could I have a silo for line 32 ? it’s going to require thorough testing, so the sooner I get the silo, the better. Thanks!
[17:12] <sil2100> robru: give me one last moment ;)
[17:12] <robru> sil2100, http://bit.ly/1nzypmn ;-)
[17:12] <robru> oSoMoN, yep, citrain broke, we're working on it
[17:12] <sil2100> robru: need to override the parent of citrain prod, as it's pointing to preprod now by default ;p
[17:13] <oSoMoN> ah, ok
[17:13] <oSoMoN> good luck with that
[17:14] <sil2100> robru: ok, should be ok now ;)
[17:14] <sil2100> robru: redeployed now
[17:14] <robru> sil2100, the deploy log doesn't show that it pulled my commit
[17:14] <sil2100> robru: it pulled it in the cyphermox job ;p
[17:14] <robru> awesome
[17:14] <sil2100> robru: as I had to do a bzr pull --remember to force the lp:cupstream2distro parent
[17:15] <sil2100> I might just change that in preprod to use it explicitly
[17:15] <sil2100> But I didn't want to throw junk commits again
[17:16] <robru> sil2100, ah I see now
[17:16] <robru> sil2100, lawl, my commit was broken, good thing I pushed it to trunk.
[17:16] <sil2100> :O
[17:17] <sil2100> Don't worry, we're breaking the train so much today that no one cares anymore!
[17:17] <sil2100> Just take a bus everyone!
[17:18] <robru> sil2100, ok, fixed in trunk and redeployed
[17:18] <robru> oSoMoN, ok, you got silo 2
[17:18] <robru> sil2100, yeah, CI Bus, that's the next thing. Then the one after that will be called CI Thrown Under The Bus.
[17:18] <bzoltan1> rsalveti: ogra_: do you have a broken emulator with the unity8 failure?
[17:19] <sil2100> haha
[17:19] <sil2100> ;)
[17:19] <robru> sil2100, ok so the prepare job seems to be able to prepare with my column-number-agnostic code, I'm going to brutalize the spreadsheet now, already made a backup copy
[17:19] <oSoMoN> robru, thanks!
[17:19] <sil2100> robru: good luck! I'll just close my eyes and go write the e-mail now
[17:20] <robru> oSoMoN, you're welcome!
[17:20] <robru> sil2100, cover me, I'm going in! ;-)
[17:20] <sil2100> robru: the preprod mention-branch-to-deploy-from seems to work, so at least that ;p
[17:20]  * sil2100 just tested
[17:24] <robru> sil2100, great
[17:25] <robru> ^^ apologies, bot is responding to me screwing up the spreadsheet
[17:32] <robru> bzoltan1, you got silo 5
[17:37] <mhr3> what happened to the spreadsheet?
[17:37] <mhr3> all the silo links disappeared
[17:39] <robru> mhr3, MUAHAHAHAHAHAH
[17:39] <robru> mhr3, silo links are at http://people.canonical.com/~platform/citrain_dashboard/#?q=
[17:39] <robru> mhr3, spreadsheet doesn't scale, since we're soon going to double the number of silos for RTM
[17:39] <mhr3> robru, oh, so it's official removal?
[17:39] <robru> mhr3, yep
[17:40] <mhr3> would be nice to announce beforehand :P
[17:40] <robru> mhr3, I'm just about to make the announcement, literally making the change right now
[17:40] <mhr3> but i'm not going to cry, the dashboard is so much better
[17:40] <robru> sil2100, do you have any idea why SOME of the cells in column C say #REF? the error is 'unknown sheet name' but the formula does not reference any sheet name, very mysterious
[17:41] <mhr3> robru, so how are we going to set the tested state?
[17:41] <robru> sil2100, oh nm, it's indirect from the other formula, i got it
[17:41] <robru> mhr3, there's a new column in the Pending tab
[17:42] <mhr3> aaah, i need to scroll now :P
[17:44] <robru> mhr3, knock your font size down or something... trust me this will be better than having to find the 40'th silo tab when you want to mark testing:done... now it's all on one screen
[17:46] <sil2100> ;p
[17:47]  * sil2100 was supposed to have a half-day sick off, but that didn't really happen much
[17:47] <sil2100> Time to EOD!
[17:47] <sil2100> robru: good to see you found the problem :)
[17:47] <sil2100> o/
[17:47] <robru> sil2100, goodnight!
[17:54] <bzoltan1> pmcgowan: rsalveti: Saviq: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349444 I have commented it.
[17:54] <Saviq> robru, icanhas reconfigure on silo 6 please? we added ubuntu-touch-meta as a new source package
[17:55] <robru> Saviq, sure one sec
[17:56] <robru> Saviq, ok it's going
[17:56] <Saviq> robru, great, can you upload http://people.canonical.com/~msawicz/touch-meta.tar to it please
[17:58] <robru> Saviq, done
[18:08] <robru> ok, gonna test some stuff, please ignore queuebot for a few minutes here
[18:12] <dobey> anyone know how to recover from http://pastebin.ubuntu.com/7886982/ when trying to build something in sbuild? it's causing the chroot to not get updated and thus a failure :-/
[18:16] <robru> dobey, not sure about that specific case, but sometimes 'apt-get -f install' is helpful
[18:16] <robru> dobey, to the point that I often find myself writing code like 'apt-get dist-upgrade --yes || apt-get -f install' when doing chrooty type things.
[18:19] <robru> ^^ disregard queuebot
[18:19] <dobey> robru: right. but how do i tell sbuild to do that? :)
[18:19] <robru> dobey, dunno about sbuild, sorry. just seen it with vagrant images and such
[18:19] <mvo_> dobey: you hit a apt bug
[18:19] <dobey> s/you/sbuild/ :)
[18:19] <mvo_> dobey: bug #1347721
[18:19] <sergiusens> robru: landing of 001 is ready; I set to yes in the "pending" view I recently discovered, but it's taking longer than usual to update the dashboard
[18:20] <sergiusens> oh and the status on spreadsheet is still "packages built"
[18:20] <robru> sergiusens, yeah I'm breaking the spreadsheet literally as we speak
[18:21] <dobey> mvo_: so, what? just rm -rf things and runs mk-sbuild again?
[18:21] <sergiusens> robru: ok, fwiw; silo one is ready to publish
[18:21] <davmor2> Saviq: Nothing is more broken with your silo 006 and somethings are fixed \o/
[18:21] <robru> sergiusens, ok thanks, will get to it shortly
[18:21] <mvo_> dobey: yeah, its just a transient failure
[18:22] <mvo_> dobey: it does not cope with the new "init" package, I'm working on a fix, but its unfortuately non-trivial
[18:22] <dobey> mvo_: what do i rm -rf exactly? sbuild is a bit of a black box for me still :-/
[18:24] <mvo_> dobey: it should be in /var/lib/schroot/chroots/ somewhere
[18:32] <dobey> mvo_: hrmm, i don't have that chroots directory...
[18:33] <dobey> oh wait, nevermind
[18:39] <rsalveti> ogra_: robru: did we trigger a new image already?
[18:39] <robru> rsalveti, i didn't
[18:40] <mvo_> dobey: ok, I think I found the bug, if all goes well I upload later tonight
[18:40] <rsalveti> guess we can trigger one then, as ubuntu-ui-toolkit-gles landed in release
[18:41] <robru> rsalveti, cool, you want to do it or should i?
[18:41] <rsalveti> robru: let me trigger this one, never used the web interface
[18:41] <robru> rsalveti, heh, ok
[18:41] <robru> rsalveti, i found it not super intuitive but if you just read it you can figure it out
[18:41] <dobey> mvo_: cool. thanks for the help
[18:42] <rsalveti> in theory I did the right thing hehe
[18:42] <mvo_> dobey: no problem :)
[18:42] <robru> rsalveti, yep, looks so
[18:43] <rsalveti> still not showing up at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch/ but that might take a few still
[18:49] <imgbot> [18:50] <robru> wooop wooop, ok I need to grab some grub, bbl
[18:51] <pmcgowan> robru, rsalveti did mediascanner fix already land?
[18:52] <rsalveti> pmcgowan: afaik, yes
[18:52] <pmcgowan> cool
[18:54] <davmor2> pmcgowan: yeah apparently they want ToyKeeper to test it as she might not break it so much,  I think they don't know her skills :D
[19:04] <ToyKeeper> Oh, that landed in 155?
[19:05] <ToyKeeper> I thought it might not land until 156.
[19:18] <ToyKeeper> (also, thought I had a few more hours before that needed to start)
[19:20] <ToyKeeper> Hmm, the commit logs don't seem to update along with the image... gotta wait for that to be manually updated I guess.
[19:20] <ToyKeeper> (so I've been testing sort of in the dark due to being in the wrong time zone)
[19:22] <fginther> kalikiana, lp:ubuntu-push-qml  is not setup for ci
[19:22] <fginther> kalikiana, oops. that should be *now setup* for ci
[19:38] <robru> alexabreu, ^ so you should probably make sure that the name you put in column B matches your IRC name so that the bot pings you properly
[19:39] <alex-abreu> robru, or the opposite
[19:39] <alex-abreu> thx
[19:39] <robru> alex-abreu, hehe, no worries
[19:39] <alex-abreu> robru, can you reconf for me?
[19:39] <robru> alex-abreu, yes ;-)
[19:40] <oSoMoN> robru, where did all the silo tabs vanish?
[19:41] <robru> oSoMoN, well, I deleted them, see my announcement on ubuntu-phone
[19:41]  * oSoMoN goes read his e-mail
[19:42]  * Chipaca grovels for a silo
[19:43] <robru> Chipaca, ONLY BUGFIXES!!!!!!!11!!11!eleven!!!
[19:43] <oSoMoN> robru, this dashboard looks so much better than the spreadsheet, thanks!
[19:44] <robru> oSoMoN, you're welcome!
[19:44] <Chipaca> robru: well... does that mean i've got to cherry pick a bugfix?
[19:44] <robru> oSoMoN, you still need the spreadsheet to initiate the request and mark testing:done. but all the jenkins jobs can be triggered from the spreadsheet
[19:44] <robru> i mean the dashboard
[19:45] <robru> Chipaca, it means I'm not landing any features today! is your thing a mixture of features and fixes?
[19:45]  * Chipaca looks at the changelog
[19:45] <Chipaca> robru: yes :-(
[19:45] <Chipaca> it can wait, i guess?
[19:46] <robru> Chipaca, yeah, we're in lockdown right now, only fixes can land.
[19:46] <robru> Chipaca, feel free to build in silo but I won't publish today
[19:46] <Chipaca> robru: i'll get it ready and tested, but won't ask for landing until traincon is >0
[19:46] <robru> Chipaca, ok thx
[19:46] <Chipaca> yeah, that's what i wanted :)
[19:46] <Chipaca> robru: thanks!
[19:47] <robru> Chipaca, you're welcome
[19:47] <Chipaca> ooh, only 1 silo remaining. Maybe I'll sell mine on ebay instead.
[19:47] <robru> Chipaca, SILOS ARE NON TRANSFERRABLE!!!!
[19:47] <robru> ;-)
[19:47] <Chipaca> robru: we can go 50/50
[19:47] <cjwatson> dobey: for future reference you didn't need to rm.  'sbuild-update -udc utopic-amd64', then when it fails, 'schroot -c source:utopic-amd64 -u root' and in that shell 'apt-get -f install; apt-get dist-upgrade'
[19:49] <ToyKeeper> Woot.  Don't try to answer a call during the initial welcome setup wizard process.
[19:49] <ToyKeeper> Instead of 'accept' and 'decline', the buttons should be labelled 'fail' and 'fail'.
[19:49] <Chipaca> ToyKeeper: not "fail" and "fail harder"? I am disappoint.
[19:51] <dobey> cjwatson: hmm, ok
[19:52] <ToyKeeper> robru: Whatever changed in image 155, it didn't fix mediascanner.
[19:52] <robru> ToyKeeper, ok, thanks for testing!
[19:52] <ToyKeeper> No local media shows up in the scopes, and the music app just crashes on startup.
[19:53] <ToyKeeper> The gallery app can see photos and videos...  but it still sucks at actually playing the videos.
[19:53] <ToyKeeper> If it's alright, I think I'll wait for image 156 before I do more detailed tests.
[19:54] <ToyKeeper> robru: However, if a mediascanner crash file would be useful, I have one.
[19:55] <robru> ToyKeeper, yes, that's probably a thing that we want.
[19:55] <robru> ogra_, do we know who was working on mediascanner? so we can flog them?
[19:56] <slangasek> beatings will continue until mediascanner improves?
[19:56] <slangasek> there don't appear to be any recent changes to mediascanner itself
[19:57] <slangasek> there does appear to be an upload of the mediascanner package by xnox, stuck in proposed since May
[19:58] <cjwatson> mediascanner2 I think
[19:58] <slangasek> ah, ok
[19:58] <slangasek> robru, ToyKeeper: https://errors.ubuntu.com/?period=day&pkg_arch=armhf may be useful
[19:58] <slangasek> as mediascanner2.0 is listed as the top crasher there
[19:58] <ToyKeeper> I've never actually gotten whoopsie to upload any crash dumps, even when whoopsie-upload-all asks it to.
[19:59] <slangasek> and rumors of phones non-backtraceability have been greatly exaggerated
[19:59] <slangasek> ToyKeeper: is that something you have time to dig into today?  I don't want to distract you if you're working on something else, but we need to get to the bottom of issues with whoopsie not uploading
[20:00] <slangasek> plars, josepht: ^^ I wasn't aware of any issues that would break whoopsie-upload-all, were you?
[20:01] <slangasek> anyway, that backtrace on errors has a very suggestive error message
[20:01] <slangasek>         msg = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x84b424 "Could not look up user name: Permission denied"}}
[20:01] <ToyKeeper> FWIW, http://toykeeper.net/tmp/phablet/2014-07-28/_usr_bin_mediascanner-service-2.0.32011.crash.bz2  is from image 155.
[20:01] <slangasek> who's putting money on this being related to the NSS changes
[20:01] <cjwatson> EACCES from getpwuid, hmm
[20:01] <cjwatson> ME
[20:02] <slangasek> I think this mediascanner crash entirely explains the smoketest regressions too, doesn't it?
[20:02] <ahayzen> robru, FYI Jussi Pakkanen and James Henstridge work on mediascanner2
[20:02] <slangasek> all of which were related to pictures not showing up in places
[20:02] <slangasek> so mediascanner is confined
[20:02] <ahayzen> ...thts who i contact when we need features for music-app anyway...
[20:03] <slangasek> do we have an apparmor policy that allows /var/lib/nssextrawhatever?
[20:03] <cjwatson> there was just an apparmor upload fixing that
[20:03] <slangasek> ok
[20:03] <cjwatson> do we have crashes postdating it?
[20:03] <slangasek> then should this be fixed when that lands?
[20:03] <cjwatson> https://launchpad.net/ubuntu/+source/apparmor/2.8.96~2541-0ubuntu2
[20:03] <cjwatson> which means 156 might well fix this
[20:03]  * slangasek nods
[20:04] <cjwatson> buildlog says it has 2.8.96~2541-0ubuntu2
[20:04] <slangasek> ToyKeeper: cjwatson and I think the mediascanner crash is fixed in 156; please let us know if it looks otherwise to you
[20:04] <ToyKeeper> If we build 156 early I'd be happy to test it sooner.
[20:04] <cjwatson> it's almost built
[20:05] <cjwatson> wait, hmm
[20:05] <pmcgowan> you mean 155?
[20:05] <cjwatson> now I'm confused
[20:05] <pmcgowan> 155 is still building afaik
[20:06] <pmcgowan> with those two fixes for blockers
[20:06] <cjwatson> right, so I'm confused about what ToyKeeper said about 155
[20:06] <pmcgowan> me too
[20:06] <ToyKeeper> Gah, you're right.  I misread the imgbot notification as built instead of building.
[20:06] <cjwatson> ok, so slangasek and I think the mediascanner2 crash is fixed in *155* :-)
[20:06] <pmcgowan> should be done soonish
[20:07] <slangasek> oh
[20:07] <ToyKeeper> Too many fires burning all at once today.
[20:08] <robru> slangasek, oh is that fixed now? sweet
[20:09] <slangasek> well, I thnk we don't know
[20:09] <slangasek> ToyKeeper: you said http://toykeeper.net/tmp/phablet/2014-07-28/_usr_bin_mediascanner-service-2.0.32011.crash.bz2 is definitely from image 155?
[20:09] <ToyKeeper> slangasek: No, it's from 154.  I was just getting ahead of myself.
[20:09] <slangasek> ok
[20:09] <slangasek> in that case, we await your re-testing :)
[20:10] <cjwatson> robru: I'm fairly sure it will at minimum shift the problem to the next thing along :-)
[20:10] <ToyKeeper> I saw imgbot's notification and reflashed and tested before I noticed it said 'building' instead of 'done'.
[20:11] <robru> oh right
[20:11] <pmcgowan> ToyKeeper, no worries
[20:11] <robru> hehe
[20:11] <pmcgowan> I was just checking for it myself
[20:12] <veebers> robru: query, libautopilot-qt silo, the 'needs sign-off' is related to traincon-0?
[20:12] <cjwatson> yes
[20:12] <robru> veebers, yep
[20:12] <robru> veebers, so you'll need ToyKeeper to approve that your silo doesn't break anything before I can release that
[20:13] <veebers> robru, cjwatson: I guess it doesn't count that I set testing to yes yesterday before your Monday right ;-)
[20:13] <josepht> slangasek: I'm not aware of any issues that would break whoopsie-upload-all either
[20:13] <veebers> robru: ack
[20:13] <slangasek> josepht: ok
[20:13] <veebers> ToyKeeper: If you have a moment, can I work with you to get that done?
[20:14] <slangasek> josepht: do you have time to work with ToyKeeper to track down whatever she's seeing?
[20:14] <ToyKeeper> veebers: Possibly, but image 155 should be done any moment now and that needs to get tested ASAP.  Could we try after 155 is built?
[20:14] <veebers> ToyKeeper: for instance I have this testing report I did with the gatekeeper: http://pastebin.ubuntu.com/7880920/
[20:14] <veebers> ToyKeeper: sure thing
[20:14] <veebers> thanks :-)
[20:15] <ToyKeeper> josepht: I haven't investigated much yet; I didn't even know about whoopsie-upload-all until last week.
[20:17] <ToyKeeper> josepht: It could have been a transient thing; it looks like my crashes just uploaded, using 154 as a base image.
[20:18] <ToyKeeper> When I tried last week, I couldn't get it to send anything at all.  But that was like ten images ago.
[20:19] <plars> slangasek: I've had some success with the latest version of whoopsie with the workarounds in place. I know it's been very hit-or-miss in the past though
[20:19] <plars> hopefully the recent fixes will improve the situation
[20:21] <bzoltan1> robru: The silo5 is still chewing on the powerpc build when I am finished with my testings. The package in the silo has a simple change in the debian/control file, so it will require a semigod's ack :) Otherwise the package is good to go.
[20:21] <tvoss> robru, hey there :) can I get a silo for line 37?
[20:22] <robru> tvoss, hm, conflicts with 6...
[20:23] <tvoss> kgunn, hey there :)
[20:24] <tvoss> kgunn, do you have an eta for silo 6 handy?
[20:24] <bzoltan1> robru: Is there a chance to kick a powerpc builder to pick up this build? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+build/6219308 Not so long time ago I had to wait like 10 hours just for that pointless powerpc builder.
[20:24] <kgunn> tvoss: i'd like to call it done and land it right now
[20:24] <kgunn> Saviq: ^
[20:24] <kgunn> ?
[20:24] <kgunn> greybacks not around but it sure seems ready from my testing
[20:24] <robru> kgunn, nope, not landing 6 during TRAINCON-0 unfortunately
[20:25] <kgunn> tvoss: ^ well, i guess there's always tomorrow
[20:25] <robru> bzoltan1, not sure. fginther do we know how to bump the priority on builds? ^^ (see bzoltan1's message)
[20:26] <robru> kgunn, tvoss: wait so what's up? am I overriding the conflict so tvoss can have a silo?
[20:26] <kgunn> dunno, i assume tvoss wants to touch something i have in silo6 and he's being nice :)
[20:26] <kgunn> just asking
[20:27] <fginther> robru, that would have to go through IS if anyone were able to do anything about it
[20:27] <bzoltan1> fginther: robru:  I am just totally confused why on earth we do not switch off these powerpc build... if you add up all the hours, days we wait for them the result is way much more than it would take to fix dozens of serious regression. That is called bad investment.
[20:27] <robru> kgunn, yeah, he's got a platform-api branch
[20:27] <tvoss> kgunn, yup, exactly. Got a platform-api bugfix in 6
[20:27] <robru> bzoltan1, yeah I dunno either, not my call though... i don't even know who controls that
[20:28] <kgunn> robru:  so silo6 technically also fixes a blocker
[20:29] <kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349362
[20:29] <robru> kgunn, yeah but that issue is whitelisted since we know that fix is coming. today is the day we slam on the breaks, stop all big landings, and only land small/medium sized fixes
[20:30] <fginther> bzoltan1, I don't have a good answer for that either. I'm assume it's possible to selectively disable architectures for a PPA
[20:30] <ToyKeeper> kgunn: Ah, sweet.  I ran into that bug about once every 10 to 15 minutes.  Good to hear it's ready to land.
[20:30] <kgunn> robru: this is bad logic and puts pain on me....the amount of testing i have to do for silo6 is huge
[20:30] <bzoltan1> fginther: who to ask to disable the powerpc for all Silos for all projects?
[20:30] <robru> kgunn, yeah this TRAINCON stuff comes straight from asac.
[20:30] <kgunn> and so every time some little thing gets fixed in unity8, platform-api, ubuntu-system-settings etc
[20:30] <bzoltan1> fginther: it is totally pointless
[20:31] <kgunn> robru: we could make the same argument for platform-api...we know a fix is coming, so white list
[20:31] <josepht> ToyKeeper: if you encounter whoopsie not uploading again let me know and I'll be happy to dig into it further
[20:31] <kgunn> robru: not blaming you...its just not sensible
[20:31] <robru> kgunn, the difference is, tvoss' branch is small, just one fix. your silo is huge and touches many things and has a big potential for regressions
[20:31] <kgunn> i was ready to land fri morning alredy
[20:31] <kgunn> olli: ^ this isn't sensible
[20:31] <ToyKeeper> josepht: I think I must have simply discovered it at a bad time.  Seems fine today.
[20:32] <olli> kgunn, otp
[20:34] <fginther> bzoltan1, I would start with sil2100 and perhaps slangasek and cjwatson.
[20:34] <robru> bzoltan1, fginther: it won't be sil2100. slangasek and cjwatson are good people to ask though
[20:34] <robru> slangasek is even supposed to be around at this time... ;-)
[20:34] <kgunn> bzoltan1: good luck with that one :)
[20:35]  * kgunn recalls powerpc with xmir
[20:35]  * bzoltan1 will this circle just for pleasure
[20:35] <bzoltan1> run
[20:35] <fginther> kgunn, do you recall the context? Is this just a matter of we're gating on all supported architectures?
[20:36] <robru> fginther, yeah I think so. the archive prevents you from regressing on arches, so if you ever built on powerpc, you have to always build on it for the rest of time
[20:36] <kgunn> yep
[20:36] <bzoltan1> robru:  and that is what i call waste of time
[20:37] <robru> bzoltan1, I dunno, we might want to run uitk on a G3 one day.
[20:37] <bzoltan1> robru:  this build is for the QtCreator's plugin
[20:37] <robru> bzoltan1, yeah, I'd feel bad if all those pre-intel mac users couldn't run it ;-)
[20:37] <bzoltan1> robru:  a strictly desktop component
[20:38] <bzoltan1> robru: that would be horrible ... If one, a single SDK user shows up with a powerpc environment i will buy a PC to her.
[20:40] <robru> bzoltan1, just kidding, yeah I've wanted to shut off powerpc for a while. intel macs came out 9 years ago, I don't even know of any modern computers using powerpc.
[20:41] <robru> kgunn, so what's happening with tvoss's landing? we're waiting for olli to step in and make a call here?
[20:43] <bzoltan1> robru:  well, I switched off my alpha server just few years ago :) after like 5y uptime ... So I can imagine all kind of crazy people
[20:44] <tvoss> robru, okay, let kgunn proceed, but I would appreciate a silo to get some testing mileage
[20:44] <tvoss> robru, I will take care of merging trunk after 6 landed
[20:44] <robru> tvoss, ok then
[20:44] <olli> robru, kgunn, tvoss, reading backlog
[20:44] <tvoss> robru, thank you :)
[20:45] <robru> tvoss, you're welcome
[20:45] <kgunn> tvoss: thanks...
[20:45] <tvoss> kgunn, yw
[20:46] <ToyKeeper> ... I still have an 13-year-old off-brand Tivo clone running as my home router / firewall / name server / email server.  But it's at least x86-based.
[20:46] <kgunn> olli: point is, i think i found a bug with our traincon....complex stuff (e.g. touches multiple things)
[20:46] <kgunn> can get caught in a "i tested, its ok" "sorry that changed, rebuild pls" vortex
[20:46] <robru> olli, ok so the current status is that kgunn and tvoss have conflicting silos (that is, they each have a silo that contains a different build of platform-api). tvoss' one is a small fix, where kgunn's is a huge landing that touches many bits. normally we'd give tvoss priority here because his landing is smaller, but kgunn is saying that tvoss' landing will cause him a lot of retesting headache. normally I could just do kgunn's release, but we're in
[20:46] <robru> this asac-mandated TRAINCON-0 state which means no big landings can get through.
[20:46] <ToyKeeper> Traincon is definitely far from perfect.  I'd be happy about any improvements you can come up with.
[20:47] <ToyKeeper> With any luck, traincon 0 might end within like 20 minutes of 155 finishing its build.
[20:47] <ToyKeeper> BTW, it doesn't normally take this long to build, right?
[20:48] <olli> robru, so when TRAINCON-0 clears tomorrow (as it looks atm) I think we should queue the silos that require more retesting first
[20:48] <robru> ToyKeeper, yeah it should have built by now. usually it's around 1.5 hours
[20:48] <kgunn> olli: consider small changes, have small amount of tests, large changes have large amount of testing
[20:48] <robru> olli, oh for sure, kgunn can be first in line when traincon is over
[20:48] <olli> if tvoss' change is comparatively small / less complex then I think it's fair to put the retest burden on him
[20:48] <olli> kgunn, are you asking to get in during traincon?
[20:48] <kgunn> olli: can i  :)
[20:49] <olli> did you?
[20:49] <kgunn> olli: well it does fix a whitelisted-blocker, and we are tested
[20:49] <kgunn> may we ?
[20:50] <olli> robru, what else is keeping us in traincon-0 atm?
[20:50] <olli> iirc, it was the whitelisted shutdown dialog bug, the emulator bug and music scanner
[20:51] <robru> olli, just https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349444 according to the last landing mail. if that's the case then 155 should fix it, as soon as that's done building any second now
[20:53] <olli> robru, do you have an ETA for the fix?
[20:53] <olli> rsalveti, ^
[20:54] <robru> olli, dunno, image should be done building any minute now
[20:54] <robru> olli, so, ETA: "any minute now" ;-)
[20:54] <rsalveti> olli: fix is already available, just waiting the latest image
[20:54] <olli> rsalveti, k
[20:55] <robru> rsalveti, I noticed the iso tracker no longer indicates a build is in progress, I guess that means it's pretty close to done.
[20:55] <robru> tvoss, you got silo 1 btw (please build)
[20:55] <rsalveti> yeah
[20:55] <rsalveti> the cdimage side is done already for quite a few https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch/
[20:56] <robru> rsalveti, I tried ubuntu-device-flash and it just came up with 154.
[20:56] <rsalveti> probably waiting the system-image import
[20:57] <olli> robru, so, I think re qtcomp / tvoss' platform api change... it's all good, get 155 out, then qtcomp, then tvoss' fix as discussed initially... sorry, had to catch up a bit
[20:58] <robru> olli, ok, sounds like a good plan, thx
[20:58] <tvoss> robru, my ci train spreadsheet is missing tabs for silos ...
[20:58] <robru> tvoss, ;-)
[20:58] <robru> tvoss, there's an email in ubuntu-phone explaining it
[20:59] <kgunn> olli: robru tvoss ...thanks...sorry about being a whiner, i just felt like groundhog day on testing qtcomp
[20:59] <robru> kgunn, no worries, I see big silos get stuck like that all the time, it's not just you
[20:59]  * tvoss hugs kgunn
[20:59]  * kgunn just realizes groundhog day might not translate.... http://www.imdb.com/title/tt0107048/
[20:59] <tvoss> robru, got the subject line handy?
[21:00] <ToyKeeper> Good movie.
[21:00] <robru> tvoss, uh, "ANNOUNCING: ..." sent by me, like just hours ago
[21:00] <popey> where is image #155 ?
[21:01] <popey> it strarted building hours ago
[21:01] <popey> also started
[21:01] <robru> tvoss, https://lists.launchpad.net/ubuntu-phone/msg09202.html
[21:01] <robru> popey, lol
[21:02] <kgunn> obviously there's your problem...strarting and starting at the same time :)
[21:03] <popey> it's usually 1.5 hours, but it's over 2 hours now
[21:04] <imgbot> [21:04] <imgbot> [21:04] <popey> wat
[21:04] <robru> woop woop!
[21:04] <ToyKeeper> ... and flashing.
[21:06] <popey> ogra_: tapping the notification in #154 works again
[21:07] <robru> rsalveti, you able to test that 155 fixes the emulator? I don't have the emulator set up at the moment
[21:07] <rsalveti> yup, give me a minute
[21:07] <robru> rsalveti, sweet thanks
[21:09] <bzoltan1> cjwatson: fginther: robru: I have heard from IS that  the powerpc builders are currently chewing through gcc, eglibc and libreoffice.. so it might take days before some of the actual builds are picked up.
[21:09] <bzoltan1> robru: rsalveti: I have tested the package on an emulator
[21:10] <bzoltan1> robru: rsalveti: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1349444/comments/6
[21:11] <robru> bzoltan1, is that a typo? we just built image 155 minutes ago. at most you could have tested image 154, not 157.
[21:11] <bzoltan1> robru:  that is what my fresh emulator said about itself
[21:11] <robru> rsalveti, are the x86 image numbers out of sync with the arm ones?
[21:12] <rsalveti> robru: yup
[21:12] <robru> rsalveti, ah ok
[21:12] <rsalveti> we need to build just for armhf a few times
[21:12] <robru> bzoltan1, nm then
[21:12] <rsalveti> so they can be in sync again
[21:16] <ToyKeeper> ... four crash dumps so far right after flashing, before I even got to see the setup wizard.
[21:17] <rsalveti> yeah, same here for the emulator
[21:17] <rsalveti> setup wizard not even showing up =\
[21:17]  * pmcgowan pauses download
[21:17] <ToyKeeper> I'm still waiting for that, watching to see what happens.
[21:18] <rsalveti> ouch, something bad is going on in here
[21:18] <ToyKeeper> _usr_lib_arm-linux-gnueabihf_url-dispatcher_update-directory.32011.crash, _usr_bin_system-settings-wizard.32011.crash, _usr_bin_unity8.32011.crash, _usr_bin_maliit-server.32011.crash
[21:18] <ToyKeeper> (in that order)
[21:18] <rsalveti> yeah, got the same ones with the emulator here
[21:18] <rsalveti> with the x86 one
[21:18] <davmor2> rsalveti pmcgowan 155  looks like it has the same ota issue that 150 had
[21:18] <rsalveti> everything is broken lol
[21:19] <pmcgowan> how did so many new packages land?
[21:19] <ToyKeeper> Let's see if second boot is any better...
[21:19] <davmor2> rsalveti I think it is the user permissions again like 150
[21:19] <rsalveti> right, but how
[21:19] <rsalveti> new lightdm?
[21:19] <pmcgowan> we got nw apparmors
[21:19] <pmcgowan> new
[21:20] <pmcgowan> new upstart
[21:20] <rsalveti> no DENIED in syslog
[21:20] <rsalveti> let me open the crash file
[21:20] <davmor2> rsalveti I think that there was a better fix for the temp work around and that might of landed
[21:21] <fginther> bzoltan1, days? good lord
[21:22] <bzoltan1> fginther: I git my build's score bumped, but see how long it takes for other silos to pick up a powerpc build.
[21:22] <ToyKeeper> robru: So, it looks like a big "no" for promoting 155.
[21:22] <robru> ungh
[21:23] <robru> mine's still flashing
[21:23] <davmor2> Toykeeper: +1 for the no promotion
[21:23] <ToyKeeper> Image 155 can't even boot to a user interface.
[21:23] <bzoltan1> fginther:  like the silo10 with the autopilot ... it was startd on 24th and finished on 25th
[21:23] <olli> so, how did that stuff creep in?
[21:23] <pmcgowan> robru, why did so many packages get added to the image, direct from archive?
[21:23] <robru> pmcgowan, i... what? image builds always pull the latest stuff from the archive
[21:23] <pmcgowan> hard to manage a traincon that way
[21:24] <pmcgowan> lets see what actually broke it
[21:24] <robru> pmcgowan, we don't control the archive. image builds were always snapshots of the archive.
[21:24] <pmcgowan> understood
[21:24] <davmor2> Toykeeper can you do a fresh install and see if it works then please that would confirm the thought that it is the permissions
[21:24] <ToyKeeper> ... hence why there has been talk of a distro fork (of sorts) for the phone.
[21:25] <pmcgowan> yes it is coming
[21:25] <ToyKeeper> davmor2: This *was* a fresh install.
[21:25] <davmor2> ouch
[21:25] <rsalveti> ToyKeeper: yeah, seems something with either hybris or android is broken
[21:25] <rsalveti> checking to see what is going on
[21:26] <robru> davmor2, how fresh is fresh? I'm flashing with u-d-f, but not using --bootstrap
[21:26] <ToyKeeper> ubuntu-device-flash --developer-mode --channel=ubuntu-touch/utopic-proposed --device=$MODEL $REVARGS --bootstrap
[21:26] <robru> kgunn, so I guess we're not releasing 6 at the moment
[21:26] <davmor2> robru Toykeeper already did it
[21:26] <rsalveti> ricmm: around?
[21:26] <robru> davmor2, ah, she did the bootstrap even, alright then
[21:27] <ToyKeeper> kgunn: Indeed, bad news.  :(  We could potentially try it on 154...  but it probably still couldn't land until whatever broke 155 is fixed.
[21:27] <kgunn> robru: right...i'll bide my time until there's an image
[21:27] <robru> kgunn, still I guess we're sticking with the plan to make tvoss wait for you though
[21:27] <tvoss> robru, fine with me
[21:27] <robru> tvoss, ok cool
[21:28] <davmor2> 😥rsalveti ah I wonder if they added the permissions fix in the android layer?
[21:28]  * kgunn is going to start the "tvoss is cooler than cool" club
[21:28] <rsalveti> nothing changed in the android layer though
[21:28] <tvoss> kgunn, I might start annoying you tomorrow, though :)
[21:28] <rsalveti> and latest android was already using latest libhybris
[21:29] <kgunn> tvoss: perfectly understandable
[21:29] <pmcgowan> lightdm did change as well
[21:29] <robru> davmor2, ToyKeeper and whoever else is feeling helpful: I guess we need to reflash 154, install packages one at a time until we reproduce the issue, to identify what broke. can we coordinate who tests which packages to make it go faster?
yeah seriously kgunn, if you could stop blocking other people that'd be great... </>
[21:30] <davmor2> robru rsalveti already did looks like android hybris
[21:30] <rsalveti> checking android nothing changed in that area though
[21:30] <rsalveti> but I'm getting an issue when calling eglCreateWindowSurface
[21:31] <rsalveti> really weird
[21:31] <ToyKeeper> ... and flashing 154 again.
[21:32] <davmor2> yeap that sounds similar to the issue I had on 150 when the permissions failed
[21:32] <rsalveti> yeah, wonder if lightdm
[21:32] <davmor2> rsalveti^
[21:32] <rsalveti> let me update 154
[21:33] <kgunn> olli: yeah, gonna have to ask you stop blocking people saturday, and go ahead and make plans to stop blocking on sunday too...yeah, that'd be great
[21:34] <rsalveti> I landed 2 things, a new android respin that only affects the emulator and changes in the initrd itself, that I tested with every device before pushing
[21:34] <rsalveti> so it could either be the initrd changes or lightdm, I'd guess
[21:34] <olli> kgunn :)
[21:37] <davmor2> guys I need to get off
[21:38] <josepht> famous last words
[21:38] <pmcgowan> rsalveti, whatcha gonna try first? I am rebooting 154
[21:39] <rsalveti> updated 154, then copied over the new initrd, worked fine
[21:39] <rsalveti> might be a first boot issue with the current lightdm package
[21:39]  * pmcgowan suspects lightdm
[21:42] <bzoltan1> robru: I am done with the silo5, it is a fairly trivial diff compareto the last release, but will require a spcial ack as it is changing the control file.  Would you push it forward so it lands before zbenjamin wakes up in about 8 hours?
[21:42] <robru> bzoltan1, hmmmm
[21:42] <robru> hang on
[21:43] <bzoltan1> robru: is something wrong?
[21:43] <robru> bzoltan1, do you have bug references for those branches?
[21:44] <bzoltan1> robru: yes, for one of the MRs I have added the bug number
[21:44] <robru> bzoltan1, yeah, we just built an image so broken it doesn't built, and we're in the middle of TRAINCON-0, it's not a good time to just be landing things
[21:44] <ToyKeeper> Can I just apt-get install the new lightdm to test?
[21:44] <robru> it doesn't boot
[21:44] <robru> ToyKeeper, I think so, just reboot ;-)
[21:44] <bzoltan1> robru:  I have a desktop component landing
[21:44] <robru> bzoltan1, oh right, sorry
[21:44] <robru> ok
[21:44] <bzoltan1> robru:  it has nothing to with the image, luckily  :) That is why  I am so calm here with my little QtCreator
[21:45] <ToyKeeper> ... apt-get update takes forever sometimes.
[21:46] <robru> barry, infinity, kenvandine: anybody around for an easy packaging ack? just a couple lines: https://ci-train.ubuntu.com/job/landing-005-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.1.1+14.10.20140728.1-0ubuntu1.diff
[21:46] <ricmm> rsalveti: whats up?
[21:46] <rsalveti> ricmm: thought the nativebuffer changes could have caused the issue, but previous android already had it included
[21:46] <cjwatson> bzoltan1: days?  nonsense, and fwiw exaggeration like that tends to make me ignore things.  your build is done anyway.
[21:47] <rsalveti> latest image is failing because eglcreatesurface is giving up
[21:47] <rsalveti> when mir starts
[21:47] <ricmm> rsalveti: ok, doubt it tho, I didnt break ABI, just removed the broken overloaded constructor
[21:47] <rsalveti> yeah
[21:47] <ricmm> rsalveti: that sounds bad
[21:47] <rsalveti> still investigating
[21:47] <ricmm> bad enough to be a simple thing
[21:47] <ricmm> rsalveti: whats the package delta?
[21:48] <pmcgowan> there seems to be a new gcc, libstdc too
[21:48] <rsalveti> ricmm: http://people.canonical.com/~ogra/touch-image-stats/155.changes + android rebuild + new initrd
[21:49] <ricmm> rsalveti: a permissions regression? app armor perhaps
[21:49] <bzoltan1> cjwatson:  my exaggeration was a straight quote from the #is channel and I did check few silos and yes I found exaple for build that started on day k and finished on day k+1 and yes it did happen to me some days ago that I had to queue for 10 hours just to start a build on powerpc.
[21:49] <cjwatson> bzoltan1: https://launchpad.net/builders/ shows the queue time.
[21:49] <cjwatson> (which is an approximation, but not a terrible one.)
[21:50] <rsalveti> ricmm: probably
[21:50] <rsalveti> 154 + android and initrd from 155 still works fine
[21:50] <rsalveti> will try updating the image before booting it
[21:51] <jdstrand> today's apparmor should not have anything to do with mir surface creation
[21:51] <ToyKeeper> A lightdm upgrade didn't break anything, AFAICT.
[21:52] <ToyKeeper> ... trying apparmor.
[21:52] <jdstrand> it simply added rules so mediascanner could access the libnss-extrausers files
[21:52] <rsalveti> wonder if this might be a first boot only issue
[21:52] <ToyKeeper> rsalveti: I tried two boots with 155, no luck either time.
[21:52] <rsalveti> ToyKeeper: but did you flash clean or updated over ota?
[21:52] <ToyKeeper> Flashed clean.
[21:52] <rsalveti> right
[21:53] <rsalveti> wonder if ota will work
[21:53] <bzoltan1> cjwatson: I was queuing for 3 hours for this build and I got a builder by being bumped. If I do not ask for it it would have taken  much more.
[21:53] <ToyKeeper> rsalveti: davmor2 did ota and his first boot failed.  Not sure about the second.
[21:53] <cjwatson> bzoltan1: but not days.
[21:53] <slangasek> plars: however, the workarounds are unrelated to whoopsie-upload-all, aren't they?  I thought they only related to whoopsie+inotify problems
[21:53] <cjwatson> deej was quite obviously speaking loosely, not giving a precise estimate
[21:53] <bzoltan1> cjwatson: as I said I was told that
[21:54] <cjwatson> deej was quite obviously speaking loosely, not giving a precise estimate
[21:54] <cjwatson> perhaps this is a language issue
[21:54] <cjwatson> "could be days" -> diiom
[21:54] <cjwatson> idiom
[21:55] <ToyKeeper> Apparmor alone didn't break the boot either...  trying several more related packages.
[21:56] <cjwatson> bzoltan1: Of course, given that qtcreator-plugin-ubuntu only has reverse-dependencies on amd64/armhf/i386, it's within your power to limit the set of architectures it builds on.
[21:56] <bzoltan1> cjwatson:  sorry, english is only my third language, I did take the "it could take days" literally
[21:56] <robru> hm, image 154 + lightdm booted fine
[21:57] <rsalveti> there are a bunch more packages though
[21:57] <robru> rsalveti, what should I try next? any likely candidates in mind?
[21:57] <ToyKeeper> robru: And image 154 + lightdm + apparmor booted fine too.
[21:58] <ricmm> robru: did you try rolling back the archive's stdc?
[21:58] <robru> ricmm, didn't "roll back" anything, just flashed down to 154 and now I'm selectively updating.
[21:59] <robru> ricmm, so if there was a stdc update in 155 then yes, otherwise no ;-)
[21:59] <ToyKeeper> I just installed a bunch of other apparmor-related libs...  and still no boot issues.
[22:00] <ricmm> robru: upgrade libstdc
[22:00] <robru> ricmm, ok, i'll try that next
[22:00] <ricmm> that'd be a good test
[22:00] <ToyKeeper> I'm trying upstart next.
[22:00] <robru> ToyKeeper, i just did upstart, still rebooting though
[22:00] <robru> ToyKeeper, boots fine with new upstart
[22:00] <ToyKeeper> After that was going to be libstdc++6
[22:01] <rsalveti> 154 then updated everything, including android and initrd, and it worked fin
[22:01] <rsalveti> wtf
[22:01] <robru> rsalveti, ugh
[22:02] <ricmm> cute
[22:03] <plars> slangasek: whoopsie-upload-all can't really do anything I think, until the whoopsie daemon has done it's job. But I don't have a deep understanding of that process. Brian would know more
[22:03] <ToyKeeper> plars: w-u-l just tells whoopsie to upload everything when it gets the chance, if I understand correctly.  It does none of the work itself.
[22:03] <slangasek> hmm
[22:04] <slangasek> rsalveti, robru: ok, so what changed that's *not* part of one of the packages in the image? livecd-rootfs?
[22:04] <slangasek> stgraber: ^^ did mvo's changes for the system-image server image land?
[22:04] <rsalveti> slangasek: in theory, yeah
[22:04] <rsalveti> (livecd)
[22:05] <robru> slangasek, there can be changes not in packages?
[22:05] <ToyKeeper> Has anyone looked at the image build log?  Maybe there was a reason it took so long...
[22:05] <slangasek> robru: the build infrastructure itself
[22:05] <plars> ToyKeeper: yeah, from a ci perspective, the whole thing is too asynchronous. We really would rather have a way to say "there's a crash file that showed up, upload it NOW" at the end of the job
[22:05] <slangasek> robru: here's another angle - download the actual system-image delta between 154 and 155 and look at what files have changed that aren't expected to
[22:05] <robru> slangasek, where is that kept?
[22:05] <slangasek> robru: system-image.ubuntu.com
[22:06] <ricmm> rsalveti: maybe some default permissions went bad
[22:06] <cjwatson> I don't see anything wrong with the livecd-rootfs change, FWIW
[22:06] <slangasek> also, anyone know why a couple of packages have /dropped/ from the image between 154 and 155? (parted, udisks2)
[22:06] <rsalveti> yeah, let me compare the rootfs
[22:06] <cjwatson> slangasek: those were added, not dropped
[22:06] <rsalveti> they were added
[22:07] <slangasek> oh, I can read diffs
[22:07] <cjwatson> The one dropped package was libexiv2-12, which was deliberate as part of ongoing transitions
[22:07] <slangasek> ;)
[22:07] <stgraber> slangasek: livecd-rootfs made it to the release pocket about 15min ago
[22:07] <slangasek> right
[22:07] <cjwatson> And we dealt with the gallery-app bit in advance
[22:07] <slangasek> stgraber: ok
[22:07] <cjwatson> ToyKeeper: the livefs bit of it took about the usual time
[22:08] <robru> stgraber, slangasek: if it was 15m ago, it wouldn't be in the image then. was it a fix for a critical bug? maybe that bug got us with this build?
[22:08] <stgraber> robru: no, the livecd-rootfs change is entirely unrelated to touch
[22:08] <slangasek> robru: no, they were changes unrelated to phone builds
[22:09] <rsalveti> weird, starting unity8 by hand works fine
[22:09] <robru> hm, image 154 with upstart and libstc boots fine
[22:09] <cjwatson> and then it randomly took ~70 minutes for the cdimage/system-image parts ...
[22:10] <cjwatson> oh, I see, it actually queued for a while on i386 first, probably because of the gcc upload extravaganze
[22:10] <cjwatson> *extravaganza
[22:10] <cjwatson> sigh
[22:10] <slangasek> system/etc/alternatives/arm-linux-gnueabihf_mirclientplatform_conf -> /usr/lib/arm-linux-gnueabihf/mir/clientplatform/mesa/ld.so.conf
[22:10] <cjwatson> I think "nothing to see here" on the build times
[22:10] <slangasek> is that right?
[22:10] <slangasek> it shows up in the delta, and /mesa/ in the path looks troubling
[22:10] <rsalveti> oh
[22:11] <rsalveti> that's fine, we have a script later on that sets the priority properly to libhybris
[22:12] <cjwatson> There's not much exceptional in the livefs build log, but I notice that the order in which libmirclientplatform-mesa and libmirclientplatform-android are configured has flipped
[22:12] <slangasek> robru: for reference, process here is: http://system-image.ubuntu.com/ubuntu-touch/devel-proposed/mako/index.json, scroll to the bottom, find the block that's 154->155, grab the path to the delta for the rootfs, download said file from system-image.ubuntu.com, unpack && disect
[22:12] <robru> slangasek, rsalveti, just confirmed on mako, image #154 + dist-upgrade boots fine, really strange
[22:12] <ToyKeeper> robru: Same here, fully dist-upgraded boots fine.
[22:12] <slangasek> rsalveti: what script sets the priority and when does it run?  Because this is a change in the rootfs, which certainly looks suspect to me
[22:12] <ricmm> rsalveti: this is a different config file, this is the conf for the Mir graphics backend to use
[22:12] <cjwatson> In the newer build, libmirclientplatform-mesa is configured before libmirclientplatform-android; previously it was after
[22:12] <ricmm> unrelated to the EGL backend to use
[22:12] <cjwatson> +update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/mesa/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode
[22:12] <cjwatson> -update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/android/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode
[22:13] <rsalveti> oh, right
[22:13] <cjwatson> first one configured wins?
[22:13] <ricmm> shouldnt it be the other way around
[22:13] <ricmm> heh
[22:13] <rsalveti> we had that as well, forgot about mir
[22:13] <cjwatson> so yeah, I'd echo slangasek's question
[22:13] <cjwatson> ricmm: alternatives aren't really a stable way to run anything unless you force matters - I suspect these two slaves have the same priority
[22:13] <rsalveti> the first one configured gets the priority
[22:14] <ricmm> well thats that
[22:14] <rsalveti> so I believe the seeds was forcing android by default
[22:14] <rsalveti> by forcing it as a dep
[22:14] <rsalveti> but something might have changed that
[22:14] <robru> ugh, sorry guys, timezone are defeating me and I can barely keep my eyes open. sounds like you guys have this under control anyway, fix or revert the issue, then build 156 asap. g'night!
[22:14] <cjwatson> Yeah, both 500
[22:15] <cjwatson> rsalveti: that wouldn't make any difference, they're both installed
[22:15] <cjwatson> an added dependency will at best only tweak heuristics
[22:15] <rsalveti> cjwatson: but why the android one was configured first before? luck?
[22:15] <ToyKeeper> I just tried re-linking that to the mesa version, and it still booted fine.
[22:15] <cjwatson> thing you aren't allowed to rely on, I expect
[22:15] <rsalveti> yeah, we just force the one we want in there
[22:16] <rsalveti> when both have the same priority, the first one installed will be used by default
[22:16] <cjwatson> where do you force this?
[22:16] <cjwatson> (a seed dependency isn't forcing anything)
[22:16] <ToyKeeper> How about trying this the other direction...  flashing 155 and trying to change things until it works?  I can't seem to make it fail when it started life as 154.
[22:16] <cjwatson> ToyKeeper: you might need ldconfig after changing the config file
[22:16] <cjwatson> (to make it fail)
[22:16] <rsalveti> we're not yet forcing anything, the only script we have that forces the right alternatives is for libhybris
[22:16] <rsalveti> we might need to add a new rule in there for mir
[22:17] <rsalveti> yeah, indeed, flo has it as mesa by default
[22:17] <ricmm> why did it change order in livefs?
[22:17] <rsalveti> that's the issue then, and explains why eglcreatesurface is failing
[22:18] <cjwatson> ricmm: non-determinism
[22:18] <ToyKeeper> cjwatson: You are correct, sir.  I forgot the ldconfig, and that was enough to break it.
[22:18] <cjwatson> ToyKeeper: yay
[22:19] <cjwatson> ricmm: I mean there may have been a proximate cause but it's nothing to point a finger at.  relying on anything like this is evil, bad, and wrong
[22:19] <ToyKeeper> rsalveti: So, we have confirmation on what causes the issue.
[22:19] <cjwatson> I don't immediately see anything obvious
[22:19] <ToyKeeper> Well, what causes the symptoms anyway.  Not sure about the root cause.
[22:20] <rsalveti> yeah, we need to add an explicit rule in there to force the one we want
[22:21] <slangasek> why is the mesa one present at all on the image? is removing it not the correct action here?
[22:21] <rsalveti> I don't know, need to ask the mir team
[22:22] <slangasek> we can force the alternative at build time, but this would adversely affect anything that actually wants the mesa build on there
[22:22] <ToyKeeper> If we can remove something, anything, that would be very helpful for RTM.
[22:22] <ToyKeeper> Currently, our image takes up like 99.9% of the target hardware's usable space...  so it fills up with logs in like two hours and then stops working.
[22:23] <rsalveti> slangasek: the seeds are only including libmirclientplatform-android and libmirplatformgraphics-android
[22:23] <davmor2> second boot fails too
[22:23] <davmor2> rsalveti ^
[22:23] <rsalveti> yeah, we found out why
[22:23] <rsalveti> build time issue
[22:24] <rsalveti> update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/mesa/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode
[22:24] <rsalveti> while it should be
[22:24] <ToyKeeper> davmor2: Non-determinate package config order resulted in using mesa instead of hardware.
[22:24] <rsalveti> update-alternatives: using /usr/lib/arm-linux-gnueabihf/mir/clientplatform/android/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_mirclientplatform.conf (arm-linux-gnueabihf_mirclientplatform_conf) in auto mode
[22:24] <davmor2> rsalveti: well found at least
[22:24] <ricmm> so we have kdub here
[22:25] <ricmm> maybe he can help us find out the right thing to do
[22:25] <kdub> you probably just have mesa installed on android or vice versa
[22:25] <rsalveti> libmirclient8 depends on libmirclientplatform-mesa | libmirclientplatform-android
[22:25] <ricmm> well, both are installed
[22:26] <rsalveti> seeds are only forcing libmirclientplatform-android
[22:26] <rsalveti> yeah, the mesa one is also installed, not yet sure why
[22:26] <kdub> there's also libmirplatformgraphics-{android,mesa}
[22:26] <rsalveti> we also have both installed
[22:27] <slangasek> rsalveti: because libmirclientplatform-mesa is the first alternative, and libmirclient8 is being resolved in the seed before libmirclientplatform-android so you get both
[22:27] <davmor2> well it's 23:26 here so I'll look at the image tomorrow.
[22:27] <slangasek> so the seed needs reordered so libmirclientplatform-android is seen before libmirclient8
[22:27] <rsalveti> slangasek: right
[22:27] <kdub> right, we should add runtime detection
[22:28] <rsalveti> we actually don't need the mesa one installed
[22:28] <rsalveti> if we're able to drop them, then even better
[22:29] <kdub> right, the two mesa ones are not needed on android
[22:29] <cjwatson> right, so explicit seeding might possibly work around this as you say; it doesn't explain the prior ordering, but that doesn't make it a bad thing to change now
[22:29] <cjwatson> BUT
[22:29] <cjwatson> ordering within the seed makes absolutely no difference to anything
[22:29] <slangasek> mm?
[22:30] <slangasek> that's contrary to my own past experience
[22:30] <cjwatson> well, not if using tasks
[22:30] <rsalveti> touch is only a meta package, right?
[22:30] <cjwatson> now, touch is using metapackages, so it might be more subtle, yeah
[22:30] <cjwatson> but the thing that matters will be apt's resolution order
[22:31] <rsalveti> yeah
[22:31] <cjwatson> and germinate-update-metapackage will have the effect of sorting the list when dumping it into Depends
[22:31] <rsalveti> yeah, just saw that
[22:31] <cjwatson> so I dispute that this can have had any effect in the past :)
[22:32] <slangasek> hmm
[22:32] <cjwatson> I think you're thinking of something slightly different, whereby seeding something or not can make a difference to how dependencies of other explicitly-seeded items are resolved
[22:33] <slangasek> no, that's not what I'm thinking of, though it's possible I made the whole thing up ;)
[22:33] <cjwatson> I wonder if this is something to do with the seed split
[22:33] <cjwatson> Yeah
[22:33] <slangasek> yeah, I'm wondering that as well
[22:33] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.utopic/touch-core
[22:33] <cjwatson> This would be fixed if touch-core inherited from touch-android
[22:34] <slangasek> which would be backwards of what we want
[22:34] <cjwatson> But that's sort of ... yeah
[22:34] <slangasek> so I think we need to move libmirclientplatform-android and libmirplatformgraphics-android down a layer into touch-core
[22:34] <slangasek> if libmirclient8 is already in -core, that's the right thing to do
[22:34] <cjwatson> Which kind of obviates the dichotomy between that and touch-android
[22:35] <cjwatson> I mean, it may be necessary, but I think this points to the seed split needing a rethink :-/
[22:35] <rsalveti> yeah
[22:35] <slangasek> well, is it acceptable as a quick fix to get the images back on their feet while we think that through?
[22:35] <cjwatson> Right now, neither touch-android nor touch-core depends on the other
[22:35] <cjwatson> Oh certainly
[22:35] <cjwatson> So it's not "backwards", it's duplicating it sideways
[22:36] <cjwatson> And you do want to duplicate it - if you move it, the same problem will pop up in touch-android
[22:36] <slangasek> ok
[22:36] <cjwatson> Yeah, the seed comment in touch-android right now is misinformation
[22:37] <cjwatson> "These must be specified first" - bzzt
[22:37] <slangasek> cjwatson: I swear I've seen it make a difference before, and that comment was added when they were *moved* in the original file, which did have the intended effect :)
[22:37] <cjwatson> slangasek: Oh, but changing this in the obvious way will break ubuntu-desktop-next
[22:37] <slangasek> I don't know the mechanism, but I know what I saw
[22:37] <slangasek> right
[22:38] <cjwatson> slangasek: If you see it making a difference, show me when I can investigate, since I'm interested :)
[22:38] <slangasek> OTOH, ubuntu-desktop-next is not currently in TRAINCON-0
[22:38] <cjwatson> slangasek: Could bite our tongues and use [armhf]
[22:38] <slangasek> cjwatson: won't fix the emulator image
[22:39] <cjwatson> True
[22:39] <cjwatson> I think this needs to be fixed either in mir, or perhaps in livecd-rootfs
[22:39] <cjwatson> I'm all for workarounds right now
[22:39] <rsalveti> we might just force the one we want in livecd-rootfs
[22:40] <rsalveti> mir had the mesa one as the first option to avoid breaking desktop
[22:40] <slangasek> I greatly prefer encoding as little as possible in livecd-rootfs
[22:40] <cjwatson> We could add the preferred alternatives to the add_package line
[22:40] <cjwatson> slangasek is right in general, but this is a terrible situation
[22:40] <slangasek> fwiw I've just pushed the seed change
[22:40] <rsalveti> yeah
[22:40] <Saviq> kgunn, so we're waiting for a lift of T-0?
[22:41] <slangasek> now, that requires a germinate run to propagate?
[22:41] <cjwatson> The seed change just pushes the problem back a couple of days until somebody next cares about -desktop-next
[22:41] <slangasek> yes
[22:41] <cjwatson> slangasek: No, we only care about metapackages here, so update ubuntu-touch-meta
[22:41] <slangasek> ok
[22:41] <cjwatson> You don't need an archive germinate run for that
[22:41] <cjwatson> It does require a cron job for the seed mirror
[22:41] <cjwatson> Let me poke that
[22:41] <cjwatson> (Runs every five minutes, usually it doesn't matter, but ...)
[22:43] <Saviq> kgunn, I was planning to run a gatekeeper job on silo 6 now that we have the ubuntu-touch meta in there
[22:43] <cjwatson> update-seeds run
[22:43] <Saviq> oh we don't :|
[22:44] <Saviq> robru, did you manage to upload the ubuntu-touch package to silo 6? I got an email saying signer (me) has no perms, not sure if it was from mterry's or your attempt?
[22:44] <slangasek> Saviq: so a heads-up that ubuntu-touch-meta is being uploaded imminently to unbreak images, so please resync with that
[22:44] <Saviq> slangasek, oh ok
[22:44] <slangasek> Saviq: it'll be ubuntu-touch-meta 171
[22:45] <Saviq> slangasek, how will it unbreak if qtmir isn't even in proposed?
[22:45] <slangasek> Saviq: this is for breakage unrelated to your silo
[22:45] <Saviq> slangasek, ah ok
[22:46] <Saviq> slangasek, so I'll just have to sync with the last change, that's fine
[22:46] <slangasek> Saviq: I'm letting you know that, for your silo, you will need to rebase on a version of ubuntu-touch-meta that doesn't exist yet :)
[22:46] <slangasek> yah
[22:46] <Saviq> slangasek, thanks
[22:57] <slangasek> ubuntu-touch-meta 170 uploaded
[23:00] <cjwatson> YM 171?
[23:01] <cjwatson> Apparently :)
[23:08] <slangasek> yeah :)
[23:19] <olli> are you guys expecting to see a #156 any time soon?
[23:22] <ToyKeeper> olli: I hope so, but I haven't seen the bot say it started building yet...  probably waiting on a fix first.
[23:23] <ToyKeeper> cjwatson, slangasek: What's left to do with the #155 bug before a new build can be started?
[23:24] <slangasek> ToyKeeper: ubuntu-touch-meta 171 needs to make it into utopic
[23:24] <ToyKeeper> olli: I assume the cron'd build will start in ~4 hours, if nothing else.
[23:24] <slangasek> which should happen as soon as proposed-migration runs again
[23:24] <olli> ok, I'll check in later
[23:25] <olli> thx everyone
[23:25] <slangasek> I'm not sure the current frequency of proposed-migration; I may be able to expedite that bit
[23:25] <cjwatson> It should run as fast as it can
[23:25] <slangasek> worst case is < 1h
[23:25] <slangasek> ok
[23:25] <cjwatson> Everything's slowed down by this megatransition
[23:37] <xnox> cjwatson: i believe i was the one who moved androidy things in the seed to be moved on top, as we were getting both desktopy and androidy dependencies on the images. We were getting desktopy deps pulled in first, by recursive dependenices that had "desktopy | androidy". And then later in the seed/metapackage we had "androidy" but by that time both stacks were pulled in already.
[23:37] <xnox> hence ordering "andrody" packages to the top, made them to be considered ahead of or'ed deps, and resulted in only one stack of packages to be installed.
[23:37] <cjwatson> Right, but I don't see any way for seed order to translate into anything that matters
[23:38] <cjwatson> I understand what you were trying to do, but I don't see the mechanism
[23:38] <xnox> it was in the germinate output.
[23:38] <cjwatson> But germinate first marks all the explicit entries in a seed as to-be-included, and only then proceeds to resolve dependencies
[23:39] <cjwatson> The only way for order within a seed to matter should be if you try to do something unwise like explicitly seeding a virtual package
[23:40] <cjwatson> (This matches apt's algorithm for the list of things you pass to apt-get install, after task expansion)
[23:52] <xnox> cjwatson: i think there is fishy things going on. So the problem as far as i remember is that both libmirplatfrom*mesa and -android variants provide the same shared library, at the same priority, which is updated with update-alternatives. And depending on the order postinsts are run, if "libmirplatformgraphics-android:armhf" is configured first it's all good, otherwise "libmirplatformgraphics-mesa:armhf" is configure and one has totally broken black
[23:52] <xnox>  screen image.
[23:53] <xnox> at the time, i believe we moved the seed around but also changed the order of the deps in most package to list /consistently/ desktopy variant first (to not break people trying out core apps / mir et.al.)
[23:54] <xnox> as well as move the seed at the top, with the hope of getting android stack configure first, and hence provide the right shared libraries.
[23:54]  * ogra_ thinks we should just put the right one into the live-build config and be done 
[23:54] <xnox> the germinate issue is that both stacks are seeded, although they shouldn't.
[23:55] <xnox> livecd-rootfs bug is that both stacks are installed, despite only one seeded explicitly.
[23:55] <xnox> there were also mir bugs, where they linked/dlopened/depend on both stacks (i failed at tracking that)
[23:58] <cjwatson> xnox: Right, all I'm saying is that I don't see any mechanism whereby the seed ordering change could have had the slightest effect.  I'm quite prepared to believe that changes elsewhere had an effect
[23:58] <cjwatson> ogra_: That does seem the simplest approach to me, but slangasek has (understandable) objections to that approach
[23:58] <ogra_> well, what he uploaded now will force the android layer into desktop-next
[23:59] <slangasek> yes
[23:59] <cjwatson> Which I already pointed out, and we accepted for now
[23:59] <slangasek> we need to unblock the phone immediately, we'll deal with the fallout afterwards
[23:59] <ogra_> i think they shouldnt be seeded at all and livecd-rootf should add the right oone for the respecive image