[01:45] <mwhudson> hey uh, do we make an armhf image that contains a kernel that can work on midway?
[02:53] <infinity> mwhudson: Yes.
[02:53] <infinity> mwhudson: If by "image" you mean "d-i netboot images".
[02:54] <infinity> mwhudson: http://ports.ubuntu.com/ubuntu-ports/dists/trusty/main/installer-armhf/current/images/generic-lpae/netboot/
[02:54] <mwhudson> infinity: yeah, i think i was being confused
[02:55] <mwhudson> have i mentioned my deep and abiding love for uboot recently
[02:56] <infinity> mwhudson: I sense sarcasm.
[02:57] <mwhudson> very perceptive of you
[03:02] <mwhudson> argh!
[03:02] <mwhudson> midway just has broken uEnv.txt support
[03:02] <mwhudson> ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt...
[03:03] <mwhudson> that explains the Unknown command 'Executing' - try 'help'
[03:03] <mwhudson>  message
[03:09] <infinity> mwhudson: Hrm, I've never had any issues on the midways I've played with.
[03:09] <infinity> mwhudson: Maybe I don't use uEnv?  I dunno.
[03:09] <mwhudson> probably not
[03:10] <mwhudson> maybe this one has out of date firmware, i dunno
[03:10] <mwhudson> just means i need to re-remember how to use boot.scr
[03:39] <nathaneltitane> hello amigos
[03:40] <nathaneltitane> i've set up a build dir to generate my first deb package (from source), after running  dpkg-buildpackage -rfakeroot i get an error message. it complains that the Package field is missing in the control file
[03:40] <nathaneltitane> any idea?
[04:12] <infinity> slangasek, xnox: heads up, lennart plans to remove udev's netlink interface, effectively breaking udev on all !systemd without people fixing things: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
[04:18] <lifeless> yay?
[05:22] <pitti> Good morning
[06:15] <dholbach> good morning
[07:58] <ogra_> pitti, thanks for the suggestion !! ... do you know if we have a tool for editing thises options or should i "just sed from postinst" ?
[07:58] <pitti> ogra_: no, we can't change it in a package, it's a conffile
[07:58] <pitti> so at most during an image build
[07:58] <ogra_> thats what i feared
[07:58] <pitti> certainly not ideal
[07:59] <pitti> ogra_: i. e. I was mostly suggesting that as a quick fix if you want to unbreak images, not as a long-term solution
[07:59] <pitti> should have mentioned that in the mail, sorry
[08:00] <ogra_> well, the only "proper" longter solution is to create a single package for a single file i think
[08:00] <pitti> ogra_: perhaps an even better thing to do would be to change /etc/X11/Xsession.d/75dbus_dbus-launch to not run $DBUSLAUNCH if [ -n "$DBUS_SESSION_BUS_ADDRESS" ]
[08:00] <ogra_> which is ugly as well but less intrusive
[08:00] <pitti> ogra_: i. e. if there already is a session bus, started from upstart or whatever
[08:00] <ogra_> well, this one seems to be actually get started by the first gdbus call
[08:01] <pitti> ogra_: gdbus runs dbus-launch if there's no $DBUS_SESSION_BUS_ADDRESS, that seems like a separate issue
[08:01] <pitti> ogra_: what is supposed to start "the" session bus on the phone?
[08:01] <pitti> it obviously wasn't 75dbus_dbus-launch as we didn't install that until yesterday
[08:02] <ogra_> pitti, no idea how it looks like in the new split greeter world ... usually we have an upstart job starting it
[08:03] <ogra_> but i dont think lightdm processes a full session startup in upstart
[08:03] <ogra_> at least not in our setup
[08:03] <ogra_> (in our new setup)
[08:04] <pitti> ogra_: so I think the first thing to do is to get some agreement what starts the session bus -- lightdm, 75dbus_dbus-launch, 00upstart (through a session upstart job), or something else
[08:04] <ogra_> mterry did a lot of complex things to make the lightdm dbus have access to the user dbuses it seems
[08:04] <pitti> ogra_: aside from that, I think changing 75dbus_dbus-launch to not do anything if there already is a session bus is a sensible and safe thing to do
[08:04] <ogra_> yeah
[08:05] <ogra_> we definitely dont want to have two per session :) (two for lightdm, two for the phablet user)
[08:05] <pitti> ogra_: yes, absolutely; two session buses will break $world
[08:06] <ogra_> right
[08:06] <pitti> if different processes use differetn addresses (otherwise it's just a waste)
[08:06] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/ .... it happens pretty visible since image 59 :)
[08:07] <ogra_> but as i said, mike does some trickery to get the buses talk to each other it seems
[08:07] <ogra_> so that phone calls get through etc
[08:09] <pitti> ogra_: can you easily test http://paste.ubuntu.com/7578684/ ?
[08:10] <ogra_> will do ... i dont have my test device near ... but in 10min or so
[08:26] <ogra_> pitti, doesnt seem to help
[08:26] <pitti> you still get two buses?
[08:26] <ogra_> root@ubuntu-phablet:~# ps aux|grep dbus |grep session|grep -v upstart|wc -l
[08:26] <ogra_> 4
[08:26] <pitti> ogra_: that means that 75dbus_dbus-launch comes first and the second one is started after that
[08:26] <ogra_> which is weird
[08:27] <ogra_> pitti, i see the same socket twice as well http://paste.ubuntu.com/7578759/
[08:28] <pitti> ogra_: right, one for lightdm, one for phablet
[08:28] <ogra_> look at the two phablet ones
[08:28] <ogra_> they are identical and use the same address
[08:28] <pitti> ogra_: yeah, I know, looks odd; can you grep for dbus-launch?
[08:28] <ogra_> not there
[08:29] <pitti> ogra_: was it there without the Xsession.d change?
[08:29] <ogra_> yes
[08:29] <pitti> if yes, that change at least helped a bit; if no, dbus-x11 wasn't the reason
[08:30] <ogra_> and before split greeter we had exactly one dbus-daemon per session
[08:30] <pitti> I have three in my desktop session, presumably it forks internally
[08:30] <pitti> martin    1648  0.0  0.0  39240   324 ?        Ss   07:18   0:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
[08:30] <pitti> martin    1660  0.0  0.0  41444  4008 ?        Ss   07:18   0:04 dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-4jEVwkHdJv
[08:30] <pitti> martin    1806  0.0  0.0  39504  3492 ?        S    07:18   0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
[08:30] <ogra_> oh. ok
[08:30] <pitti> ogra_: but not two with the same --address thing
[08:31] <ogra_> right
[08:31] <pitti> ogra_: on the phone we probably don't have the a11y bus, so we can ignore that
[08:31] <ogra_> right
[08:32] <pitti> 1660 is started by session upstart (lightdm -> init -> dbus-daemon (1660)
[08:32] <pitti> 1648 isn't, not sure where that comes from, but the --print-address sounds like it's coming from dbus-launch
[08:37] <ogra_> pitti, could you upload the dbus-x11 fix in any case ?
[08:37] <pitti> ogra_: sure
[08:37] <ogra_> (since i dont see dbus-launch it seems to have worked)
[08:37] <pitti> ogra_: was that tracked as a bug, or just on u-phone@ so far?
[08:38] <ogra_> just the ML
[08:38] <pitti> ack, thanks
[08:41] <pitti> ogra_: test-building now, will test on desktop before I upload
[08:41] <pitti> (just to make double-suree)
[08:41] <ogra_> ok
[08:42] <pitti> I still wish we could avoid all teh Xsession.d/ legacy and shellery on the phone
[08:43] <pitti> it's not even running X :)
[08:46] <ogra_> we will at some point :)
[08:47] <xnox> pitti: i did remove dbus-launch from ubuntu-touch images. it shouldn't be seeded on touch images at all...
[08:47] <xnox> pitti: any clue as to why it was pulled back in?
[08:47] <xnox> sorry, i mean dbus-x11
[08:47] <pitti> xnox: no, I don't know why it came in there
[08:47] <ogra_> xnox, split greeter uses gdbus ... which needs dbus-launch
[08:48] <ogra_> xnox, but sadly also ships the Xsession.d script that fires up a second session bus
[08:48] <pitti> no, gdbus doesn't *need* dbus-launch
[08:48] <ogra_> well, *uses*
[08:48] <ogra_> :)
[08:48] <pitti> it really shouldn't
[08:48] <pitti> our session should already have a bus
[08:48] <pitti> if a process doesn't have $DBUS_SESSION_BUS_ADDRESS, that's a bug in passing the env variables or starting the bus too late
[08:49] <ogra_> well, lightdm seems to spawn one thats not upstart driven
[08:49] <ogra_> xnox, so its a new dependency of the new greeter session implementation
[08:50] <pitti> so the dbus-x11 Xsession.d/ change is a cheap and harmless help for that, but it in no way address the actual bug
[08:50] <ogra_> if it even is a bug
[08:50] <xnox> ogra_: that dependency is black-listed from the seed =)
[08:50] <ogra_> we verified yesterday that it fixed the AP issues
[08:50] <xnox> ogra_: I guess we didn't enforce it.
[08:50] <ogra_> xnox, talk to the greeter team ...
[08:51] <xnox> ogra_: i'm talking to landing team / person in charge of the seed =)
[08:51] <xnox> ogra_: dev teams will always try to use haskell & what not =)
[08:52] <ogra_> xnox, split greeter is the base for a ton of other features, feel free to work with mterry on improving it (and file a bug) but we need to land this if any possible so others can move on with their dependant work
[08:52] <xnox> ogra_: is there no featureflag to run split greeter in non-split mode?
[08:52] <ogra_> not that i know of
[08:54] <ogra_> and it is also pretty complicated ... making sure phone calls to the users get handled by the greeter, you can start apps in the user session from the locked greeter etc ... the feature set is huge and scary :)
[08:58] <sil2100> ogra_: btw. do you remember who robru poked to ACK all the crazy packaging changes of the greeter landing?
[08:58] <ogra_> xnox, if you like getting scared in the morning ... https://code.launchpad.net/~mterry/unity8/split/+merge/213149 (there are about ten other packages with changes but this is the core)
[08:59] <ogra_> sil2100, no, probably me ... doesnt the train record that ? i know rob always puts my name into the lander field or some such when i ack something
[09:02] <ogra_> (i have seen him putting it in a jenkins form)
[09:05] <ogra_> xnox, my theory is that dropping dbus-launch would need a re-org of the unity8-greeter-wrapper script (so that the first gdbus --session call happens after upstart ran init --user for lightdm ...) but i wont touch that code with the author not around
[09:15] <sil2100> ogra_: let's hope mterry will be around today
[09:20] <ogra_> xnox, Saviq, pitti, sil2100 bug 1325882 ... i think thats our final solution
[09:20] <ogra_> (but mterry needs to agree)
[09:20] <pitti> ogra_: yes, sounds good to me (i. e. fix the startup ordering)
[09:21] <Saviq> ogra_, yeah, I thought that's what was happening..
[09:21] <ogra_> great :)
[09:21]  * ogra_ likes agreement
[09:22] <ogra_> i see dbus already hit proposed
[09:22]  * ogra_ prepeares the accompanying unity8 upload
[09:23] <pitti> ogra_: FWIW, you don't really need that dbus on a new image, it's mostly to make debugging less confusing
[09:23] <pitti> and it'll be stuck in -proposed until I fix the tests for udisks2 in -proposed (which broke due to enabling logind session tracking)
[09:24] <Saviq> ogra_, if I agree, do you still need mterry's agreement? shall I push an MP?
[09:24] <ogra_> pitti, crap
[09:25] <ogra_> Saviq, well, given the above comment from pitti it is unlikely that we can make our 12:00UTC deadline ... so yes, go ahead ... cant become worse, can it ?
[09:27] <Saviq> ogra_, ;)
[09:27] <ogra_> sil2100, keep a silo ready for Saviq ^^^;)
[09:28] <pitti> ogra_: why do you need that fix urgently? (if so, release team can fast-track it)
[09:29] <ogra_> pitti, we are in TRAINCON-0 mode ... which means nothing can land (except some select bits) until we have resolved the major issue ... if we cant fix it in a given timeframe we have to roll back the whole landing
[09:30] <ogra_> the timeframe we have set ourselves for this one is 12:00 UTC ...
[09:30] <ogra_> so that we can be sure we can drop TRAINCON-0 in any case tonight
[09:30] <pitti> ogra_: ok, but I still don't understand how that dbus change actually fixes the bug, or why fixing the ordering in bug 1325882 would need that dbus fix
[09:30] <ogra_> by either having a proper fix or by rolling back all packages that make up this landing
[09:31] <ogra_> pitti, the re-ordering wont since we drop all deps on dbus-x11 with that
[09:31] <ogra_> pitti, if we would keep dbus-x11 and *not* re-order we would need your fix though
[09:32] <sil2100> o/
[09:32] <ogra_> pitti, with Saviq offering to take the risk of the re-order we get around using dbus-x11 at all ... and make xnox happy too ;)
[09:33] <pitti> ah, ok; it seems a bit curious that this dbus-x11 fix would actually fix things
[09:34] <ogra_> well, the dbus-launch call for gdbus makes things currently work
[09:34] <ogra_> s/for/from/
[09:34] <pitti> hm, "work"
[09:35] <ogra_> yeah
[09:35] <pitti> it still means that this spawns another bus which no othe process wants..
[09:35] <ogra_> well, "not fail" is probably better :)
[09:35] <ogra_> no, it spawns *the* session dbus ... the upstart job wont fire if there is one allready
[09:36] <ogra_> but that session dbus wont use the upstart defined options for the daemon etc
[09:36] <pitti> urgh :) yes, then Houston we have a problem
[09:36] <pitti> because no other processes will know about that one
[09:36] <ogra_> right
[09:36] <ogra_> well, the indicators do ... they dont start without dbus-launch available
[09:36] <ogra_> (and other weird things happen)
[09:37] <pitti> so we should not install dbus-x11 so that we actually see which processes try to call dbus-launch (and then LART them)
[09:37] <pitti> DON'T *spank" START *spank* A NEW *spank* BUS! *spank*
[09:38] <ogra_> right, thats what Saviq will now implement ...
[09:38] <ogra_> in the hope that it works
[09:38] <Saviq> ogra_, https://code.launchpad.net/~unity-team/unity8/resync-distro-split/+merge/221845 + https://code.launchpad.net/~unity-team/unity8/fix-split-dbus/+merge/221847
[09:39]  * sil2100 keeps his fingers crossed
[09:39] <ogra_> if not we'll have to roll back and leave it to mterry to come up with a proper solution
[09:41] <ogra_> Saviq, both acked ... (with a comment on the second)
[09:42] <Saviq> ogra_, yeah, added telepathy-ofono test plan to the landing
[09:42] <Saviq> sil2100, line 36 is ready for you
[09:43] <sil2100> Saviq: excellent! The reorder seems ok...
[09:43] <sil2100> Let me assign
[09:43] <sil2100> Saviq: silo 20 for you
[09:44] <sil2100> Let's get it building and tested o/
[09:44] <ogra_> ++
[09:44] <Saviq> builds
[09:44] <ogra_> and then get an image that fixes our world ;)
[09:45] <rbasak> @pilot in
[09:49] <sil2100> ogra_, Saviq: let's hope that it does!
[09:49] <Saviq> ogra_, hmm... so without dbus-x11 it's upstart that will start dbus, and indicators in greeter should then work again, 'cause the gdbus → dbus-launch *before* upstart caused things to mess around?
[09:50] <ogra_> it should
[09:50] <Saviq> ok it's an easy thing to check on 61, /me tries
[09:50] <ogra_> let me quickly try your change on my flo
[09:52] <Saviq> but yeah, in any case, the fact that gdbus just launches dbus... nasty
[09:52] <Saviq> ogra_, looks legit!
[09:52] <ogra_> yay
[09:53]  * ogra_ reboots with the change 
[09:53] <pitti> well, it does that if tehre is no $DBUS_SESSION_BUS_ADDRESS -- not having that is the actual bug
[09:54] <ogra_> Saviq, no indicators for me ... are you sure you removed dbus-x11 ?
[09:54] <ogra_> (i purged it)
[09:54] <Saviq> ogra_, I just have 61, so no dbus-x11, never installed it
[09:54] <ogra_> hm
[09:54] <Saviq> oh wait
[09:54] <ogra_> let me reflash then :/
[09:55] <Saviq> ogra_, no, I have it here
[09:55] <ogra_> aha
[09:55] <Saviq> somehow
[09:55] <ogra_> so that doesnt really fix it
[09:55] <rbasak> mitya57: for https://code.launchpad.net/~chris-good/ubuntu/trusty/netkit-rwall/fix-for-1277981/+merge/216563, it looks like the source package isn't version 3.0, so how would you expect a dep3 patch in that case? I don't see any patch system in use.
[09:56] <Saviq> :|
[09:56] <rbasak> I was looking at https://bugs.launchpad.net/ubuntu/+source/netkit-rwall/+bug/1277981 but just realised it's the same bug.
[09:56] <ogra_> Saviq, trying something ...
[09:57] <Saviq> ogra_, so yeah, no dice here either :|
[09:57] <mitya57> rbasak: He could switch to 3.0, or use dh_quilt, or just add the patch to debian/patches to indicate that it is a patch
[09:58] <mitya57> also, three changelog entries for one upload looks like an overkill
[09:59] <popey> is there an easy way for me to do "apt-get source libdbus-cpp3=utopic" for example where I am on trusty?
[09:59] <popey> (i.e. I want to get the source package from utopic version of a package, on my trusty system)
[10:00] <Saviq> popey, download off of launchpad easiest probably, otherwise you'd need to add utopic repos to your system
[10:00] <popey> yeah, figured it was going to be that way, thanks
[10:02] <maxb> popey: use pull-lp-source from ubuntu-dev-tools
[10:02] <popey> neat!
[10:02] <popey> thanks
[10:05] <sil2100> ;/
[10:06] <sil2100> ogra_: what are you trying now?
[10:06] <ogra_> sil2100, a few other things ... gimme a bit
[10:08] <ogra_> Saviq, so even when adding "initctl start dbus" to the script (and actually getting a proper dbus) i dont get indicators ... looks almost like greeter-started never gets emitted
[10:09] <Saviq> ogra_, well, don't they crash for you?
[10:09] <ogra_> Saviq, they do
[10:09] <Saviq> ogra_, so they are getting triggered, but their env doesn't have the dbus details, I'd say
[10:09] <rbasak> mitya57: he's not the DM for the package though. Isn't adding a patch system in an Ubuntu delta a little invasive? I agree that he should send the patch upstream or get it in through Debian though. No need to introduce an Ubuntu delta for this.
[10:10] <ogra_> Saviq, right, looking into that atm
[10:10] <rbasak> mitya57: I agree about the excessive changelog, though I assume that he's just unfamiliar with tooling. I'd have just fixed that up had I uploaded (which I won't)
[10:10] <Saviq> ogra_, it's like upstart a) never started dbus or b) didn't put their details into its global env
[10:10] <rbasak> mitya57: (also, he needs to fix Utopic first now. Easier to just fix Debian)
[10:11] <mitya57> I agree.
[10:13] <ogra_> Saviq, right, i have code in place here that calls initctl start dbus now ... pulls the address from it and exports
[10:13] <ogra_> lets see
[10:13] <ogra_> \o/
[10:13]  * ogra_ got indicators 
[10:14] <ogra_> that looks good !
[10:14] <sil2100> \o/
[10:15] <Saviq> ogra_, just push under my MP
[10:15] <Saviq> ogra_, it's ~unity-team, so you should be able to
[10:15] <Saviq> ogra_, or well, gimme a diff and I will
[10:15] <Saviq> (test and push)
[10:16] <ogra_> Saviq, paste.ubuntu.com/7579305/ ... preparing an MP
[10:17] <Saviq> ogra_, I'll just add it to mine, let's not break things up in multiple MPs
[10:17] <ogra_> ok
[10:18] <sil2100> Damn, hackish
[10:18] <Saviq> ogra_, wonder if we should use set_greeter_var for it, though
[10:18] <BluesKaj> 'Morning folks
[10:18] <Saviq> ogra_, or erm, put it on the upstart env
[10:18] <ogra_> sil2100, i'll leave the proper cleanup to mterry :P
[10:18] <sil2100> ogra_: +1 ;p
[10:18] <Saviq> ogra_, or does "start dbus" take care of it already?
[10:19] <ogra_> Saviq, well, calling start dbus is the first wrong thing ... the rest is just fallout :P
[10:19] <ogra_> Saviq, it doesnt give us the address and doesnt export it either ... but luckily stores in that file that i source
[10:20] <ogra_> its a hack on top of a hack
[10:20] <ogra_> but seems to work fine at least
[10:20] <Saviq> mhm
[10:21] <ogra_> this needs some serious re-work to be right
[10:22] <ogra_> in fact i think much of it should move into proper upstart jobs and get the right ordering
[10:26]  * ogra_ looks if it is possible to pull the address more elegantly out of the upstart session global vars instead
[10:27] <Saviq> ogra_, well, upstart get-env?
[10:27] <ogra_> right
[10:27] <ogra_> thats what i'm trying here
[10:27] <ogra_> but iits a bit fiddly
[10:30] <ogra_> Saviq,
[10:30] <ogra_> /sbin/initctl start dbus
[10:30] <ogra_> export DBUS_SESSION_BUS_ADDRESS="$(/sbin/initctl get-env DBUS_SESSION_BUS_ADDRESS)"
[10:30] <ogra_> drop the file ... this works too
[10:31] <ogra_> one hack less
[10:31] <ogra_> hmm
[10:31] <xnox> Saviq: i've updated https://wiki.ubuntu.com/Touch/CrossCompile with some notes from the session. Is there anything missing? And where should I circulate it, such that people from the session see it?
[10:32] <xnox> Saviq: also, I didn't yet find where unity-scope-go bindings in cgo are, and trying to cross-compile those. Can you please remind me who can point me to them?
[10:34] <Saviq> xnox, jamesh
[10:34] <Saviq> xnox, and ubuntu-phone@ would definitely be a place to post this
[10:35] <Saviq> xnox, there's some common data in https://wiki.ubuntu.com/SimpleSbuild too, maybe we should combine those
[10:35] <Saviq> grr
[10:37] <Saviq> ogra_, kicked another build in the silo with your fix, then
[10:37] <ogra_> yay
[10:37] <sil2100> Saviq: \o/
[10:37]  * Saviq tries to repro the split bug
[10:37] <ogra_> let me re-flash my device so i can test on a virgin install
[10:38] <sil2100> Now it looks so much nicer - although still a bit hackish :)
[10:39] <ogra_> sil2100, yeah, the starting of dbus should not be needed ... but init is started with --no-startup-event which makes the dbus upstart job not being called
[10:40] <Saviq> ogra_, does mtp-server respawns here constantly :|
[10:40] <ogra_> (since it is "start on startup")
[10:40] <Saviq> -does
[10:40] <ogra_> not for me
[10:40] <Saviq> under the greeter session (where it should probably never start in the first place)
[10:40] <ogra_> yeah
[10:40] <ogra_> why doesnt it do that here
[10:41] <ogra_> do you have a porper cable in use ? i'm not sure this is related
[10:41] <ogra_> (sadly i'm flashing now so my device is taken for the next 12-15 min)
[10:42] <Saviq> ogra_, I can access it fine
[10:42] <Saviq> ogra_, but there's the user one running (working), and then the greeter one respawning and crashing in a loop
[10:42] <Saviq> which kind of makes sense
[10:42] <Saviq> given it's
[10:42] <Saviq> start on :sys:android-mtp-on or :sys:android-usb-connected
[10:43] <ogra_> hmpf
[10:44] <ogra_> how can i uniquely know i'm in a lightdm session now ...
[10:46] <ogra_> Saviq, "start on :sys:android-mtp-on or :sys:android-usb-connected and not unity8-greeter-started"
[10:46] <ogra_> Saviq, try chaning it like that and see if the user mtp-server still starts fine
[10:46] <ogra_> hmm, i think that needs some brackets to group the old arg
[10:47] <ogra_> Saviq, "start on (:sys:android-mtp-on or :sys:android-usb-connected) and not unity8-greeter-started"
[10:47] <ogra_> more like that i guess
[10:47] <Saviq> ogra_, ok, I'm starting to feel like we're not progressing at all...
[10:47] <ogra_> the unity8-greeter-started shouldnt be in the users env
[10:47] <ogra_> Saviq, why is that ?
[10:48] <sil2100> There's still some time, we can push the revert if this doesn't work
[10:48] <ogra_> right
[10:48]  * sil2100 upgrades his phone
[10:49]  * ogra_ gets some breakfast while teh flo downloads 62 ... 
[10:49] <ogra_> Saviq, wht i dont get is why mtp didnt start before for you but now does ... it isnt related to dbus in any way
[10:50] <ogra_> its not like we changed anything else
[10:50] <ogra_> execpt for the dbus bits
[10:51] <Saviq> ogra_, no mtp at all now
[10:52]  * Saviq doesn't get how that could work... they're events, not states, or am I dumb?
[10:55] <ogra_> Saviq, well, i dont get why you have it all of a sudden
[10:55]  * Saviq reflashes
[10:55] <xnox> Saviq: correct, upstart only has events. There is a separate job which emits yeah/nay events (android-mtp-on & android-mtp-off events)
[10:56] <xnox> Saviq: on system level, which are re-emitted into session init as "sys:android-mtp-on" for example
[10:56] <ogra_> right
[10:56] <Saviq> xnox, sure
[10:56] <Saviq> start on (:sys:android-mtp-on or :sys:android-usb-connected) and not unity8-greeter-started
[10:56] <Saviq> that I don't get
[10:56] <xnox> Saviq: it's a fake approximation of the state =)
[10:56] <ogra_> there is another system job that emits android-mtp-on if the android property is set
[10:57]  * ogra_ wrote both these jobs 
[10:57] <xnox> Saviq: the first two are emitted, however, I don't know who/where/what emits "unity8-greeter-started" or how "not" works.
[10:57] <xnox> Saviq: i don't think that's valid job.
[10:57] <ogra_> it just hands through the porperty to upstart
[10:57] <ogra_> xnox, "unity8-greeter-started" is emitted by the new greeter
[10:58] <Saviq> ogra_, oh so it's a property or an event?
[10:58] <ogra_> which should only spawn inside the lightdm session
[10:58] <xnox> ogra_: you apear to be waiting for event called "not" though.
[10:58] <ogra_> Saviq, we have an upstart property watcher ... the property is watched ... on change it emits the event
[10:58] <xnox> ogra_: well not you, but that job.
[10:58] <xnox> start on condition
[10:58] <ogra_> eeek
[10:58] <ogra_> indeed
[10:59] <Saviq> so that explains why it didn't start at all
[10:59] <ogra_> xnox, well, we only want mtp if that event doesnt even exist
[10:59] <xnox> ogra_: not possible =)
[10:59] <ogra_> or rather if the greeter doesnt run in our session
[10:59] <ogra_> right
[10:59] <ogra_> :/
[10:59] <xnox> ogra_: pre-start script
[10:59] <ogra_> there must be sommething we can check for thoush
[11:00] <ogra_> *though
[11:00] <xnox> ! status unity8-greeter-started || {stop; exit 0}
[11:00] <xnox> end script
[11:00]  * ogra_ idly waits for his device to finish flashing
[11:00] <xnox> ogra_: if that's a job.
[11:00] <xnox> ogra_: but it's not a job.
[11:00] <ogra_> well, an event
[11:00] <xnox> ogra_: check for the job presence instead.....
[11:00] <ogra_> it has a sub-job we could look for
[11:00] <doko> barry, what is the status of Debian #749692?
[11:00] <ogra_> right
[11:00] <ogra_> that was my initial idea
[11:01] <xnox> ogra_: we don't at all store state, thus one has no idea if an event fired in the past and is now gone. Nor one can negate, future events.
[11:02] <ogra_> right, i think your pre-start thing will work
[11:02] <Saviq> ↑ yeah, that's why I didn't understand it...
[11:02] <ogra_> Saviq, add a pre-start script
[11:02] <ogra_> ! status unity8-greeter-started || {stop; exit 0}
[11:02] <Saviq> let's see, flashing now
[11:02] <pitti> jodh: hey James, thanks for the procenv fix; need a sponsor for Debian?
[11:03] <xnox> ogra_: is unity8-greeter-started an actual job?
[11:03] <Saviq> no
[11:03] <ogra_> err, no, one sec ...
[11:03] <xnox> ogra_: status can only be run on jobs, not events....
[11:03] <ogra_> there is an actual job though
[11:03] <xnox> ogra_: see upstart cookbook on how to make mutually exclusive jobs.
[11:03] <ogra_> unity8-greeter-init
[11:03] <jodh> pitti: thanks for the offer, but I have upload rights for procenv (it's currently building on their buildd's).
[11:03] <xnox> ogra_: there is a snippet
[11:03] <ogra_> Saviq, use that
[11:04] <pitti> jodh: FYI, I have some improvements for the sbuild test to automatically use the host's apt proxy, so that it runs much much faster locally; I'll test/upload this once procenv actually becomes buildable again
[11:04] <pitti> jodh: ah, sweet; thanks
[11:04] <xnox> Saviq: ogra_: once you have a merge proposal, I'd offer to review it.
[11:04] <ogra_> my prob is that i cant reproduce it at all ... and dont get how Saviq got to that state
[11:05] <Saviq> ogra_, it does make sense, though - there's only one usb cable, who gets it?
[11:05] <ogra_> the system first of all :)
[11:05] <Saviq> (well, the active session, probably)
[11:05] <jodh> pitti: thanks. I'd like to understand a bit more about why 3.15 dropped that feature, but I plan to add extra procenv guards to avoid such a problem happening again.
[11:05] <ogra_> right
[11:05] <ogra_> it seems to be a race i dont see on flo
[11:05] <Saviq> yeah, I'm on mako
[11:05] <ogra_> right
[11:06] <ogra_> phablet@ubuntu-phablet:~$ initctl status unity8-greeter-init
[11:06] <ogra_> unity8-greeter-init stop/waiting
[11:06] <ogra_> so there we go
[11:07] <Saviq> ogra_, that's a task :|
[11:07] <ogra_> Saviq,  ! status unity8-greeter-init  || {stop; exit 0}
[11:07] <ogra_> thats what you want in pre-start
[11:07] <ogra_> in the mtp-server job
[11:07] <ogra_> try it
[11:07] <Saviq> k
[11:08] <ogra_> hmm, probably we dont want the negation
[11:08]  * ogra_ is confused 
[11:09] <Saviq> I don't really think this will help, it's a task, it just goes to stopped straight away
[11:10] <ogra_> sigh
[11:10] <ogra_> Saviq, haha ...
[11:11] <ogra_> how about "and started unity8" ;)
[11:11] <ogra_> lightdm should never start that
[11:12] <ogra_> since the greeter is its shell
[11:13] <Saviq> ogra_, USER != lightdm?
[11:13] <ogra_> oh !
[11:13] <Saviq> that sounds about right
[11:13] <ogra_> yeah, that should work too
[11:20]  * ogra_ tests silo 
[11:20] <Saviq> what am I doing wrong?!? http://pastebin.ubuntu.com/7579709/
[11:20] <Saviq> /bin/sh: 1: [: lightdm: unexpected operator
[11:20] <Saviq> ah sh?
[11:20] <ogra_> yeah
[11:21] <ogra_> POSIX ... drop one =
[11:21] <Saviq> ok good
[11:22] <ogra_> silo confirmed to work fine
[11:22] <Saviq> ogra_, on that note http://paste.ubuntu.com/7579717/
[11:22] <Saviq> the list of things running in the greeter session, we should probably strip some of the
[11:22] <Saviq> m
[11:23] <Saviq> but yeah, not necessarily now
[11:23] <ogra_> yeah, looks ok for now
[11:26] <ogra_> xnox, http://paste.ubuntu.com/7579742/
[11:26] <ogra_> please take a look
[11:27] <ogra_> Saviq, i guess i need to upload that, right ?
[11:27] <ogra_> (core dev ... etc)
[11:27] <sil2100> hm, I wonder why I can't upgrade to the unity8 from the silo PPA
[11:27] <ogra_> sil2100, i just pulled the debs and did a dpkg -i *.deb
[11:27] <ogra_> worked fine
[11:28] <sil2100> Yeah, will try that as well then
[11:28] <sil2100> A bit strange though
[11:28] <ogra_> you need unity8-common from the i386 build ...
[11:28] <Saviq> ogra_, that broke user mtp for me (pre-start needs exit 0 always?)
[11:28] <ogra_> Saviq, err
[11:28] <ogra_> no, the code is wrong
[11:28] <ogra_> needs to use curly brackets
[11:28] <ogra_> sorry, fixing
[11:29] <ogra_> another bashism :)
[11:30] <ogra_> Saviq, xnox http://paste.ubuntu.com/7579772/
[11:30] <ogra_> that should work
[11:31] <ogra_> hi mterry btw ...
[11:31] <mterry> ogra_, hello!  I just read the thread
[11:31] <sil2100> mterry: !
[11:31] <mterry> Am responding to some of the bugs
[11:31] <sil2100> mterry: FINALLY!
[11:31] <ogra_> hehe, yeah ... the world fell apart as expected :)
[11:32] <mterry> ogra_, sil2100: the dbus thing doesn't make any sense
[11:32] <ogra_> mterry, we have it fixed now
[11:32] <Saviq> ogra_, can't say that it does...
[11:32] <Saviq> ogra_, job failed to start
[11:32] <ogra_> mterry, but another issue with mtp showed up
[11:32] <sil2100> mterry: ogra_ and Saviq are doing a nice job of trying to workaround/fix the issues, but I guess someone knowledgable in the very core would be helpful
[11:32] <mterry> ogra_, sil2100: /usr/lib/lightdm/lightdm-greeter-session launches dbus for the greeter, upstart does it for the session
[11:32] <ogra_> Saviq, sigh
[11:33] <ogra_> mterry, only if youhave dbus-x11 installed which spawns multiple session dbuses becaause Xsession.d scripts get processed too
[11:33] <ogra_> (and drags in X11 deps ... )
[11:33] <Saviq> ogra_, http://pastebin.ubuntu.com/7579797/ works for me
[11:33] <ogra_> Saviq, hmm, k
[11:34] <Saviq> +/- ;
[11:34] <ogra_> Saviq, can you try without the exit 0
[11:34] <ogra_> that should be a no-op
[11:34] <mterry> ogra_, why does the Xsession.d script do that in Mir?  And why didn't we see that in testing I wonder
[11:35] <Saviq> mterry, that's a great question indeed
[11:35] <ogra_> mterry, locally run AP tests work fine ... in the lab AP somehow connects to the extra spawned dbus it seems
[11:35] <mterry> woah
[11:35] <ogra_> so you didnt see that ... but in any case running multiple session buses is wrong
[11:35] <ogra_> and for that we have a fix
[11:36] <mterry> But I've also done plenty of ps aux | greps in my testing.  I feel like I would have noticed a whole extra dbus, not to mention the problems that would cause the greeter session
[11:36] <ogra_> mterry, what i find more interesting is why didnt you see the mtp issue
[11:36] <ogra_> your desktop should have been plastered with mtp errors
[11:36] <mterry> ogra_, what's the mtp issue?
[11:36] <ogra_> mterry, it starts for lightdm
[11:36] <ogra_> and when the user one starts it clashes
[11:36] <ogra_> and crashes
[11:36] <Saviq> ogra_, no, no errors on desktop
[11:36] <ogra_> Saviq, oh ?
[11:37] <Saviq> ogra_, it crashes in the *lightdm* session
[11:37] <ogra_> ah, k
[11:37] <Saviq> ogra_, not in user
[11:37] <ogra_> so just a .crash file
[11:37] <Saviq> so anyway, it works fine, connects fine, *just* apport dumping your battery down the drain
[11:37] <ogra_> Saviq, anyway, does dropping exit 0 still work ?
[11:37]  * ogra_ would liek to get rid fo that 
[11:37] <Saviq> ogra_, worse than that, I just lost indicators again :|
[11:37] <ogra_> oh my
[11:38] <ogra_> Saviq, with no changes to the greeter stuff and using the silo packages ?
[11:38]  * ogra_ reboots his flo 10 times ... lets see
[11:38] <Saviq> ogra_, no, patched manually, will flash again and get the silo now
[11:38] <mterry> but I would have seen the crashes in /var/crash then...
[11:39] <Saviq> mterry, yeah, I do have the feeling that something moved under our feet :|
[11:39] <mterry> ogra_, and why was it only flo that had the dbus problem?
[11:39] <ogra_> mterry, http://ci.ubuntu.com/smokeng/utopic/touch/
[11:39] <ogra_> not only flo
[11:40] <ogra_> i just dont have a mako for hacking
[11:40] <ogra_> Saviq tests mako, i test flo atm
[11:40] <xnox> ogra_: that pastebin is good.
[11:40] <mterry> ogra_, on the mailing list only flo was listed as having the black-boot problem
[11:40] <mterry> ogra_, all had it?  (We also tested flo in Malta...)
[11:40] <ogra_> mterry, black boot ?
[11:40] <Saviq> mterry, yeah, no black boot
[11:40] <mterry> ogra_, people were saying there was a boot problem getting any session on flo
[11:40] <ogra_> mterry, that was with the half done landing ... unrelated
[11:40] <mterry> ogra_, I don't think it was the half done landing
[11:41] <ogra_> mterry, unity8 didnt land til sunday late afternoon
[11:41] <ogra_> all other bits from the silo did
[11:41] <Saviq> ogra_, I don't think the exit 0 is a noop
[11:41] <Saviq> ogra_, if USER != lightdm
[11:41] <Saviq> ogra_, it will exit with ['s retcode
[11:41] <mterry> ogra_, (A) I'm not sure the half done landing caused any problems.  I *thought* I set all the dependencies correct -- in this case, ubuntu-touch-session woudln't have landed until unity8 did, so no split boot would be enabled.
[11:41] <mterry> (B) people reported same black boot after unity8 landed
[11:41] <ogra_> Saviq, which either triggers stop or not ...
[11:42] <Saviq> ogra_, yeah, and when not
[11:42] <ogra_> Saviq, the exit 0 is after the "if"
[11:42] <Saviq> ogra_, pre-start exits with 1
[11:42] <Saviq> ogra_, so job fails
[11:42] <xnox> Saviq: did you test it.
[11:42] <ogra_> i dont get why the curly brackes we use everywhere else didnt work for you
[11:43] <xnox> "[foo] && bar" construct is considered guarded, and works correctly under `set -e`
[11:43]  * mterry re-reads thread to see which symptoms were from the second dbus
[11:43] <ogra_> mterry, the half done landing was an infra prob ... unity8 was stuck somewhere
[11:43] <ogra_> mterry, not your fault
[11:43] <Saviq> xnox, I did
[11:43] <xnox> Saviq: ogra_: it can be changed to ' [ "$USER" != "lightdm" ] || { stop; exit 0; }
[11:43] <sil2100> mterry: right, it wasn't on your side
[11:43] <ogra_> mterry, the double dbus caused http://ci.ubuntu.com/smokeng/utopic/touch/ to regress heavily
[11:43] <mterry> ogra_, oh, so if ubuntu-touch-session got through then without unity8, yeah that could cause problems
[11:43] <Saviq> xnox, ok let me try that
[11:43] <ogra_> mterry, which doesnt show up when testing locally
[11:44] <Saviq> not sure why || would behave differently than &&?
[11:44]  * mterry has to run real quick for 15m, be back
[11:44] <sil2100> In 15 minutes we will commence the big revert ;p!
[11:44] <ogra_> Saviq, 10 reboots in a loop ... i always had indicators here
[11:45] <xnox> Saviq: it shouldn't. maybe -1 exit is comming later? also you do need to fully stop the job, for the new config to take effect on next start. (restart is not enough, one needs stop&start)
[11:45] <ogra_> sil2100, thanks for telling us ... :P
[11:45] <ogra_> sil2100, the silo looks fine for me, did you try ?
[11:45] <Saviq> xnox, yeah yeah, I had it stopped and went "start foo", it barfed
[11:46] <Saviq> xnox, I'll try in a sec, flashing
[11:47] <sil2100> ogra_: rebooting and looking, but what about that adb problem? Is the pre-start hack working?
[11:47] <Saviq> sil2100, mtp, not adb, and yes, we're almost ther
[11:47] <Saviq> e
[11:47] <ogra_> sil2100, it should ... waiting for Saviq for a final test, then i'll upload to the silo
[11:47] <sil2100> s/adb/mtp
[11:47] <sil2100> ACK
[11:47] <sil2100> ;)
[11:47] <ogra_> sil2100, we use the same code xnox pointed to above in a ton of other scripts ... should definitely work
[11:49] <sil2100> \o/
[11:49] <sil2100> Ok, I like how it works
[11:50] <ogra_> got indicators ?
[11:50] <sil2100> Yep!
[11:50] <ogra_> great
[11:50] <sil2100> Nice greeter indicators indeed on my mako
[11:50] <ogra_> now just mtp ...
[11:51] <sil2100> Trying the fix outlined above
[11:51] <ogra_> sil2100, check if they opertes right
[11:51] <ogra_> *operate
[11:51] <ogra_> sil2100, battery should look different in the greeter than in the session
[11:51] <ogra_> clock too
[11:51] <ogra_> if you expand them
[11:52] <sil2100> So far so good, they look different indeed + disabling/enabling wifi works
[11:52] <ogra_> good
[11:52] <ogra_> then all should be fine with that landing
[11:53]  * sil2100 tries to run some AP tests to see if all is ok
[11:53] <ogra_> ++
[11:53] <ogra_> good idea
[11:53] <ogra_> perferably some of the ones we know did fail
[11:53] <ogra_> sudoku is a good one for that
[11:57] <ogra_> xnox, Saviq, final version that works fine here ... no crashes and mtp still starts fine for the user http://paste.ubuntu.com/7579893/
[11:58] <ogra_> sil2100, feel free to try that too (and check if there are crashes in /var/crash for the 111 user after applying it )
[11:58] <Saviq> ogra_, http://paste.ubuntu.com/7579899/
[11:58]  * Saviq had some network weirdness
[11:59]  * mterry is back
[11:59] <ogra_> Saviq, yeah, identical to mine http://paste.ubuntu.com/7579893/
[11:59] <mterry> Is there anything I can help with or did you heroes already just solve something?
[11:59] <ogra_> Saviq, works fine for me ... did you verify on mako ?
[11:59] <Saviq> ogra_, yes, have mtp for user, no crash
[12:00] <ogra_> mterry, i think we are fine for now ... but read the rest of the thread there are more regressions
[12:00] <ogra_> mterry, i guess bfiller would appreciate if you could help with these
[12:00] <ogra_> Saviq, good, dputting to the silo ... then a final test of the package, then lets publish and fire off an image
[12:01] <Saviq> ogra_, yeah, I'll do some telephony stress-testing in the mean time
[12:01] <sil2100> mterry: some regressions might have been fixed by ogra_'s and Saviq's fixes, but some others might still be a problem
[12:01] <mterry> ogra_, all the telephony ones?  Yeah, I saw that.  Some were known, but some are surprises yeah
[12:01] <ogra_> Saviq, ++
[12:01] <pmcgowan> mterry, btw shouldnt the indicators only show different behavior when the phone is locked
[12:01]  * sil2100 runs sudoku-app tests
[12:01] <sil2100> pmcgowan: they do right now, right?
[12:02] <ogra_> sil2100, but we have no actual "locking" enabled atm
[12:02] <mterry> pmcgowan, no they have a slightly different UI even in no-password mode to my knowledge
[12:02] <pmcgowan> sil2100, they are aways reduced features from greeter - without lock
[12:02] <mterry> pmcgowan, they export differences via phone vs phone_greeter profiles
[12:02] <pmcgowan> mterry, thats different than android and ios afaik
[12:02] <pmcgowan> more a question for design
[12:02] <ogra_> and surely not a blocker for now
[12:02] <mterry> pmcgowan, right.  We have the information available to indicators to show what they wish on the greeter
[12:03] <Saviq> pmcgowan, indeed, and then we're the first doing that kind of thing on a phone AFAICT
[12:03] <mterry> pmcgowan, we export current user, whether they need a password, and that we are in a greeter
[12:03] <pmcgowan> not a blocker, just noticed in 59
[12:03] <pmcgowan> mterry, ok
[12:03] <ogra_> mterry, the boot animation is really really tiny ... is that wanted ? its only like 1-1.5cm on the flo screen
[12:04] <pmcgowan> mterry, I also looked at the memory overhead for all the additional processes, its not terrible but not great either
[12:04] <ogra_> pmcgowan, huh ? it doubled
[12:04] <mterry> ogra_, I don't know about the scaling...  Mirco wrote the actual gl code.  It probably should scale bigger on flo
[12:04] <pmcgowan> ogra_, its around 40MB more
[12:04] <ogra_> and causes issues with app lifecycle ... apps dies way eralier
[12:04] <mterry> pmcgowan, yeah.  We double the shell memory
[12:04] <ogra_> pmcgowan, not what i see
[12:04] <pmcgowan> ogra_, oh, perhaps I mssed something
[12:05] <sil2100> From what I saw it was much higher than before
[12:05] <mterry> pmcgowan, and some of the extra telephony processes etc
[12:05] <Saviq> pmcgowan, mterry, but a lot of that mem should be shared, no?
[12:05] <pmcgowan> mterry, see https://docs.google.com/a/canonical.com/spreadsheets/d/1kBNHXCh941rcl7ZUbpjpRlyMtNAZmqCRhEy0jOM4Izo/edit#gid=0
[12:05] <Saviq> same libs etc.
[12:05] <pmcgowan> Saviq, yeah I counted PSS
[12:05] <Saviq> oh k
[12:05] <ogra_> pmcgowan, bug 1325580
[12:06] <ogra_> pmcgowan, will definitely need improvements ...
[12:06] <Saviq> yeah, that's to be fixed for sure, shell should have reduced, greeter shouldn't be that big
[12:06] <ogra_> right
[12:06] <mterry> ogra_, pmcgowan: are you saying that unity8 RSS got bigger by itself after split landing?
[12:06] <Saviq> and well, we can probably strip the greeter session (there's mediascanner running, for example)
[12:06] <sil2100> ogra_: all sudoku tests passed locally \o/
[12:06] <Saviq> hud
[12:06] <ogra_> and there are a lot upstart jobs we dont want in the greeter ...
[12:06] <mterry> Or just that having an extra greeter process is causing problems?
[12:06] <ogra_> sil2100, yay
[12:06] <sil2100> ogra_: let me revert and see if I had those failures before actually...
[12:06] <pmcgowan> mterry, I was saying the latter
[12:06] <mterry> ogra_, we don't start most of them -- we have a custom startup event in greeter shell
[12:06] <ogra_> mterry, well, we have two full sessions atm
[12:07] <sil2100> As per smoketesting
[12:07] <ogra_> right
[12:07] <ogra_> we dont start most of them but still too many
[12:07] <ogra_> the greeter itself shouldnt eat 90M+ either
[12:07] <Saviq> we should not start maliit in the greeter until it's needed, that's for sure
[12:07] <mterry> ogra_, mediascanner is an interesting one -- wonder why it starts
[12:07] <ogra_> might need the same change we used for mtp
[12:07] <Saviq> hud, should be gone, too
[12:07] <pmcgowan> we need to fix maliit to begin with
[12:08] <mterry> Yeah, maliit probably shouldn't be the biggest RSS consumer anyway
[12:08] <ogra_> ++
[12:08] <pmcgowan> thats already known issue
[12:08] <sil2100> +1
[12:08] <ogra_> anyway ... lets see that we get out of TRAINCON-0 now
[12:08] <Saviq> that, too
[12:08] <ogra_> then we can look into optimizations
[12:08] <mterry> ogra_, so what fixes do we have lined up?
[12:08]  * ogra_ is also curious about boot time 
[12:08] <ogra_> mterry, silo 20
[12:09] <ogra_> proper dbus handling and dropping of dbus-x11
[12:09] <mterry> ogra_, boot probably suffered.  I remember doing some testing and it got slightly worse, but surprisingly not as bad as I expected
[12:09] <ogra_> and mtp suppression in lightdm sessions
[12:09] <mterry> ogra_, but I don't have those numbers
[12:09] <ogra_> mterry, i'll produce bootcharts once w ehave a proper image
[12:09] <ogra_> one step at a time :)
[12:09] <ogra_> currently we are around 30sec
[12:10] <ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-49.png
[12:10] <Saviq> mterry, I don't seem to get dialer when accepting a call
[12:10] <ogra_> thats the last one i did
[12:10] <mterry> ogra_, Saviq, sil2100, others: thanks for taking care of this yesterday/today.  I owe you all beers and hugs.  I would have been able to help a little last night, but my flight got delayed 3h because someone died on it(!)
[12:10] <ogra_> OH GOD !
[12:10] <sil2100> mterry: oh crap...
[12:10] <Saviq> maan
[12:10] <Saviq> mterry, I mean it doesn't unlock
[12:10] <mterry> Saviq, that's new...
[12:11] <mterry> Saviq, you press the button, does it launch dialer in session and just fail to unlock?
[12:11] <Saviq> mterry, yes
[12:11] <Saviq> mterry, when I launch from launcher, unlocks fine
[12:11] <mterry> Saviq, they come from different places...  notification is via us pretending to be url-dispatcher
[12:12] <mterry> Saviq, but if it launches in session, we are seeing the event
[12:12] <Saviq> mterry, yeah, so by then it's greeter that should unlock itself, that's what fails
[12:13] <Saviq> mterry, btw, I wrote on one of the bugs... I feel like we need to converge on just one notification UI
[12:13] <ogra_> Saviq, mtp has built in the silo ... can you test the deb
[12:13] <ogra_> sil2100, ^^^
[12:13] <Saviq> ogra_, doing
[12:13]  * ogra_ does too on flo 
[12:13] <mterry> Saviq, yeah.  I just looked at code, and we are doing a hide right after telling session.  Odd
[12:13] <sil2100> Saviq: I'm ready to publish anytime
[12:14] <mterry> Saviq, one process can't currently draw on each session -- I suppose we could make a system daemon that talked to USC and overlayed a notification
[12:14] <Saviq> mterry, well, greeter can, can't it
[12:14] <mterry> Saviq, not on user session when you're in it
[12:14]  * ogra_ reboots with the mtp-server deb
[12:15] <Saviq> mterry, oh thought greeter is just a layer on top
[12:15] <mterry> Saviq, it's its own Mir session -- can we interleave Mir surfaces and sessions?
[12:15] <Saviq> mterry, understood it's a complete session that hides, now
[12:15] <Saviq> mterry, they get composited are they not
[12:15] <Saviq> mterry, as you swipe the greeter away
[12:15] <Saviq> mterry, anyway... LATER
[12:16] <mterry> Saviq, yeah but that's just one session on top of another.  But you're right, I think we could interleave if we wanted.  But we'd have to proxy notifications that only session sees through the greeter in that case
[12:16] <mterry> Saviq, sure.  :)
[12:16] <Saviq> mterry, yeah, some smarts need to happen
[12:16] <Saviq> mterry, but yeah, it reliably does not unlock for me
[12:17] <mterry> Saviq, reliably.  OK.  Let me get a phone hooked up with latest image
[12:17] <Saviq> mterry, can you start looking into that?
[12:17] <Saviq> great
[12:17] <ogra_> mtp is fine here
[12:23] <Saviq> ogra_, sil2100, should I run AP locally or are we going for fur smoke test
[12:23] <Saviq> ?
[12:23] <ogra_> i think sil2100 tested a few
[12:23] <Saviq> ogra_, +1 on mtp
[12:23] <Saviq> dialer and messaging would be most useful
[12:23] <sil2100> Saviq: I ran sudoku app which was said to be failing
[12:23] <Saviq> but I don't want to delay
[12:23] <sil2100> Saviq: and it passed
[12:23] <ogra_> and given that we were never able to reproduce the AP failures locally anway i would go for smoke
[12:24] <Saviq> +1 then, let me just run through manual tests for ofono
[12:24] <sil2100> Saviq: but those passed with the old unity8 from #62 as well...
[12:24] <ogra_> they always passed locally
[12:24] <ogra_> and failed in the lab
[12:24] <ogra_> except when plars did the hackery of removing Xsession.d ..
[12:25] <ogra_> this part should be fine now so AP should pass in the lab
[12:25] <ogra_> lets probably take that to the -ci-eng channel now
[12:25] <sil2100> I would say, let's get this released and check the image results
[12:25] <ogra_> ++
[12:50] <barry> doko: i'm working on this whole stack today, so i will verify that particular bug
[13:15] <GunnarHj> rbasak: Hi Robie!
[13:17] <rbasak> GunnarHj: hi!
[13:18] <GunnarHj> rbasak: Thanks for looking at bug 1314402! How would you suggest that we ask for input from other developers?
[13:18] <rbasak> GunnarHj: np, thank you for your work! ubuntu-devel or ubuntu-motu maybe?
[13:18] <rbasak> (as in, mailing lists)
[13:19] <rbasak> Or if somebody experienced on here can answer, I'd be happy with that too - I would just copy and paste into the bug for future reference in that case.
[13:19] <rbasak> Others: the issue is that GunnarHj's proposed package provides extra translations for Skype, so sort of integrates with that package but without being able to change that package.
[13:20] <rbasak> And Skype could in future provide new translations which would need to override the skype-translations package without breaking anything.
[13:20] <rbasak> So GunnarHj has arranged for the skype-translations binary package postinsts to insert symlinks, but only if regular files don't exist in their place. Then a future skype package would just overwrite those symlinks.
[13:20] <rbasak> I think we all accept that this is hacky, but don't have a better solution. Is this acceptable for upload to universe?
[13:21] <rbasak> GunnarHj: is that an accurate summary? Anything to add?
[13:22] <GunnarHj> rbasak: Thanks, yes I think that's pretty much it. Let's see if someone chimes in. Otherwise I can try one of the lists.
[13:36] <GunnarHj> seb128, Laney: A while ago you provided some input wrt bug 1314402 and my symlink idea to avoid future conflicts with the Skype package, and I made a minor change. Now rbasak is sponsoring the request, and is asking whether the idea is a reasonable approach that could be accepted for uploading to universe. Please see rbasaks questions above (13:19 UTC). Would appreciate your input (again).
[13:42] <seb128> GunnarHj, Laney is on vac today, and I've no strong opinion, I feel it's hacky and it's going to bite us back, but I have too much to do to argue against it, so if somebody wants to upload just go for it
[13:46] <rbasak> GunnarHj, seb128: well, that's what makes me reluctant :-/
[13:49] <GunnarHj> seb128, rbasak: Ok, thanks seb128 (I think). ;) All I can say is that my intention is to monitor it to prevent that anything goes wrong (even if I currently don't see what it could be).
[13:51] <seb128> GunnarHj, creating symlinks in postinst that are meant to be overwritten by other debs is just a weird hack, sorry
[13:53] <rbasak> seb128: everything in the partner archvie is a hack though :)
[13:53] <GunnarHj> seb128, rbasak: I don't claim it's not. It's just that it's the only way I could come up with to make it possible to package those translations.
[13:53] <rbasak> slangasek: I see that you've done most/all of skype uploads to partner. Do you have any comment on this, please? ^^
[13:54] <seb128> GunnarHj, hacks create unreliability in the system and whats makes our upgrades fragile
[13:54] <rbasak> (going back ~40 minutes)
[13:54] <seb128> GunnarHj, to me the proper solution there seems to work with upstream to have them include the translations, or check a different paths in addition to their
[13:54]  * rbasak wonders if there's a better approach here, such as adding support into the partner skype package.
[13:56] <rbasak> I don't know what form that might take though.
[13:58] <GunnarHj> seb128, rbasak: Well, admittedly I haven't tried to approach upstream. As regards doing something in the partner repository, I think that would be difficult since people may alternatively install Skype directly from the Skype web site.
[14:01] <rbasak> Pragmatically I think that having something community-maintained and in universe that makes for a better i8n experience for something in partner is something we should support, since Ubuntu is supposed to be for everyone and the community is volunteering translations.
[14:01] <rbasak> But I'm not sure it makes sense to go the step further and have packages in universe support an even more third party source than the partner archive is.
[14:02] <rbasak> If users are installing Skype directly from the web site, then they can install translations directly from the other source.
[14:03] <GunnarHj> rbasak: Well, that's a valid point indeed. Actually, in the proposed package I refer to the partner repository in the descriptions in debian/control.
[14:04] <rbasak> GunnarHj: I'm trying to think of how we might make this work with less of hack assuming that we could make a change to how the partner repository's skype package handles it.
[14:05] <GunnarHj> rbasak: Yeah.. This is something I haven't thought much about so far.
[14:05] <rbasak> GunnarHj: what if the skype package's postinst installed the symlinks instead, and the preinst removed them?
[14:06] <rbasak> skype-translations would still provide the actual translations, and the skype package would them hook into them if present.
[14:06] <rbasak> One catch is that removing skype-translations would lead to a tree of broken symlinks.
[14:07]  * rbasak doesn't know
[14:07] <rbasak> I think a mailing list thread is appropriate at this point :)
[14:08] <GunnarHj> rbasak: Maybe you are right. I'll think a little more about it, and then start a thread. Thanks for your thoughts so far.
[14:09] <rbasak> GunnarHj: no problem. Thank you for working on this. It's a tough situation and I appreciate you persevering to improve Ubuntu.
[14:49] <pmcgowan> mlankhorst, can you take a quick look at https://bugs.launchpad.net/qt/+bug/1318584
[14:50] <shadeslayer> pitti: poke
[14:51]  * pitti does a jump to the left
[14:51] <shadeslayer> :D
[14:51] <shadeslayer> pitti: is there any advantage to running package tests on the builder vs on the autopkgtest setup?
[14:52] <pitti> shadeslayer: in general, if a package has "make check" like upstream tests, run them during package build
[14:52] <pitti> shadeslayer: that'll cover all architectures and we also have more hardware for it, and failures should cause FTBFS which is more "obvious'
[14:53] <shadeslayer> right
[14:53] <pitti> shadeslayer: if you can run an upstream test suite against the installed packages, then the autopkgtest can do that
[14:53] <pitti> shadeslayer: for some test suites that's easy (some projects have a "make installcheck"), for others it's hard/impossible
[14:54] <pitti> shadeslayer: in the latter case it's usually better to come up with a simple smoke test that ensures that the package works at all (has exectuables/includes/files etc. at the right place and enough dependencies)
[14:54] <pitti> shadeslayer: so in short: upstream tests during build -> check the fine details; smoke tests during autopkgtest -> ensure that the package is by and large right
[14:55] <shadeslayer> roger
[14:59] <slangasek> rbasak: what's the gist of your question?  I guess you're not asking me to comment on whether everything in the partner archive is a hack ;)
[15:17] <rbasak> slangasek: so GunnarHj wants to add a new skype-translations package to universe, which will augment the skype package by providing translations not available upstream.
[15:18] <rbasak> slangasek: the awkward thing is that skype looks for translations in one place, so I'm not sure how to technically do this without skype-translations messing with the directory that skype ships.
[15:18] <rbasak> slangasek: GunnarHj has a solution with symlinks that appears to work, but it is definitely a hack. I wonder if a better way is to add support to the skype package somehow.
[15:19] <rbasak> Or, if not, then is the mechanism GunnarHj has come up with acceptable for upload to universe. I'm reluctant to upload without a +1 from someone else on the approach.
[15:19] <rbasak> (that first sentence should have been a question)
[15:34] <slangasek> rbasak: what's wrong with skype-translations shipping files in the same directory as skype itself?  This seems perfectly reasonable to me
[15:34] <GunnarHj> slangasek: For the case you have time to take a closer look, the skype-translation package that rbasak has reviewed is built in utopic at
[15:34] <GunnarHj> https://launchpad.net/~gunnarhj/+archive/skype-translation/+packages
[15:35] <slangasek> as for adding it to the skype package itself, I would say no unless it gets upstreamed
[15:36] <GunnarHj> slangasek: The problem is possible conflicts if later Skype versions are bundled with the same translations.
[15:36] <slangasek> GunnarHj: so use a pre-emptive "replaces"?
[15:37] <GunnarHj> slangasek: Err.. What's that in English? ;)
[15:38] <slangasek> have skype-translations declare Replaces: skype, so that the skype-translations versions of the files will always be used without complaints from the package manager
[15:39] <seb128> slangasek, the issue is in the other way
[15:39] <seb128> slangasek, new skype might includes translations that are in skype-translation
[15:39] <rbasak> slangasek: I did not know that would be acceptable. Thanks! I wonder if it's possible to do it the other way round though then? So a new skype will replace older translations in skype-translation?
[15:39] <seb128> slangasek, so skype would fail to install
[15:39] <slangasek> seb128: not with a Replaces it wouldn't
[15:39] <seb128> unless upstream skype add the proper replaces
[15:40] <slangasek> no, there would be no failure to install
[15:40] <slangasek> you can always install a "replaced" package, it just doesn't get all of its files unpacked
[15:40] <seb128> hum?
[15:40] <seb128> skype 6 would start shipping de.po which is in skype-translation
[15:40] <slangasek> now, if this is not acceptable because we must prefer the upstream translations over the ones in the skype-translations package, then this doesn't solve the problem
[15:40] <seb128> how would that not fail on a file conflict
[15:40] <slangasek> because that's what Replaces means
[15:40] <seb128> (if skype doesn't add the Replaces)
[15:41] <seb128> well, that means having skype to add a Replaces to their package
[15:41] <seb128> which they didn't do yet
[15:41] <infinity> No...
[15:41] <slangasek> no, it does not!
[15:41] <slangasek> Replaces tells you /which package wins/ in the case of a file conflict
[15:41] <infinity> seb128: If skype-translation replaces skype, it always wins.  Install order doesn't matter.
[15:41] <GunnarHj> slangasek: But that would mean that if there is a skype-translation translation installed, it would take precedence over the translation bundled with Skype. Would that be an acceptable solution?
[15:41] <infinity> The only minor bug there is that if you remove skype-translation, you'll have files "missing" from skype.
[15:41] <seb128> oh, ok
[15:42] <slangasek> GunnarHj: it's acceptable from an archive perspective; it just puts the burden on the maintainer of skype-translations to make sure the package is kept up to date
[15:42] <seb128> learning every day ;-)
[15:42] <seb128> I though replaces was unidirectional
[15:42] <GunnarHj> slangasek: Well, I'm ready to assume that role...
[15:43] <infinity> seb128: It is.  It's just that install order doesn't matter.  An installed package can Replaces a package you're about to install, and the new one just won't have all its files installed.
[15:43] <infinity> And, of course, the real problem here is that if there's an overlap, then skype-translations is updated to remove the overlap, peole who already upgraded skype just won't have that translation anymore.
[15:44] <infinity> (translations installed, includes de.po, new skype installed, its own de.po is replaced, new translations installed, de.po removed)
[15:44] <infinity> Which is why unconditional replaces is generally a bad idea.
[15:46] <GunnarHj> infinity: What if you just drop a translation from skype-translation, if it gets bundled via a new Skype version? Then it wouldn't be removed.
[15:46] <infinity> GunnarHj: That depends on upgrade order.  If your new translations is upgraded BEFORE the new skype, all is well.  If the new skype is upgraded first, the file goes missing.
[15:48] <infinity> This isn't to say that this hack isn't preferable to having no translations at all, perhaps, just that there's a limitation here that can't be solved without upstream interaction.
[15:48] <infinity> Having skype read from a secondary location is much cleaner, in that it avoids this hack.
[15:49] <GunnarHj> infinity: There is just a tiny detail... How to get Microsoft listen to such a request?
[15:49] <infinity> How does skype do translations?
[15:49] <infinity> Is it just gettext?
[15:49] <infinity> Or something fancy?
[15:50] <infinity> Cause our glibc is already patched to read secondary locations (this is how langpacks work)
[15:50] <infinity> If you used the langpack location for your translations, maybe it would Just Work?
[15:50] <infinity> ie: /usr/share/locale-langpack/*
[15:51] <GunnarHj> infinity: Nothing fancy. Special .ts XML files that are converted to .qm files.
[15:51] <infinity> Oh.  So, yes.  Fancy, from my POV. ;)
[15:52] <infinity> So, the much messier, but won't-cause-disappearing-files-or-conflicts option is to dpkg-divert every one of the files you ship.
[15:52] <infinity> So that if skype ships the same file, it gets diverted, but exists.
[15:52] <infinity> And then when you remove it from yours, the skype one is moved back to where it should live.
[15:53] <GunnarHj> infinity: That's something new to me. Sounds interesting.
[15:55] <infinity> GunnarHj: The manpage can be a bit daunting, as is getting the right syntax.  But in plain english, a dpkg-divert says "if another package tries to install $file, please install it to $file.otherlocation instead", and then when you remove $file from your package, you also remove the diversion, so the other owner's file gets moved back to where it belongs.
[15:56] <GunnarHj> infinity: Can you think of a package where that feature is made use of?
[15:56] <GunnarHj> infinity: (as an example)
[15:58] <infinity> pkgbinarymangler has the scariest diversion in the entire archive. :P
[15:58] <infinity> (utopic-amd64)root@cthulhu:/home/adconrad# dpkg -S /usr/bin/dpkg-deb
[15:58] <infinity> diversion by pkgbinarymangler from: /usr/bin/dpkg-deb
[15:58] <infinity> diversion by pkgbinarymangler to: /usr/bin/dpkg-deb.pkgbinarymangler
[15:58] <infinity> dpkg, pkgbinarymangler: /usr/bin/dpkg-deb
[15:59] <infinity> (do not try that one at home, kids)
[15:59] <infinity> GunnarHj: There's hackish stuff in pkgbinarymangler's preinst to make sure dpkg-deb always exists, obviously that doesn't matter much for diverting a translation, so you can ignore that bit.
[16:00] <GunnarHj> infinity: Ok.. I will take a look, and try to figure out if and if so how this could be applied to my simple package.
[16:00] <GunnarHj> infinity: Thanks for the tip!
[16:01] <infinity> GunnarHj: In the case of a package diverting multiple files (and potentially removing some), I'd probably do it with variable and shell loops.
[16:02] <GunnarHj> infinity: Sounds reasonable.
[16:02] <infinity> GunnarHj: ie: CURRENT_TRANS="de kr jp"; OLD_TRANS="es fr", and make sure you're removing diversions for OLD_TRANS on upgrade.
[16:03] <GunnarHj> infinity: Think I get the picture. Have some reading and testing to do now. ;)
[16:21] <ogra_> pitti, ugh ... is there any way to not make ofono-phonesim-autostart pull dbus-x11 into the test env ?
[17:04] <hallyn_> ok it's gotta be pulseaudio.  crashing my utopic laptop anytime i've played, let's say, about 10 mins of audio
[17:04] <hallyn_> hard crash though, nothing in syslog, alt-sysrq doesn't work, have to hold down power button
[17:26] <chrisccoulson> mlankhorst, who can I ping about nouveau-specific issues? I could do with some help on bug 1309044
[18:18] <hallyn_> serge    11285 26898  0 13:15 ?        00:00:01 /bin/bash /usr/bin/pomigrate2 --use-compendium --pot2po --quiet tmp.Cvh7SoRbeB/af /home/serge/po/af /home/serge/po/templates
[18:19]  * hallyn_ purges translate-toolkit for lack of better idea
[19:13] <brendand> More utopic trouble anyone?
[19:17] <brendand> Stuck on 'Started Accounts Service'
[19:18] <brendand> Strange thing is i don't even remember upgrading
[19:20] <brendand> Now it's colord.service
[19:27] <brendand> Ahh - it was fsking unity8-greeter at it again
[19:27] <brendand> Managed to install itself behind my back
[20:33] <stgraber> GunnarHj: hey there, were you the one requesting the svtplay-dl sync for trusty? Seems likely to be a mistake (trusty instead of utopic), if so, I'll reject it from the New queue.
[20:34] <GunnarHj> stgraber: Yes, it was me, and no, it was no mistake.
[20:34] <stgraber> GunnarHj: ah, ok, what's the rationale for getting that new package into the archive post-release?
[20:34] <GunnarHj> stgraber: It's already in utopic; this is a SRU, sort of...
[20:35] <GunnarHj> stgraber: The rationale is to make it more easily available to users already in 14.04.
[20:35] <stgraber> GunnarHj: ok, sounds more like something for trusty-backports than for the trusty-updates
[20:36] <stgraber> (which to a user wouldn't make any difference since both are enabled by default)
[20:36] <GunnarHj> stgraber: Is backports enabled by default these days?
[20:36] <stgraber> GunnarHj: it is, yes
[20:38] <GunnarHj> stgraber: Ok, didn't know. Well, in that case a backport would be just as good, I suppose. But I also thought that since this is a standalone package, that can't break anything existing, it didn't matter...
[20:40] <stgraber> GunnarHj: we usually only allow new packages in stable releases for post-release hardware enablement. Backport from new releases (whether the package already exists in a past release or not) should go through -backports.
[20:40] <stgraber> GunnarHj: ok, so I'll reject that upload. Please run "requestbackport svtplay-dl" on your machine to automatically file the backport request, then a member of ubuntu-backporters will process it for you.
[20:40] <stgraber> rbasak: hey there, can you add the SRU paperwork to bug 1309991 please?
[20:42] <GunnarHj> stgraber: Ok, will do. Thanks for letting me know.
[20:50] <stgraber> pitti: hey, your util-linux upload is missing the usual SRU paperwork, though the bug is sufficiently obvious that I'll accept it anyway (the title pretty much being the testcase anyway)
[20:54] <stgraber> bdrung: can you update both the bugs referenced in that audacity upload with the SRU paperwork stuff? they both seem to be lacking testcases at least.
[20:54] <bdrung> stgraber: i can quickly add a test case for the libav bug
[21:13] <stgraber> lool: can you update bug 1310715 with SRU information (rational, testcase, regression potential, ...)?
[21:29] <bdrung> stgraber: 1076928 updated
[21:40] <bdrung> stgraber: paperwork for both audacity bugs done.
[21:40] <stgraber> bdrung: cool, thanks. Re-reviewing now
[21:41] <stgraber> bdrung: both of those have been fixed in utopic right? (LP says that's not the case but I suspect it's wrong)
[21:41] <bdrung> stgraber: audacity should migrate in utopic
[21:41] <bdrung> stgraber: audacity is still stuck in proposed due to libav
[21:42] <jdstrand> mdeslaur: will we have something equivalent to the apparmor status in upstart jobs when we move to systemd?
[21:42] <jdstrand> s/status/stanza/
[21:43] <stgraber> bdrung: ah ok, that makes sense then
[21:44] <bdrung> stgraber: do you know why libav didn't migrate?
[21:45] <stgraber> bdrung: no, but I can look it up for you
[21:45] <infinity> bdrung: libav is a pretty involved ongoing transition.
[21:45] <bdrung> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libav
[21:45] <bdrung> that page says that libav is a valid candidate
[21:46] <infinity> bdrung: Sure, and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows how many dozens of packages break if it migrates.
[21:46] <stgraber> bdrung: right, in which case you need to also look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[21:46] <infinity> bdrung: You need to read both pages as a whole, it's two steps in the process.
[21:47] <stgraber> http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html seems relevant too
[21:48] <bdrung> that page is easier to understand than the update_output.txt
[21:49] <stgraber> yeah, update_output.txt isn't the most readable thing ever, it assumes you know how britney works quite well (or that your brain somehow adapted to make sense of that file)
[23:43] <psusi> cjwatson, bug #1326143 the user has no efi system partition, yet grub-install failed to fall back to grub-pc for some reason... any clue as to how that could happen?