[06:50] <dholbach> good morning
[07:12] <JamesTait> Good morning all; happy One Day Without Shoes Day! :-D
[07:14] <diwic> good morning, is it possible to use perf on the phone? (E: Package 'linux-tools' has no installation candidate)
[07:15] <diwic> it's the nexus 4 if that matters
[07:19] <RAOF> diwic: Looks like the answer is “no”; we've got builds of linux-tools for lots of the devices, but not for mako?
[07:21] <diwic> RAOF, so it seems, but just asking in case I'm missing something
[07:22] <diwic> there is one for "goldfish" but not sure what that is
[07:22] <diwic> probably not Nexus 4
[07:25] <RAOF> Goldfish is the emulator
[07:32] <diwic> aha
[08:02] <ev> ogra_: the .upload file should be created by whoopsie-upload-all. The .uploaded file indicates that it's been successfully uploaded. Perhaps the upstart job that fires off whoopsie-upload-all isn't working?
[08:02] <ogra_> ev, hmm
[08:02] <ogra_> ev, how is that called ?
[08:03] <ogra_> all i have is /etc/init/whoopsie.conf
[08:04] <ogra_> root@ubuntu-phablet:~# initctl status whoopsie
[08:04] <ogra_> whoopsie start/running, process 1625
[08:04] <ogra_> and that one started just fine it seems
[08:06] <ogra_> ah, in apport-noui
[08:07] <ogra_> no upstart logs ...
[09:30] <bian-xie> please anyone can give a brief introduction about Ubuntu Touch Camera architecture
[09:31] <bian-xie> I mean how the camera-app connected with Android mediaserver running in the lxc container
[10:27] <davmor2> Morning all
[11:42] <sergiusens> ogra_: hey, can you take a look at https://code.launchpad.net/~sergiusens/phablet-tools/mantashot/+merge/215767 ?
[11:43] <sergiusens> ogra_: going to add phablet-screenshot to the mir testplan ;-)
[11:43] <didrocks> sergiusens: you have been broken?
[11:44] <sergiusens> didrocks: phablet-screenshot doesn't work on manta due to the coloring being changed
[11:44] <sergiusens> didrocks: used to be bgra for manta and now it's the same as all others: rgba
[11:45] <didrocks> ok, some kind of good enhancement then :)
[11:57] <ogra_> sergiusens, oh, when did that change
[11:57] <nik90> hey I did a system update and it is removing quite a bit of ubuntu touch related packages https://i.imgur.com/nfOGXN1.png
[11:58] <nik90> does anyone else see this?
[11:58] <sergiusens> ogra_: don't know; saw a bug related to manta failing on screenshots from cwayne (and although a bit different) failed
[12:03] <sergiusens> ogra_: anyways, I added phablet-screenshot to the mir testplan, mind reviewing?
[12:03] <ogra_> where is it ?
[12:04] <ogra_> (change approved btw)
[12:26] <sergiusens> ogra_: the test plan?
[12:27] <ogra_> well, wasnt that what you wanted me to review ?
[12:27] <sergiusens> ogra_: https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir
[12:27] <sergiusens> ogra_: no, I wanted you to review the manta change which you already have :-)
[12:27] <sergiusens> ogra_: ah, you should test as well :-P
[12:28] <ogra_> heh, ok
[12:45] <sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/emulator_channel/+merge/215860
[12:50] <Laney> mpt: bug #1289470> We keep the two sliders in system-settings?
[12:53] <mpt> Laney, yes
[12:53] <Laney> okay
[12:54] <mpt> (that’s why the u-s-s bit is still assigned to me)
[12:55] <Laney> Fairy nuff
[12:58] <rickspencer3> popey, I would like to log a bug against Unity 8 on my phone, but it's not a crash, can I use apport-cli in some way to do that?
[12:59] <rickspencer3> popey, nm, I just found this https://wiki.ubuntu.com/QATeam/TouchTesting
[12:59] <rickspencer3> looks like I can use ubuntu-bug and adb
[13:00] <popey> rickspencer3: you can just ubuntu-bug /var/crash/foo.crash, yes.
[13:00] <popey> i have had mixed success with that
[13:00] <rickspencer3> popey, ok
[13:00] <rickspencer3> there's no crash file, but I'm giving it a try
[13:04] <trex_> hello everyone, perhaps a stupid question, but i was wondering, where can i find the most recent stable version of ubuntu mobile?
[13:05] <trex_> am currently running     ubuntu-device-flash --channel=saucy --revision=99
[13:06] <pmcgowan> trex_, the latest trusty images are in the devel channel, currently 294
[13:07] <trex_> thanks pmcgowan
[13:09] <pmcgowan> trex_, that channel has tested and promoted images (devel same as trusty) whereas the bleeding edge is on trusty-proposed and that can break
[13:10] <trex_> pmcgowan, in terminal, i could just run adb shell system-image-cli --channel trusty -b 294
[13:11] <pmcgowan> trex_, you can use ubuntu-device-flash, not sure if you need to do a bootstrap to move from stable
[13:11] <pmcgowan> sergiusens, ^^
[13:12] <sergiusens> pmcgowan: trex_ no, not needed, just ubuntu-device-flash --channel devel with the device connected
[13:13] <trex_> got it thanks
[13:13] <trex_> so
[13:13] <sergiusens> stable is going to be promoted to trusty soon though
[13:14] <trex_>     ubuntu-device-flash --channel=devel-294?
[13:14] <pmcgowan> trex_, no need for 294
[13:14] <sergiusens> trex_: no, exactly as  typed; whats with adding the revision/version number?
[13:15] <trex_> got it
[13:15] <trex_> thanks
[13:16] <trex_> was on saucy (above), wifi is still down on it, switching to trusty as recommended..thanks
[13:22] <mterry> kgunn, the autopilot3 tests failed where the py2 ones didn't?  That's odd
[13:23] <kgunn> mterry: yeah...something about no module named "autopilot.vis"
[13:23] <mterry> That doesn't seem related to my change at least...
[13:24] <mterry> kgunn, install python3-autopilot-vis
[13:25] <kgunn> mterry: man i feel dumb...i thot i had
[13:26] <kgunn> mterry: all happy now
[13:28] <kgunn> mterry: ...it was late
[13:28] <mterry> kgunn, :)
[13:30] <kgunn> mterry: i'll run the phone test now too...
[13:30] <kgunn> if that helps save you a cycle or 2
[13:31] <mterry> kgunn, OK thanks.   I can run something too.  Is that all of the test pieces?  (i.e. are we running all the dependent component tests?)
[13:35] <kgunn> mterry: i was going to run the entire AP suite....
[13:35] <kgunn> per https://wiki.ubuntu.com/Process/Merges/TestPlan/autopilot
[13:36] <kgunn> which thomi says takes ~4 hrs
[13:39] <mterry> kgunn, just the autopilot tests for the autopilot project do or are you running all autopilot tests for Touch?
[13:39] <kgunn> mterry: all tests for touch
[13:40] <kgunn> its effectively the smoke test
[13:40] <mterry> I see
[13:40] <mterry> kgunn, OK, well if I can offload some of that, let me know
[13:40] <kgunn> mterry: you might want to do some exploratory testing....
[13:41] <kgunn> i suppose technically...the untiy8 test https://wiki.ubuntu.com/Process/Merges/TestPlans/Unity8
[13:41] <kgunn> (the manual stuff)
[13:42] <mterry> kgunn, sure.  (Also, we released Mir 0.1.8?  nice)
[13:42] <kgunn> mterry: yes
[13:46] <mterry> kgunn, cool, that means we can simplify the split silo
[14:15] <mardy> bfiller: hi! Are you taking care of landing the "app-access2" branch of u-s-s-o-a?
[14:20] <bfiller> mardy: yes, but probably will not do that until after 14.04. still trying to get syncing working fine
[14:20] <mardy> bfiller: that's fine, I just wanted to know if you were on it
[14:21] <bfiller> mardy: yup, we did test it and it works fine
[14:24] <mterry> doanac, you mentioned wondering what to do about unlock_screen.py in ubuntu-test-cases.  The new unlock-device script is a wholesale replacement for it.  No need to convert it, just switch to using unlock-device instead
[14:25] <mterry> doanac, oh whoops, you said "run-autopilot-tests.sh" not unlock_screen.py
[14:25] <doanac> mterry: correct. its not a 1-to-1 mapping with the new way it works
[14:27] <mterry> doanac, how come those scripts can rely on /home/phablet/bin/unlock_screen.sh being there?  What puts that in place?
[14:28] <doanac> mterry: we put it there when we provision a device (our scripts/provision.sh)
[14:32] <cwayne> bfiller: hey, any chance we can get this reviewed (it'll fix address-book-app tests for the touch_custom suite) https://code.launchpad.net/~cwayne18/address-book-app/autopilot-upstart/+merge/212747
[14:35] <bfiller> cwayne: sure, looks like it's failing in CI though. can you try and get that resolved first?
[14:36] <rickspencer3> popey, sorry to bug you for this, but I think you helped me last time ... I'm looking for the script for getting screenshots of a phone or tablet
[14:37] <rickspencer3> I think ogra_ wrote it, maybe/
[14:37] <rickspencer3> ?
[14:37] <ogra_> phablet-screenshot
[14:37] <popey> what he said
[14:38] <ogra_> actually i'm pondering to write an app for that over easter ... lets see if i'm bored enough
[14:38] <popey> to do it on the device?
[14:38] <ogra_> yeah
[14:38] <popey> good luck ☻
[14:38] <ogra_> heh
[14:39] <rickspencer3> jeez, I already had it installed
[14:39]  * rickspencer3 dopes slap self
[14:44] <dobey> dpm: hey, when should we expect that e-mail you said you were going to send to ubuntu-phone about scopes i18n?
[14:45] <dpm> dobey, today in the next 30 mins, sorry for the delay!
[14:45] <dobey> dpm: ok, thanks :)
[14:48] <jose> didrocks: ping
[14:48] <didrocks> jose: pong
[14:51] <cwayne> bfiller: trying to look into it, but can't seem to get any of the logs or do a rebuild
[15:17] <sergiusens> ogra_: rsalveti did you get a chance to test https://code.launchpad.net/~sergiusens/phablet-tools/mantashot/+merge/215767 ?
[15:18] <ogra_> not yet
[15:18] <ogra_> i need to upgrade my manta forst
[15:18] <ogra_> *first
[15:19] <mterry> doanac, OK so I have lp:~mterry/ubuntu-test-cases/touch-unlock-device -- what's the best way to test that my changes work?  Just do the stuff in README-cli.rst?
[15:20] <rsalveti> sergiusens: not yet, flashing
[15:20] <rsalveti> sergiusens: was updating bug 1284612
[15:21] <sergiusens> rsalveti: ah, I got a needs fixing and will just add a user switch for that one (--update) although it is in general bad practice
[15:21] <rsalveti> sergiusens: it is, it's fine to update by default
[15:21] <rsalveti> our infra is broken
[15:22] <sergiusens> rsalveti: well asac and plars will kill me if I do that :-P
[15:22] <rsalveti> if we really wanted to force a specific version, we should declare that when installing packages by hand
[15:22] <sergiusens> makes sense
[15:22] <sergiusens> but I might still get killed :-P
[15:22] <rsalveti> right :-)
[15:22] <plars> kill you, no...
[15:23] <dpm> dobey, first e-mail for scopes sent. The one for click scope translations to follow later on today, but that'll take me a bit more, as I want to dig a bit deeper into the mapping of Name/Description in .desktop/manifest/store
[15:23] <dobey> dpm: ok
[15:23] <dobey> dpm: thanks
[15:23] <rsalveti> sergiusens: the emulator-channel one is also approved
[15:23] <dpm> np
[15:24] <plars> sergiusens, rsalveti: From what I see, it looks like we still have about 10 tests that require installation of -autopilot packages
[15:24] <popey> olli_: are you on amd64 on desktop or i386?
[15:24] <rsalveti> plars: right, and why update would be a problem in there?
[15:25] <rsalveti> would the newer packages be available via a silo or something?
[15:25] <rsalveti> oh, during the smoke testing I believe
[15:25] <plars> friends, mediaplayer, webbrowser, url-dispatcher-tools (for unity8), dialer-app, messaging-app, address-book-app, ubuntuuitoolkit, ubuntu-system-settings-online-accounts, and ubuntu-system-settings
[15:25] <ogra_> rsalveti, well, i was suggesting to use lplib for that apt upgrade issue ... but we need to kind of make sure the local dependency resolution hooks into that since we cant use the archive one
[15:25] <olli_> popey, Linux minime 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[15:25] <rsalveti> right, we're just lucky
[15:25] <sergiusens> rsalveti: are you implying that train landings can't happen until the image is tested? :-)
[15:26] <ogra_> rsalveti, well, we'Re screwed if we try to test on an image that was promoted two weeks ago
[15:26] <rsalveti> if we really want to install additional packages that would match the image id, we should sync that somewhere else
[15:26] <sergiusens> I know that the way it is, running update potentially makes you test the wrong thing
[15:26] <rsalveti> or make it pre-installed by default
[15:26] <sergiusens> I'm all for preinstalling these autopilots
[15:26] <ogra_> rsalveti, but we have all info
[15:26] <ogra_> it is on the device
[15:26] <popey> olli_: trying to parse your spreadsheet
[15:26] <sergiusens> rsalveti: exactly; we talked about this in January :-)
[15:26] <plars> rsalveti: for instance, we have an image with version of something one of those depends on, and we install the updated version from the archive, the dependency can force install of something else that we don't want
[15:27] <rsalveti> plars: right, but how can we fix this?
[15:27] <plars> rsalveti: the recommendation in the past was always "don't ever run apt-get update"
[15:27] <rsalveti> either we cache the packages (at the time we create the image), or we have them pre-installed
[15:27] <rsalveti> plars: but that's not an ideal fix :-)
[15:27] <ogra_> rsalveti, fish the dependency info out of the local apt db ... download the debs with lplib ... dpkg -i them
[15:27] <plars> rsalveti: agreed
[15:27] <rsalveti> plars: as we're just lucky that the archive will still have the packages around because we're testing a fresh image
[15:28] <plars> rsalveti: the longer term solution is to move away from packages for autopilot tests
[15:28] <rsalveti> ogra_: right, from a cache
[15:28] <ogra_> what cache ?
[15:28] <olli_> popey, what's the problem
[15:28] <ogra_> we have a package db from the moment the image was built
[15:28] <rsalveti> ogra_: you need to download it from somewhere valid, could be launchpad as you suggested
[15:28] <sergiusens> rsalveti: well this also brings in the problem that you can't realy rerun tests on older images unless it's a click ;-)
[15:28] <ogra_> so from there we get all info ... version, deps etc
[15:28] <ogra_> lp lib pulls them for us from launchpad
[15:28] <asac> rsalveti: wen dont want to upgrade packages until we have a different solution
[15:29] <ogra_> and we just dpkg -i them
[15:29] <popey> olli_: trying to figure out what needs patching and what doesnt
[15:29] <rsalveti> asac: that I get
[15:29] <popey> olli_: and the impact
[15:29] <rsalveti> but we should also work to fix our infra
[15:29] <asac> rsalveti: we are parallelizing landing: e.g. upload new versions right after the image is produced etc.
[15:29] <asac> rsalveti: right
[15:29] <ogra_> hwo do you want to fix that ?
[15:29] <olli_> popey, I filed those bugs for that
[15:29] <asac> my idea was to backup the Packages file
[15:29] <rsalveti> ogra_: you suggested a valid solution
[15:29] <sergiusens> asac: well making the image writable is also bad; that needs fixing too
[15:29] <ogra_> you would have to have an archive snapshot after each package change
[15:29] <asac> used to produce the image, and then have a tool that maps that to librarians taht we can then feed into the test run
[15:29] <asac> as the packages file :)
[15:29] <ogra_> rsalveti, ah, i thought you mean on the archive
[15:30] <popey> olli_: right, the bug explains the problem but not the impact of changing
[15:30] <olli_> popey, want to jump on a HO real quick
[15:30] <asac> i think that would be the right solution; everything else feels pretty hacki
[15:30] <popey> olli_: ya
[15:30] <ogra_> asac, thats hacky too
[15:30] <olli_> https://plus.google.com/hangouts/_/canonical.com/olli
[15:30] <ogra_> :)
[15:30] <asac> not sue
[15:30] <asac> its snapshooting
[15:30] <ogra_> no
[15:30] <rsalveti> if we get the packages from lp and dpkg -i them, we're fine
[15:30] <ogra_> snapshooting would mean to actually create an archive snapshot
[15:30] <asac> sergiusens: well, if you want to change image you need to make it writable; what we should do is really make it read-only afterwards and ensure that we really only change things that we want to change
[15:31] <rsalveti> as lp keeps everything in there
[15:31] <ogra_> right
[15:31] <popey> olli_: balls, hangouts broken
[15:31] <olli_> ah, you dist-upgraded
[15:31] <olli_> heh
[15:31] <ogra_> all solutions to this are hacky ... so it doesnt matter which we pick really
[15:31] <rsalveti> popey: kill every chrome process you have
[15:31] <rickspencer3> *cough*
[15:31] <ogra_> the only clean solution would be real snapshots
[15:31] <popey> ugh
[15:31] <sergiusens> asac: I sort of solved it with click so that you don't need to make it writable at all; don't know why the same stuff can't be done with the other stuff
[15:31] <ogra_> but thats something we cant afford
[15:31] <rsalveti> or having everything pre-installed
[15:31] <asac> ogra_: not sure what is different?
[15:31] <rsalveti> everything we care to be tested
[15:32] <asac> rsalveti: manually cofing magic around lp and dpkg -i will over time be apt :_)
[15:32] <asac> e.g. if its more ciomplex you need dependency resolution etc.
[15:32] <rsalveti> asac: yup :-)
[15:32] <sergiusens> asac: you can test any click package on any image (devel|devel-proposed) without making it writable and without altering the image
[15:32] <ogra_> asac, it will use apt for getting all its info
[15:32] <asac> ogra_: then why not just make apt do the right thing?
[15:32] <ogra_> it will replace the download and install parts of apt
[15:32] <rsalveti> asac: can we snapshot the archive?
[15:32] <asac> no
[15:32] <ogra_> asac, because we cant ?
[15:32] <asac> we can snapshot the packages file
[15:33] <asac> and be smart about finding them in lop
[15:33] <asac> we could write a proxy
[15:33] <ogra_> the onyl way to make apt do the right thing is an archive snapshot
[15:33] <asac> that resolves things super smart :)
[15:33] <rsalveti> but then we need to use lp
[15:33] <asac> hehe
[15:33] <sergiusens> the general solution is to not use debs for testing; then you don't need all this mega infra around it
[15:33] <rsalveti> ogra_: yeah
[15:33] <popey> olli_: ok, there
[15:33] <ogra_> asac, why do you want to snapshot the package file
[15:33] <asac> rsalveti: sure. but still saying that keeping the packages file around is a first step
[15:33] <ogra_> asac, you have that snapshot on disk
[15:33] <sergiusens> asac even with this solution, how do you test a devel image?
[15:33] <asac> because you will have to remember exatly what package versions were available at the time of image production
[15:33] <ogra_> all you need is grep-dctl to get the info you want
[15:33] <asac> have to go on a call :)
[15:34] <rsalveti> can't we create a custom tarball with every package we need?
[15:34] <rsalveti> like we do for custom channels?
[15:34] <ogra_> then have lplib pull the debs and dpkg -i them
[15:34] <asac> rsalveti: we dont know which packages we might need
[15:34] <asac> do we?
[15:34] <rsalveti> that would deploy the packages somewhere in the image?
[15:34] <doanac> mterry: you can probably test it by running something like: ./scripts/run-smoke -a friends_app
[15:34] <rsalveti> asac: well, we could maintain a list (and deps)
[15:34] <rsalveti> as we're installing them anyway
[15:34] <ogra_> fun
[15:34] <ogra_> and if some package changes dependencies you are screwed
[15:35] <ogra_> somewhere low level ... totally unrelated to what you need
[15:35] <rsalveti> as long we also download the dependencies, we're fine
[15:35] <mterry> doanac, I also assume theses branches need updating?  https://code.launchpad.net/~canonical-ci-engineering/jenkins-launchpad-plugin
[15:35] <ogra_> so effectively you have an archive snapshot :P
[15:35] <ogra_> in a tarball
[15:35] <rsalveti> right, but not the entire archive
[15:35] <rsalveti> just for the things we need/use
[15:35] <ogra_> which might be gigantic
[15:35] <rsalveti> I like the lp idea, but I wanted something that could also be off-line
[15:35] <ogra_> how do you knwo what you might want to use next week ?
[15:36] <ogra_> i dont think that flies
[15:36] <doanac> mterry: probably should check with fginther about those branches. I think they are otto and run on x86 so maybe not
[15:36] <rsalveti> well, we already know what needs to be installed anyway, right?
[15:36] <rsalveti> as we're installing them today
[15:36] <ogra_> not if i.e. a dep changed
[15:36] <rsalveti> we just calculate that dynamically
[15:36] <rsalveti> all we need is the list of packages we care to install
[15:37] <sergiusens> rsalveti: ogra_ fwiw, for readonly testing I use lp to pull in some extra deps (but it's tight; I don't have dependency resolution)
[15:37] <ogra_> well, i prefer using lplib and the local packages file
[15:37] <fginther> mterry, those branches do not need updating, that's the old test runner which is being obsoleted
[15:37] <ogra_> that gives you all the archive if you need it
[15:37] <sergiusens> alternatively you can apt-get download *-autopilot and cache that with ogra stats :-P
[15:37] <ogra_> not just a predefined subset
[15:37] <rsalveti> sergiusens: that's kind of my proposal
[15:37] <mterry> fginther, OK.  Is there any unlocking logic in phablet-tools?
[15:38] <rsalveti> as long we also download the deps, we're fine
[15:38] <ogra_> i dont like that limitation
[15:38] <rsalveti> but ogra_ doesn't like it
[15:38] <sergiusens> mterry: no; would be nice to have QA proposed their one solution to rule them all
[15:38] <fginther> mterry, I'm 95% sure there isn't
[15:38] <sergiusens> s/d//
[15:38] <mterry> fginther, will double check
[15:38] <ogra_> if we actually invest into such gross hackery we should make all packages aavilable that the Packages file refers to
[15:39] <rsalveti> Saviq: do we have a bug for the 'Apps' scope title that is always centered when you boot the device?
[15:39] <rsalveti> Saviq: that's really annoying :-)
[15:39] <rsalveti> ogra_: right
[15:40] <rsalveti> if the dep list is not big, I'd just pre-install everything
[15:40] <rsalveti> but nobody likes that :-)
[15:40] <ogra_> eeek
[15:40] <ogra_> yeah
[15:40] <rsalveti> it solves everything
[15:40] <ogra_> you will have to wrangle with pmcgowan then :)
[15:40] <rsalveti> and you can test without changing the image
[15:40] <rsalveti> RO :-)
[15:40] <Saviq> rsalveti, yeah, the bug is "we're getting rid of the tab-like header, let's not care about it" ;P
[15:40] <Saviq> rsalveti, and it only happens on boot, no normal person will see it as often as we do
[15:41] <rsalveti> lol, indeed
[15:41] <pmcgowan> rsalveti, lets just install all of gnome too, and wine, and ....
[15:41] <ogra_> wine !
[15:41] <ogra_> the armhf version *can* run notepad
[15:41] <rsalveti> pmcgowan: as I said, as long the deps are not that big
[15:41] <rsalveti> and not many deps
[15:41] <ogra_> so surely a valid candidate
[15:42] <rsalveti> we can for sure simplify them
[15:42] <ogra_> though we need wine-mir first
[15:42] <rsalveti> otherwise we'll create a huge hackery all around and still test RW images
[15:42] <pmcgowan> forget I said anything
[15:42] <ogra_> (or would that be mir-wine ?)
[15:42] <rsalveti> or move everything to click
[15:42] <rsalveti> :-)
[15:42] <pmcgowan> rsalveti, maybe we have two images, one with a testing seed?
[15:42] <sergiusens> I guess no one likes the better solution of not using debs for testing
[15:42] <pmcgowan> everything clic sounds better
[15:43] <ogra_> pmcgowan, that would only test one the right way
[15:43] <ogra_> and you cant buold two at the same time
[15:43] <pmcgowan> same as we are doing really
[15:43] <pmcgowan> ok
[15:43] <rsalveti> we could just pre-install the core deps, and have everything else as click
[15:43] <ogra_> would always be serialized ... with potentially added new packages in the second one
[15:43] <ogra_> rsalveti, but thats what we do already
[15:43] <rsalveti> that would be the best way I guess
[15:43] <pmcgowan> ogra_, how about a separate fs partition or something
[15:44] <rsalveti> ogra_: we don't, we're installing packages :-)
[15:44] <pmcgowan> guess that wouldnt work
[15:44] <rsalveti> ogra_: my idea is to still test with a RO image, and only using clicks for everything
[15:44] <rsalveti> including autopilot tests
[15:44]  * ogra_ liked the chroot in /home/phablet idea 
[15:44] <asac> rsalveti: imo, its not a problem to install test packages and helper libraries as long as you dont do that no a running system
[15:44] <asac> then you can RO it again
[15:44] <ogra_> well
[15:44] <rsalveti> asac: that's still a problem
[15:45] <asac> without changing anything that is not in the packages
[15:45] <ogra_> but the system *is* running
[15:45] <rsalveti> as that package could bring an additional dependency
[15:45] <asac> it doesnt need to be running
[15:45] <rsalveti> and we're still not going to test the same thing
[15:45] <asac> thats why i say :)
[15:45] <sergiusens> asac: not really; look how the phonesim package broke the image testing
[15:45] <asac> you can prep the tarball outside the phone
[15:45] <ogra_> and it suddenly has the ability to write to places it couldnt wriote to before
[15:45] <asac> and flash that
[15:45] <sergiusens> it wasn't really the image going out you were testing
[15:45] <ogra_> so it will use that
[15:45] <rsalveti> the only way to test the same image, is to not change it :-)
[15:45] <ogra_> right
[15:45] <rsalveti> that's why using clicks works best
[15:45] <sergiusens> but a newly created monster consisting of image + every test dep
[15:45] <ogra_> so have a giant click with a chroot inside ;)
[15:46] <rsalveti> sergiusens: do we know if it'll be that big?
[15:46] <sergiusens> ogra_: I have a concept of pyinabox that sort of works
[15:46] <ogra_> that installs to ~ and runs all tests
[15:46] <rsalveti> if that big, we can just create a click with the dependencies
[15:46] <asac> we can package our testsuites in click, yes.
[15:46] <ogra_> sergiusens, you said the same thing in london ... finish it :)
[15:46] <sergiusens> rsalveti: well problem is phonesim
[15:46] <ogra_> code rules
[15:46] <sergiusens> ogra_: I want QA to work on it
[15:46] <rsalveti> then we solve that separately
[15:46] <sergiusens> ogra_: I come up with the concept
[15:46] <sergiusens> they should do it
[15:46] <ogra_> right
[15:47] <rsalveti> ogra_: yeah, I remember sergiusens said he had the solution as well :P
[15:47] <sergiusens> rsalveti: and that I was going to let QA decide best
[15:47] <rsalveti> QA?
[15:47] <rsalveti> shouldn't be our CI team?
[15:47] <ogra_> but instead they play with phones all day  ... finding our secretly hidden "easter eggs"
[15:47] <sergiusens> rsalveti: when I did this, I wasn't considering phonesim requrements
[15:47] <sergiusens> rsalveti: that just tramples on upstart
[15:47] <sergiusens> so they should hold the domain
[15:48] <rsalveti> right
[15:48] <rsalveti> but nobody from the CI/QA team are here to discuss, so guess we're just wasting time :P
[15:48] <rsalveti> as we're not going to implement anything anyway
[15:48] <rsalveti> asac: should we have a meeting or something to better discuss this issue?
[15:49] <ogra_> yeah
[15:49] <sergiusens> rsalveti: QA should own it; foundations, phonedations and ci help
[15:49] <ogra_> after release though
[15:49] <rsalveti> sure, don't want a meeting for tomorrow :-)
[15:49] <ogra_> nah, today :)
[15:49] <ogra_> 4h
[15:49] <sergiusens> let's have the meeting in brazil!
[15:49] <ogra_> because we have so much time :)
[15:49] <ogra_> sergiusens, ++
[15:50] <rsalveti> hahah
[15:50] <ogra_> hmpf
[15:50] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/
[15:50] <ogra_> when did we surpass 500M
[15:50] <asac> lets not do it this week plase
[15:50] <ogra_> damned ... you dont look for two weeks and the thing grew massively
[15:50] <asac> i feel its a more fundamental thing we have to solve first
[15:50] <rsalveti> sure
[15:50] <ogra_> right
[15:50] <asac> so CI team doesnt even need to be involved
[15:50] <rsalveti> ogra_: language packs?
[15:51] <asac> until foundations and phonedations come up with a solution
[15:51] <ogra_> rsalveti, well, we didnt add any
[15:51] <rsalveti> well, who will implement the solution?
[15:51] <asac> how to build and install addons for testing and other stuff
[15:51] <rsalveti> they need to be involved to see if it'd be feasible or not
[15:51] <asac> rsalveti: once we know what needs to be done, we can get them involved
[15:51] <sergiusens> autopilot in golang would also solve all the problems :-P
[15:51] <ogra_> rsalveti, in fact xnox promised "huge amounts of space to be freed when we drop python2" ... that was when we were at 430M
[15:51] <asac> rsalveti: but i would really like to see someoen coming up with something that isn't just another bandaid on top of a bandaid etc.
[15:51] <asac> that won't come out of CI :)
[15:51] <rsalveti> asac: yup
[15:52] <sergiusens> ogra_: we should add a test to fail the image testing if it's too big
[15:52] <rsalveti> sure
[15:52] <asac> and including them will ensure we want to decide what to implement right away
[15:52] <rsalveti> we need to help with that
[15:52] <asac> we need to first solve the problem :)
[15:52] <asac> work with the foundations guys
[15:52] <ogra_> sergiusens, cdimage has something like that ... its just not switched on ... it doesnt fail, but puts a "OVERSIZED" file in place in the download dir
[15:52] <asac> imo its a problem between phonedations and foundations
[15:53] <asac> once the general concept is there, we can refine by including stakeholders like AP folks, CI etc.
[15:53] <ogra_> asac, writing testing infra is a phone/foundations job ?
[15:53] <asac> ogra_: no
[15:53] <rsalveti> ogra_: not writing
[15:53] <rsalveti> ogra_: finding a solution
[15:53] <ogra_> hmm
[15:53] <asac> ogra_: but figuring the solutionm to the wider problem of RO images
[15:53] <ogra_> ok
[15:53] <asac> and how to make them useful to developers, testing etc.
[15:53] <rsalveti> as tjos os core to us as well
[15:53] <rsalveti> *this
[15:53] <asac> how to do packaging of addons that are not apps
[15:53] <asac> etc.
[15:53] <asac> i think rsalveti understands why i think it first needs to be solved on a concept level by phonedations/foundations
[15:54]  * ogra_ thinks this is a bit on the edge to QA ... but i'm willing to accept it is also a *dations task 
[15:54] <asac> QA?
[15:54] <rsalveti> ogra_: at least until we can all agree at a single soltuion
[15:54] <asac> qa has no business desinging our OS
[15:54] <ogra_> asac, no, but testing it
[15:54] <rsalveti> ogra_: we don't even agree to what needs to be done :-)
[15:54] <asac> this is a fundamental OS oproblem right
[15:54] <asac> now
[15:54] <rsalveti> right
[15:55] <asac> lets talk about this tomorrow in leads meeting
[15:55] <popey> olli_: you'll need to speak to bfiller about notes app on bug 1288885
[15:56] <bfiller> popey, olli_ : I have an mr for that
[15:56] <rsalveti> sounds fine
[15:56]  * ogra_ goes back to grumble about image oversizedness
[15:58] <grepped> I am going to buy MOTO G, but I want to use Ubuntu-touch on it. Let me know if ubuntu-touch is available for it
[16:00] <rsalveti> ogra_: it's indeed really big
[16:00] <rsalveti> ogra_: 20140408 is already bad
[16:00] <ogra_> right
[16:01] <ogra_> i have no idea where that came from
[16:01] <ogra_> we didnt do any mass-adding of packages or so
[16:02]  * sergiusens goes for lunch
[16:03] <mterry> doanac, fginther: OK, have a gander at https://code.launchpad.net/~mterry/ubuntu-test-cases/touch-unlock-device/+merge/215911 when you have time
[16:05] <doanac> mterry: ack. we won't be making any changes until after thursday, but I'll queue this up for testing this week
[16:05] <mterry> doanac, reasonable  :)
[16:05] <bfiller> popey: https://code.launchpad.net/~bfiller/notes-app/fix-exec-path/+merge/215914
[16:06] <popey> bfiller: done.
[16:31] <kyleN> Hey, I have a question about codenames. Specifically it seems to me that we use "flo" when we should use "razor" on the touch install instructions here: https://wiki.ubuntu.com/Touch/Install
[16:32] <kyleN> which makes the nexus 7 2013 wifi link incorrect and inconsistent the other target platforms.
[16:33] <kyleN> I added a note below the Supported Devices table there yesterday and would like to clarify this now.
[16:34] <kyleN> pmcgowan, do you know who I should direct this question to?
[16:35] <pmcgowan> kyleN, ask rsalveti but if I recall a prior discussion flo is consistent
[16:36] <kyleN> pmcgowan, if you look at the page and follow the link you will see the flo link is wrong
[16:36] <rsalveti> flo is the real device name when building the image
[16:36] <rsalveti> razor is the way google calls it
[16:36] <pmcgowan> kyleN, I see yep
[16:36] <pmcgowan> kyleN, you are correct for that use
[16:37] <pmcgowan> kyleN, right so just fix the link and the naming
[16:37] <kyleN> I understand flo is the driver code  name. this case is image restore code name. so 'razor' it shall be
[16:38] <kyleN> ack
[16:38] <rsalveti> right
[16:51] <rickspencer3> is anyone else having trouble with system settings crashing when they try to run updates?
[16:52] <mhall119> I've had it crash on several things
[16:52] <asac> hmm
[16:52] <rickspencer3> so, this is really bad
[16:52] <rickspencer3> this means I can't update
[16:52] <rickspencer3> (with the gui)
[16:53] <asac> seb128: ^
[16:53] <Laney> Do you have a crash file?
[16:53] <seb128> hum, first time I read about that
[16:53] <seb128> what Laney said
[16:53] <rickspencer3> Laney, yes, I already apport-cli'd it
[16:54] <rickspencer3> I can upload it by hand somewhere if you want
[16:54] <mhall119> rickspencer3: close all other apps and then try launching it, that usually works for me
[16:54] <asac> ogra_: how did your whoospie submission go?
[16:54] <asac> could rickspencer3 use that?
[16:54] <asac> mhall119: well, that's not a solution :)
[16:54] <rickspencer3> no, it just crashes every single time I click on updates
[16:55] <rickspencer3> Laney, seb128 do you guys want me to do something?
[16:55] <rickspencer3> mhall119, are you able to click on Updates in system settings?
[16:55] <seb128> rickspencer3, report the issue using whoopsie
[16:55] <rickspencer3> seb128, so, I think I already did that
[16:55] <rickspencer3> but, this seems quite serious
[16:55] <rickspencer3> I can't update now
[16:55] <Laney> is it https://errors.ubuntu.com/problem/9a9a51201599dfbe82e30dfd944a00e2ffaa8bbb ?
[16:55] <seb128> rickspencer3, do you have a link/url for the report?
[16:55] <nerochiaro> artmello__: if you come up with anything on these lost mouse events, please let me know by email. thanks
[16:55] <Laney> these don't have useful traces
[16:56] <mhall119> rickspencer3: yes
[16:56] <rickspencer3> mhall119, do you have automatic updates enabled, or disabled?
[16:56] <mhall119> rickspencer3: it just finished downloading r296
[16:56] <rickspencer3> for me, it's set to "Never"
[16:56] <mhall119> rickspencer3: I have auto-download disabled
[16:56] <rickspencer3> weird
[16:56] <rickspencer3> I wonder if I am out of disk space or something
[16:57] <seb128> rickspencer3, can you copy the .crash online somewhere/share it?
[16:57] <rickspencer3> seb128, sure
[16:57] <rickspencer3> seb128, which one?
[16:57] <rickspencer3> -rw-r----- 1 phablet  whoopsie 4670471 Apr 15 12:51 _usr_bin_system-settings.32011.crash
[16:57] <rickspencer3> -rw-rw-rw- 1 root     whoopsie       0 Apr 15 12:47 _usr_bin_system-settings.32011.upload
[16:57] <rickspencer3> -rw------- 1 whoopsie whoopsie       0 Apr 15 12:47 _usr_bin_system-settings.32011.uploaded
[16:57] <seb128> rickspencer3, the .crash :p
[16:57] <ogra_> asac, didnt go so well, seems the daisy server has issues
[16:58] <seb128> rickspencer3, e.g the only non 0 one
[16:58] <kyleN> pmcgowan, rsalveti I updated/clarified the table & section
[16:58] <ogra_> asac, but ev was looking into it
[16:58] <rickspencer3> oops
[16:58] <rickspencer3> lol
[16:58] <rickspencer3> right
[16:58] <cjwatson> sergiusens: can you give me a test case I can use to reproduce that "click chroot" thing with Qt5Qml/Qt5Quick?  the chroot seems to contain the necessary packages
[16:59] <rickspencer3> seb128, I emailed it to you
[16:59] <cjwatson> sergiusens: like a tar of your current directory when running http://paste.ubuntu.com/7251105/, or something
[16:59] <rickspencer3> < 5 megs
[16:59] <seb128> rickspencer3, thanks
[17:00] <kyleN> pmcgowan, fyi I have been asked to move the install instructions to the dev portal. so this page will become a link to the portal and I'll refactor the text for clarity. release notes and similar will stay on the wik.
[17:00] <pmcgowan> kyleN, not sure I am +1 on that
[17:01] <pmcgowan> kyleN, installs are not just for devs
[17:01] <kyleN> pmcgowan, then you need to talk to jono who asked me to do this.
[17:01] <pmcgowan> kyleN, I could see simpler get the stable image instructions, but we should still have some
[17:02] <kyleN> pmcgowan, actually, I have been writing up a clearer explanation of the whole thing, for example explaining channels with more clarity
[17:03] <pmcgowan> kyleN, cool would be happy to review if you want
[17:04] <seb128> Laney, rickspencer3: that crash is
[17:04] <seb128> #0  0xaae69f76 in SignOn::Identity::createSession(QString const&) ()
[17:04] <seb128>    from /usr/lib/libsignon-qt5.so.1
[17:04] <seb128> #1  0xaaedfaee in UbuntuOne::Keyring::findToken() ()
[17:04] <seb128>    from /usr/lib/arm-linux-gnueabihf/libubuntuoneauth-2.0.so.0
[17:04] <seb128> #2  0xaaf074ec in UpdatePlugin::UpdateManager::checkUpdates() ()
[17:04] <seb128>    from /usr/lib/arm-linux-gnueabihf/ubuntu-system-settings/private/Ubuntu/SystemSettings/Update/libUbuntuUpdatePanel.so
[17:04] <seb128> so ubuntuone/signon issue
[17:05] <rickspencer3>  wow
[17:05] <seb128> mardy, ^ is that known?
[17:05] <rickspencer3> seb128, so I should try to relog into U1 and try again?
[17:05] <asac> maybe somewhat extract the state of yhour U1 login?
[17:05] <asac> before?
[17:05] <seb128> rickspencer3, not sure, in any case it seems like a valid issue in their code
[17:05] <asac> not sure what would help to figure what state that thing is in
[17:05] <seb128> would be nice to have somebody knowing how to debug that to help before you wipe the state
[17:05] <asac> right
[17:06] <rickspencer3> ok, I'll chill out
[17:06] <seb128> mardy would know but he might be eod at this time
[17:06] <asac> rickspencer3: do you have two routes?
[17:06] <asac> err two default routes?
[17:06] <rickspencer3> asac, no
[17:06] <asac> ok thought might have been triggered by https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1307981
[17:07] <cyphermox> asac: no
[17:07] <asac> cyphermox: ?
[17:08] <rickspencer3> asac, ok
[17:08] <rickspencer3> I bet that's what it is
[17:08] <asac> cyphermox: sure that this cannot cause ubuntuone state get messed about online state?
[17:08] <rickspencer3> I was logged onto my wrong access point
[17:08]  * rickspencer3 tries with correct access point
[17:09] <rickspencer3> still crashes
[17:09] <asac> ok
[17:09] <asac> well, wait for the experts to arrive
[17:09]  * rickspencer3 tries tablet
[17:09] <asac> mardy: dbarth: see the trace that seb128 has
[17:09] <asac> above
[17:10] <rickspencer3> works fine on my tablet, which only has the one working access point
[17:10] <rickspencer3> seb128, app updates in Updates Pane looks nice!
[17:10] <seb128> rickspencer3, thanks ;-)
[17:11] <asac> rickspencer3: ok, so browsing etc. works well on your phone right now and it still crashes?
[17:11] <rickspencer3> asac, correct
[17:11] <ogra_> rickspencer3, yeah, it just "upgraded" my local dict webapp from 0.4 to 0.3 ...
[17:11] <rickspencer3> the only symptom I seem to have is that the updates pane crashes
[17:12] <rickspencer3> even Karma machine works :)
[17:12] <seb128> rickspencer3, is the software-upgrade app working?
[17:13] <rickspencer3> seb128, when I run Update Manager, it also crashes
[17:13] <seb128> k
[17:13] <rickspencer3> or at least that's what it looks like, it doesn't run in any case
[17:13] <asac> if so, we can probably rule out bogus networking as the source.
[17:13] <asac> next idea plz
[17:13] <seb128> not surprising since the issue seems in the backend/u1 auth
[17:15] <rickspencer3> man, this really makes me think we need to work on the robustness and testing for our system updates
[17:15] <rickspencer3> we talked a lot about it after the last set of problems, but I'm not sure we ever designed the "bullet proof" version
[17:15] <asac> i think i heard that before
[17:16]  * ogra_ hugs mpt for revisiting bug 1296431
[17:16] <ogra_> this is really annoying
[17:16] <rickspencer3> that's not true, it already you by turning off
[17:16] <rickspencer3> what could go wrong?
[17:16] <rickspencer3> oops
[17:16] <rickspencer3> "alerts you" by turning off
[17:17] <ogra_> great :P
[17:17] <ogra_> it alerts me three times a day :P
[17:17] <ogra_> (which screams: we really need to improve power consumption next cycle)
[17:18] <rickspencer3> ogra_, interesting
[17:18] <rickspencer3> my phone easily lasts throughout a day
[17:18] <rickspencer3> so long as I am not watching movies on it, etc...
[17:18] <ogra_> in your pocket
[17:18] <rickspencer3> ogra_, no, I use it for calls and texting and the browser and etc...
[17:18] <rickspencer3> I use it a lot
[17:18] <ogra_> mine is nearly constantly on during the work day
[17:18] <dbarth> asac: which one?
[17:18] <rickspencer3> mine is my only phone
[17:18] <rickspencer3> so it's always on
[17:19] <ogra_> i never do calls (apart from test calls) but use a ton of webapps
[17:19] <dbarth> asac: ah ok, on it
[17:19] <asac> 19:04 < seb128> Laney, rickspencer3: that crash is
[17:19] <asac> 19:04 < seb128> #0  0xaae69f76 in SignOn::Identity::createSession(QString const&) ()
[17:19] <asac> 19:04 < seb128>    from /usr/lib/libsignon-qt5.so.1
[17:19] <asac> 19:04 < seb128> #1  0xaaedfaee in UbuntuOne::Keyring::findToken() ()
[17:19] <asac> 19:04 < seb128>    from /usr/lib/arm-linux-gnueabihf/libubuntuoneauth-2.0.so.0
[17:19] <asac> 19:04 < seb128> #2  0xaaf074ec in UpdatePlugin::UpdateManager::checkUpdates() ()
[17:19] <ogra_> rickspencer3, i mean the screen is up all day on mine
[17:19] <asac> 19:04 < seb128>    from /usr/lib/arm-linux-gnueabihf/ubuntu-system-settings/private/Ubuntu/SystemSettings/Update/libUbuntuUpdatePanel.so
[17:19] <asac> 19:04 < seb128> so ubuntuone/signon issue
[17:19] <asac> 19:04 < rickspencer3>  wow
[17:19] <asac> 19:05 < seb128> mardy, ^ is that known?
[17:19] <asac> that one
[17:19] <rickspencer3> ogra_, ah, yeah, that'll do it
[17:19] <asac> dbarth: ok
[17:20] <ogra_> (i dont do G+ on my PC for example)
[17:20] <ogra_> and with oxide it can now cope with android :)
[17:20] <dbarth> seb128: do you have an open bug for that one?
[17:20] <dbarth> (or do you want me to open one)
[17:21] <seb128> dbarth, not sure, rickspencer3 said he submitted it with apport but I can't find it
[17:21] <seb128> well maybe it's not in launchpad, only e.u.c
[17:21] <Laney> I was guessing that but I didn't find it there
[17:21] <rickspencer3> I can just quickly make a bug
[17:21] <Laney> seb128: you have it now so you can ubuntu-bug it
[17:21] <rickspencer3> and upload the crash file
[17:21] <dbarth> rickspencer3: if you have the crash file, yes, better
[17:21] <Laney> ubuntu-bug <crash file> is a good way to file a bug given one of those
[17:22] <dbarth> yup
[17:22] <dbarth> rickspencer3: just ping me the bug and i'll prioritize with mardy
[17:22] <ogra_> seb128, thats an issue with whoopsie (as i said above)
[17:22] <ogra_> or rather with the server
[17:22] <mhall119> alecu: Saviq: the "Apps >" tab header in the dash is always centered the first time I get to it, rather than left-aligned
[17:22] <ogra_> seb128, ev started looking into it this morning
[17:22] <Saviq> mhall119, it's going away
[17:23] <Saviq> mhall119, in favour of the new app header
[17:23] <Saviq> mhall119, and is a bug in UITK
[17:23] <sergiusens> cjwatson: bzr branch lp:camera-app is enough for me to get that pastebin
[17:23] <mhall119> any ETA on when new app header will land?
[17:23] <rickspencer3> dbarth, is there a better way to do it than manually creating a bug and attaching the .crash file?
[17:24] <dbarth> rickspencer3: ubuntu-bug like Laney reminded me
[17:24] <dbarth> rickspencer3: works on your phone
[17:24] <ogra_> rickspencer3, ubuntu-bug should do it for you
[17:24] <ogra_> it will give you an URL you can click on
[17:24] <rickspencer3> hmmm, I used apport-cli to report it last time, let me try that one
[17:29] <mamenyaka> is there a 4.4.2 branch for ubuntu touch?
[17:29] <rickspencer3> dbarth, ogra_ so I never got a lp bug out of it
[17:29] <rickspencer3> not sure what I did wrong
[17:30] <rickspencer3> for your yack shaving pleasure:
[17:30] <rickspencer3> http://pastebin.ubuntu.com/7256465/
[17:30] <ogra_> thats weird
[17:30] <ogra_> mamenyaka, yes, look at phablet-ubuntu.com ... there are aosp branches ...
[17:30] <ogra_> err
[17:30] <mamenyaka> ogra_: hi!
[17:30] <ogra_> phablet.ubuntu.com
[17:30] <ogra_> there is also a wikipage somewhere afaik
[17:30] <cjwatson> sergiusens: works for me
[17:31] <mamenyaka> i looked, but do I need to manually check out the ones I need?
[17:31] <ogra_> not sure, i rarely do that :)
[17:31] <cjwatson> sergiusens: as in, no errors from run cmake -DCLICK_MODE=1 or run make
[17:31] <sergiusens> cjwatson: hmmm, and you sudo click chroot -aarmhf -f ubuntu-sdk-14-04-dev1-papi create ?
[17:31] <sergiusens> papi/qml
[17:31] <dbarth> rickspencer3, ogra_: could be due to the the upstream package ref. in launchpad
[17:31] <cjwatson> sergiusens: well, "sudo click chroot -a armhf -f ubuntu-sdk-14.04 create", but it should be equivalent
[17:32] <dbarth> i'll create one real quick for you to upload the crasher
[17:32] <sergiusens> cjwatson: let me try creating it like that
[17:32] <cjwatson> sergiusens: they're just convenience aliases basically
[17:33] <cjwatson> sergiusens: well, except that the alias is "ubuntu-sdk-14.04-papi-dev1" not "ubuntu-sdk-14-04-dev1-papi", but your paste matches the correct version
[17:33] <sergiusens> cjwatson: so if you create it with the alias and run with the alias it will map to the same thing
[17:33] <sergiusens> yeah, sorry, I'm always mixing that part
[17:34] <sergiusens> but I get a key not found error and notice it quickly enough :-)
[17:34] <cjwatson> sergiusens: the alias is mapped right at the start and never used directly otherwise
[17:35] <sergiusens> I'm creating a new chroot now and waiting to see if this was a hiccup as ogra_ originally anticipated wrt to seeds
[17:35] <ogra_> sergiusens, no, that was different
[17:35] <mamenyaka> ogra_: is there anyone still working on the ports?
[17:36] <ogra_> there was an autopkgtest failure of some sso componnent that confused the world
[17:36] <sergiusens> if it works today and failed yesterday...
[17:36] <sergiusens> mamenyaka: actively there's samsung s5 that I am aware of
[17:36] <ogra_> right, that was fixed quickly yesterday
[17:36] <sergiusens> meh
[17:36] <sergiusens> nexus 5 I mean
[17:36] <ogra_> haha
[17:36] <ogra_> spread the rumours !
[17:36] <dbarth> rickspencer3: https://bugs.launchpad.net/ubuntu/+source/signon/+bug/1308164
[17:38] <mamenyaka> here's my main problem: i'm still on the phabet-trusty branch, but libhybris gives me build errors
[17:38] <rickspencer3> dbarth, done
[17:38] <dbarth> ty
[17:38] <mhall119> where am I supposed to see app updates in ubuntu-system-settings?
[17:38] <mamenyaka> and apparently it need some files which are only available in the newer branches
[17:39] <ogra_> where you see image updates
[17:39] <mhall119> ok, so there just aren't any right now
[17:39] <ogra_> for me there was one ... "upgrading" one of my locally installed apps from 0.4 to 0.3
[17:40] <mamenyaka> ubuntu/libhybris/compat/media/media_codec_layer.cpp:51:40: fatal error: gui/IGraphicBufferProducer.h: No such file or directory
[17:43] <seb128> rickspencer3, dbarth: I set that bug to private, that's a dump of a process which deal with online credential, it could include private info
[17:43] <rickspencer3> thanks seb128
[17:43] <seb128> yw
[17:44] <seb128> subscribed mardy / Laney to the bug, we can subscribe more people if needed
[17:44] <mamenyaka> sergiusens: can you help me?
[17:46] <cjwatson> ogra_: It wasn't an autopkgtest failure - it was a double-override that caused a package to go missing from the archive for a brief period
[17:46] <sergiusens> mamenyaka: I think this should work phablet-dev-bootstrap --sources aosp --repo-branch phablet-4.2.2_r1 my_dir
[17:46] <cjwatson> ogra_: It's certainly possible that that could have confused "click chroot create", though I haven't traced the dependencies
[17:46] <sergiusens> dbarth: hey, Elleo had an MR for the webapps so we could upload content; care to apply it?
[17:47] <mamenyaka> sergiusens: thanks, looks like its doing its job
[17:49] <Elleo> sergiusens: from what I hear it's in the queue to be uploaded soon
[17:52] <mamenyaka> is this still valid? https://wiki.ubuntu.com/Touch/AOSPBuild
[17:53] <davmor2> Who would be the best person to talk to about the multiple call feature
[17:58] <dbarth> sergiusens: it's applied
[17:58] <dbarth> sergiusens: the apps should be in the store upload queue
[17:59] <dbarth> seb128: +1
[17:59] <sergiusens> cjwatson: just created from scratch and still seeing the issue; any quick thoughts on what it could be?
[17:59] <sergiusens> dbarth: Elleo great!
[18:00] <Laney> rickspencer3: do you have a file /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log that you could attach?
[18:01] <rickspencer3> I can try
[18:01] <sergiusens> popey: can you check those webapps enqueued? I seem to have lost my happroval powers :-/
[18:01] <popey> ya
[18:01] <Laney> Just subscribed you so you can see it
[18:01] <sergiusens> popey: thanks, it's a good happroval fwiw :) will allow content uploads :-)
[18:02] <rickspencer3> Laney, done
[18:03] <popey> sergiusens: you mean in the store?
[18:03] <Laney> rickspencer3: Cheers, do you have a /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log.1.gz file too?
[18:03] <Laney> That didn't contain what I thought it might
[18:04] <Laney> ("findToken(): Using Ubuntu One account" ...)
[18:04] <popey> bueno what do we do with webapps which error with "found unusual policy groups: content_exchange" ?
[18:05] <Laney> Anyway, gtg, just hoping to get information that mardy might find useful tomorrow
[18:05] <Elleo> popey: sounds like the definition of "unusual" will need to change, more and more webapps are likely to have that policy as it's what allows them to do file uploads now the webapp container supports it
[18:05] <sergiusens> popey: yea; approve in the store (the webapps) and those webapps will allow content uploads
[18:06] <Elleo> the content_exchange policy allows for communication with content-hub
[18:06] <sergiusens> popey: hmm, that might be an outdated policy check?
[18:06] <sergiusens> jdstrand: ^^
[18:06] <popey> sure, but strictly the fact is it's an "error" in the process, not a warning
[18:06] <rickspencer3> Laney, done
[18:07] <sergiusens> popey: I think you mistyped beuno :-)
[18:07] <popey> oh, i did ☻
[18:07] <Laney> Ta
[18:07] <beuno> :)
[18:08] <beuno> popey, so that's in the review script
[18:08] <popey> yes
[18:08] <beuno> currently mostly owned by jdstrand and dholbach
[18:08] <beuno> are you certain it's outdated?
[18:08] <popey> i bzr pull every time I check an app
[18:09] <popey> so I know I'm running latest click-reviewers-tools
[18:09] <beuno> popey, I understand, I guess I'm asking if you know for sure the script is wrong  :)
[18:09] <popey> well, I'm not suggesting it's wrong
[18:10] <popey> I'm saying I am getting an error when trying to accept an app which the guys here want approved
[18:10] <popey> and I will block that unless someone tells me otherwise
[18:10] <beuno> sure
[18:10] <beuno> that's what the scripts are for!
[18:10] <popey> Very soon I expect to be replaced by a small shell script
[18:10] <beuno> looks like I haven't added any value to this conversation
[18:11] <popey> well dholbach is eod
[18:12] <Elleo> beuno: for context, this is in relation to recent features added to the webbrowser/webapp-container which allow for file uploads via content-hub
[18:12] <popey> so we need jdstrand
[18:12] <beuno> right
[18:12] <Elleo> so until friday that policy probably made perfect sense, since there was no reason for a webapp to be talking to content-hub
[18:12] <beuno> jdstrand owns new policies
[18:13] <jdstrand> ?
[18:13] <Elleo> but now it's required for anything wanting to use the file upload features
[18:13] <popey> jdstrand: we have new webapps in the store which require content_exchange policy group, but the click-reviewer-tools tag it as "unusual" and error.
[18:14] <jdstrand> popey: ok, can you file a bug. I have a few of things accumulated to fix
[18:14] <jdstrand> s/of//
[18:14] <Elleo> presumably it's just for webapps that it considers content_exchange unusual?
[18:14] <Elleo> since the gallery click package would use that too
[18:14] <jdstrand> it would just be webapps
[18:14] <davmor2> pmcgowan: Hey who would be the best person to talk to about the multi call feature in UT?
[18:15] <pmcgowan> davmor2, boiko and bfiller_afk
[18:16] <davmor2> pmcgowan: thanks
[18:16] <popey> jdstrand: https://bugs.launchpad.net/click-reviewers-tools/+bug/1308184
[18:17] <davmor2> boiko, bfiller_afk: with the new multicall feature I can connect to two calls but merging doesn't happen, I wanted to double check if there is a service that I might need to activate from my provider before I dig into it and file a bug
[18:18] <pmcgowan> popey, beuno really need a way to log bugs on store apps
[18:19] <jdstrand> popey: thanks!
[18:20] <popey> pmcgowan: such as?
[18:21] <pmcgowan> popey, every new app I download I am finding issues, and rather than email the devs, would be nice to have a project or something
[18:21] <pmcgowan> popey, like rad.io back doesnt work
[18:21] <pmcgowan> and the one with riddling the other day
[18:21] <popey> i think thats up to each dev, surely?
[18:21] <pmcgowan> and the two broken webapps
[18:21] <Elleo> centralised bug reporting for all apps on the platform would be pretty cool
[18:21] <Elleo> at least as an option for devs to enable
[18:22] <pmcgowan> right
[18:22] <Elleo> not much use if they're just going to ignore it
[18:22] <Elleo> but I know I'd much rather have had some decent bug tracking for lots of small projects on meego without having to setup lots of infrastructure myself
[18:22] <pmcgowan> Elleo, more bugs could drop their ratings
[18:23] <Elleo> pmcgowan: that could be risky, lots of users don't know the difference between a bug and a feature request
[18:23] <pmcgowan> true
[18:23] <Elleo> pmcgowan: plus you'd be insentivising devs to close bugs fraudulently
[18:23] <pmcgowan> my concern right now is the last 4 apps I got were all broken in some way
[18:23] <Elleo> a clear division between reviews and bug reports is pretty essential in my view
[18:23] <pmcgowan> and I am getting them sort of at random
[18:23] <boiko> davmor2: probably you need to activate that indeed
[18:24] <Elleo> I got pretty fed up of getting "bug reports" via reviews on nokia apps, that you then have no way to respond to/contact the person
[18:24] <pmcgowan> Elleo, so you think a built in kindof bug reporter direct to the dev?
[18:24] <davmor2> boiko: on the plus side the the call and hold multicall works well ;)
[18:25] <Elleo> pmcgowan: I think a couple of options would be best, reporting to launchpad or reporting via email or something
[18:25] <Elleo> to the user it could look identical
[18:25] <pmcgowan> sure
[18:26] <Elleo> things can get lost of they're just emailing stuff, so launchpad tracking would be the best option
[18:26] <Elleo> I'm just not sure I'd trust all devs to bother with it
[18:26] <pmcgowan> not sure
[18:26] <beuno> pmcgowan, I think R&R will do that
[18:27] <boiko> davmor2: \o/
[18:27] <beuno> if Launchpad wasn't crazy to integrate with, we could somehow use that
[18:27] <Elleo> R&R?
[18:27] <pmcgowan> beuno, that would be best
[18:27] <beuno> Ratings & Reviews
[18:27] <Elleo> beuno: I'm hoping that'd become Rating & Reviews & Bugs then ;)
[18:27] <Elleo> rather than just lumping bugs into Reviews, which gets very annoying from a dev's perspective
[18:28] <beuno> well
[18:28] <Elleo> although I'm guessing the Ubuntu review system will end up more comprehensive than Nokia's was, so that might not be as much of a pain
[18:28] <beuno> I don't think we should write *another* bug tracker
[18:29] <Elleo> but you need a clear way to interogate the reporter/review for further information
[18:29] <Elleo> because in a review scenario hardly anyone puts adequate detail
[18:29] <Elleo> since it's just a review they'll just say "$X doesn't work"
[18:33] <Elleo> Nokia's system was especially annoying in that regard because it gave no means at all of contacting the reviewer or replying to reviews
[18:34] <Elleo> so I have "reviews" (bug reports) that no one else can reproduce, but which I can't get any useful info to debug
[18:36] <beuno> Elleo, right
[18:36] <beuno> there's a challenge there to solve elegantly
[18:36] <Elleo> yeah, that might indicate that it's more natural for the user for them to communicate a bug via a review
[18:36] <popey> jdstrand: should I wait for an update tonight or leave these in the queue till tomorrow?
[18:37] <jdstrand> popey: feel free to accept them and reference the bug. content_exchange is fine for webapps now
[18:37] <Elleo> so perhaps just some way of communicating with the user about it and marking it as fixed might be enough
[18:37] <beuno> Elleo, agreed
[18:37] <beuno> or at least, a good start
[18:37] <Elleo> yeah
[18:38] <jdstrand> popey: does that work ok?
[18:38] <popey> jdstrand: thats find given you said it ☻
[18:38] <jdstrand> cool :)
[18:39] <cjwatson> sergiusens: sorry, not sure I have a clue.  Check inside the chroot whether dpkg -S says those files are there
[18:40] <popey> jdstrand: also camera is apparently unusual?
[18:40] <popey> is that an acceptable policy group name?
[18:41] <popey> (twitter webapp wants it)
[18:41] <jdstrand> popey: I was going to review them all when I do it. camera shouldn't be unusual any more either
[18:41] <popey> ok
[18:41] <jdstrand> (oxide prompts when it is in use, so nothing scary there)
[18:42] <popey> sergiusens: done
[18:43] <Elleo> popey: thanks :)
[18:43] <mardy> Laney: do you know how to make debugging symbols available to errors.ubuntu.com?
[18:44] <popey> np Elleo
[18:45] <Laney> mardy: nein, but you can work with that core dump
[18:47] <sergiusens> beuno: pmcgowan: popey let me trace you back to a conversation from august http://summit.ubuntu.com/uds-1308/meeting/21857/foundations-1308-click-error-reporting/ " and one of the agreements (I'm not fond of it still), was to use the store ratings for bugs
[18:51] <pmcgowan> sergiusens, I dont see that in the notes, and assume you mean reviews not ratings per se
[18:52] <sergiusens> pmcgowan: look at the notes!  * Do we want to support interactive bug reporting? * Evan takes the con position:  wants to move away from launchpad for bug reporting in general, and  thinks the arguments for doing this apply even more than usual to phone  users vs. desktop users  * If we need more info out of  crashes, handle on the server side with server-side hooks to provide  code to be executed on the client for a particular crash
[18:53] <famonid> It seems some html5 functionality is broken (at least for me)... http://gauth.apps.gbraad.nl/ used to work on image ~150 but it is broken now
[18:53] <pmcgowan> sergiusens, sure read that, says not launchpad, but not clear what we will do to me
[18:53] <sergiusens> pmcgowan: the use the store is hidden in the video though
[18:53] <famonid> It would be great if so could confirm my issue
[18:53] <pmcgowan> and thats all crash reporting, symbols stuff
[18:53] <mardy> Laney: OK, I'll look into that tomorrow, maybe I'll ping you for assistance :-)
[18:53] <pmcgowan> sergiusens, well, ok
[18:53] <pmcgowan> sergiusens, probably how everyone else does it
[18:53] <sergiusens> pmcgowan: yeah, you need to look at the video; but if you had ratings, you'd already have a direct way to rate an app
[18:54] <sergiusens> pmcgowan: there are a bunch that just don't work
[18:54] <sergiusens> and would be good to know from the get go
[18:54]  * sergiusens speaks as a user now
[18:54] <pmcgowan> indeed
[18:57] <dobey> pmcgowan: the suggestion was, that like most other "app stores," the app authors themselves don't want to set up some project management infrascture on lp (or anywhere else that's not their own thing), and users are more likely to just report issues in reviews anyway, so just have that and let devs filter it
[18:57] <famonid> Can someone please test the html5 authenticator from gbraad on a current image with the built in browser? It does not work for me anymore... http://gauth.apps.gbraad.nl/ If I know it does work on other devices, I am sure that the fault is at my side.
[18:58] <pmcgowan> dobey, makes sense
[18:59] <dobey> it's sort of a poor compromise, but keeping people from just writing junk in reviews is going to be hard anyway
[18:59] <dobey> and finding a solution that is really nice, is also very hard
[19:00] <ogra_> but worth the effort in the end ;)
[19:00] <dobey> a matter of argument :)
[19:00] <ogra_> no, a matter of time and manpower ;)
[19:01] <pmcgowan> ooo app updates in settings!
[19:01] <ogra_> pfft
[19:01]  * ogra_ still only got one "downdate"
[19:02] <dobey> ogra_: developing it is, yes; but whether that time and manpower was worth it in the end, is a matter of argument :)
[19:02] <ogra_> dobey, if people chose ubuntu phones because that feature is cool (among others) it will have been worth it
[19:03] <dobey> ogra_: if developers choose not to support ubuntu because we force that feature on them, maybe it wasn't worth it, though.
[19:03] <dobey> it's a thin line :)
[19:03] <ogra_> no, the feature needs to be sexy for both sides indeed
[19:04] <dobey> every feature can't be balanced on a fence ;)
[19:22] <tedg> jdstrand, Added easyprof to bug 1301400 for adding the path to the sdk confinement. Is that the best way to mark that?
[19:37] <jdstrand> tedg: every app should have that dbus access, similar to like we do with the hud?
[19:37] <tedg> jdstrand, yeah, it just allows it to set the number if it's on the launcher.
[19:38] <tedg> Will do progress in the future as well
[19:38] <jdstrand> tedg: is the access ready to be added now or still being defined?
[19:38] <tedg> jdstrand, I proposed the MR. I think it's perfect, but you might wait on a review :-)
[19:39] <tedg> jdstrand, To be clear, there's no rush. The first use case is system settings which is unconfined.
[19:40] <jdstrand> so... dbus bus=session path=/com/canonical/unity/launcher/${DBUS_APP_PKGNAME} interface=com.canonical.unity.Launcher.Item method=count{,Visible},
[19:41] <jdstrand> tedg: or can we just skip interface and method?
[19:41] <dpm> dobey, ok, app metadata internationalization mail sent to ubuntu-phone too
[19:41] <dobey> dpm: cool, thanks
[19:41] <tedg> jdstrand, No, interface is fd.o properties. And it's not PKGNAME because it's the full app id. There could be an icon for each app.
[19:41] <jdstrand> dbus bus=session path=/com/canonical/unity/launcher/${DBUS_APP_ID}, ?
[19:41] <tedg> jdstrand, Yeah
[19:42] <jdstrand> @{APP_ID_DBUS}
[19:42] <jdstrand> tedg: right, ok. I'll add that note to the bug and will add it to the next upload
[19:42] <tedg> jdstrand, Cool, thanks!
[19:44] <jdstrand> np
[19:45] <rickspencer3> mardy, wrt bug #1308164
[19:45] <rickspencer3> shall I go ahead and enable the U1 account and try again?
[19:59] <mhall119> app updates on ubuntu-system-settings doesn't wrap the app icon in UbuntuShape, is this by design?
[20:01] <ajalkane> What's the correct procedure for cross-compiling Ubuntu touch application for ARM? The instructions I have seem to build executables for x86 when I build on x86
[20:04] <popey> ajalkane: cross-compiling just landed in qtc as I understand it from dpm earlier
[20:04] <pmcgowan> you make an arm chroot and target the build there
[20:04] <dpm> it landed a while ago
[20:04] <dpm> but the UX is much better now
[20:04] <pmcgowan> dpm, did we update docs yet?
[20:05] <ajalkane> any learn-it-in-minute-for-dummies instructions for command-line compilation?
[20:05] <dpm> pmcgowan, not that I know
[20:05] <popey> dpm: heh, see my question from earlier for ajalkane ☻
[20:06] <dpm> ajalkane, no need to do it from the command line, you can open the CMakeLists.txt file, and Qt Creator will ask you which build targets you want. If you select the 14.04 click build,
[20:06] <ajalkane> dpm: okay thanks... so I guess apt-get dist-upgrade is needed as I think I have few weeks old version
[20:06] <dpm> then you can choose it from the kits menu right above the big green "Play" button
[20:07] <dpm> once you've done that, then when you do a build using Ctrl+B or the button, it will build it in the arm chroot
[20:07] <ajalkane> Okay that's nice... I'm still living in the ancient past where click packages did not build correctly in QTC :)
[20:08] <dpm> :-)
[20:08] <dpm> if you need any extra dependencies for the build, Tools > Options > Ubuntu > Click > Maintain and install them from there
[20:09] <ajalkane> Ok great, thanks
[20:11] <dpm> ajalkane, let me know if you've got any questions. Did you see my comments on some of your MPs? I think they are already merged, but are listed as pending. It'd be great if you could confirm that and mark them as merged if that's the case - thanks!
[20:15] <ajalkane> dpm: sure thing, I saw the mails but when I looked at the to be merged list I didn't see them. I'll take a closer look, but anyway those oldies are definitely merged.
[20:27] <dpm> ajalkane, ok, cool, thanks! Development should also be easier now that the code for the app and the plugin is all in the same branch, and Qt Creator can build the whole thing together :)
[20:33] <ajalkane> Alright, I will try building with QTC the needed click package during this week.
[20:34] <popey> mhall119: i think that's a bug in ubuntu-system-settings..