[04:02] <hackersarchangel> howdy everyone
[04:48] <hackersarchangel> Well I was trying to get Ubuntu Touch to recognize my files from Android using mount —-bind but all that was doing was getting it to show up in Full Mode/Terminal but not in the Music app.
[04:48] <hackersarchangel> So at this point, I suspect a permissions issue but I took ownership of the files.
[04:48] <lotuspsychje> hi mate
[04:48] <hackersarchangel> Ah well.
[04:48] <lotuspsychje> wich device your on?
[04:49] <hackersarchangel> howdy
[04:49] <hackersarchangel> hammerhead/Nexus 5
[04:49] <lotuspsychje> cool
[04:49] <lotuspsychje> nexus7 here
[04:49] <hackersarchangel> I’m not overly worried about that, in all honesty I’m more concerned with my lack of SMS xD
[04:49] <lotuspsychje> does it run well on n5?
[04:49] <lotuspsychje> test message buggy for you?
[05:08] <hackersarchangel> yeah it runs fine.
[05:08] <hackersarchangel> In fact if SMS worked I’d use it all the time, just use it instead.
[05:09] <lotuspsychje> i also have a few bugs on nexus7
[05:09] <lotuspsychje> like brightness control resets every boot
[05:10] <lotuspsychje> you also have this on n5?
[05:10] <hackersarchangel> Yeah well it’s the price we pay for using Beta software
[05:10] <hackersarchangel> Yep. I turned on Auto Brightness
[05:10] <hackersarchangel> that helps it
[05:11] <lotuspsychje> what happens on auto brightness?
[05:11] <hackersarchangel> It is initially reset but it then takes over properly and just adjusts it.
[05:11] <lotuspsychje> ill try it later on
[05:11] <lotuspsychje> i need 100% all the time :p
[05:12] <lotuspsychje> well, at least we have a secure Os on tablet/phone :p
[05:12] <hackersarchangel> Well the auto brightness does a good job.
[05:12] <lotuspsychje> nothing like android nightmare
[05:12] <lotuspsychje> tnx for the tip, ill try it
[05:12] <hackersarchangel> Well Android could be much much worse.
[05:12] <lotuspsychje> howso?
[05:12] <hackersarchangel> But yeah I prefer having a true Linux base to work with.
[05:13] <hackersarchangel> Well they could easily just install whatever they wanted and by they I mean bad people.
[05:13] <lotuspsychje> so much malicious on android
[05:13] <hackersarchangel> At least there are barriers if you use it properly.
[05:13] <lotuspsychje> but i have to admit android still runs smoother for now
[05:13] <lotuspsychje> i hope the RTM touch gets real stable
[05:14] <lotuspsychje> hackersarchangel: you think release of Bq and meizu will influence ubuntu touch?
[05:14] <hackersarchangel> Yep.
[05:14] <lotuspsychje> i also think :p
[05:14] <hackersarchangel> I think it will at least do something to shake people up, and it will probably help it get a better reputation if nothing else.
[05:15] <lotuspsychje> true
[05:15] <lotuspsychje> i miss my terminal apps so badly
[05:15] <lotuspsychje> i wanna get them on touch
[05:15] <lotuspsychje> but cant because dir lock
[05:16] <lotuspsychje> hackersarchangel: do you also run the devel version on your n5?
[06:01] <bzoltan> mvo_: Please sync this MR with the branch, it seems to conflict after your last MR, what finally landed  https://code.launchpad.net/~mvo/qtcreator-plugin-ubuntu/lp1366786-click-deploy
[06:01] <mvo_> hi bzoltan, let me have a look
[06:02] <bzoltan> mvo_: Thank you :)
[06:04] <mvo_> bzoltan: np, I updated the branch and fixed the conflicts
[06:04] <bzoltan> mvo_:  Great. I will include that to the actual landing (silo3) and ping you when it is ready for review.
[06:32] <dholbach> good morning
[06:51] <afiskon> Hello everyone. I was using ubuntu touch (devel, 203r @ lg nexus 4) for a few days and noticed some problems with a clock. When I'm not using a smartfone for some time time freezes. I.e. lockscreen shows 10:30 PM, but a real time is 10:45 PM. Same story with system tray (or how it's called here?)
[06:52] <afiskon> I believe for the same reason alarm never works :(
[06:53] <afiskon> Is there any known workaround for this issue?
[08:19] <JamesTait> Good morning all; happy Swap Ideas Day! :-D
[08:41] <mailyaseen> popey : we have 4 diferent section in UT.. scope, apps, music and videos... so there will be any option in future to change them, like adding new one or removing any one
[08:41] <popey> mailyaseen: yes, you can change them
[08:41] <mailyaseen> popey: how can i change them?
[08:42] <popey> swipe up from the bottom in the dash
[09:10] <mailyaseen> popey : but i cant delete any existing section, or cant add any new section there....
[09:11] <popey> mailyaseen: yeah, you use the star icon in the top right to favorite them
[09:11] <popey> maybe you're on an older image than me ☻
[09:11] <mailyaseen> popry : i am on r203...
[09:12] <popey> I'm on 235 here
[09:13] <mailyaseen> popey : then i will wait for stable release... and will make use of that, to remove or add section
[09:13] <mailyaseen> popey: thank you
[09:25] <popey> mailyaseen: no problem!
[09:43] <Dyerdyuz> Um, hi.
[09:43] <Dyerdyuz> I want to ask some questions.
[09:43] <Dyerdyuz> What's the safest way to repair my grub?
[09:49] <davmor2> D
[10:05] <Akiva-Thinkpad> morning all
[10:09] <davmor2> Akiva-Thinkpad: morning
[10:09] <Akiva-Thinkpad> hey davmor2
[10:10] <Akiva-Thinkpad> what you working on today?
[10:10] <davmor2> Akiva-Thinkpad: same as always new an interesting ways of destroying Ubuntu
[10:11] <Akiva-Thinkpad> davmor2, oh? Do tell :P
[10:15] <davmor2> Akiva-Thinkpad: I'm QA it's what I do :)
[10:16] <Akiva-Thinkpad>  davmor2 any idea when the phone's gonna come out?
[10:17] <davmor2> Akiva-Thinkpad: No
[10:17] <Akiva-Thinkpad> davmor2, Shucks
[10:23] <sturmflut-work> Akiva-Thinkpad: The Meizu MX4 is scheduled for september 20, but I don't know if it will come with Ubuntu from the start.
[10:35] <Akiva-Thinkpad> sturmflut-work, yah i heard about that. Ive never used a large phone like that before
[10:35] <Akiva-Thinkpad> have you?
[10:44] <jppiiroinen> o/
[10:45] <E524> hi all, yesterday i asked a question and got now answert. i am new to irc and hope it was not because i oversteped some rules. i post it again in the hope somebody would answer it. thx in advance
[10:45] <E524> Hi everyone! A question: it seems it has been a bit silent around the feature that you can use a full desktop version of ubuntu with a dockingstation. is this a soon to come reality or was that just a plan?
[10:48] <ogra_> E524, to dock an ubuntu phone that then turns into a desktop, you actually first need an ubuntu phone ;)
[10:49] <E524> hehe, yes, but it's soon comming and i am saving money for it. if that docking fuction is also comming, i suppose there will be dockinstations too
[10:50] <E524> so was that a yes?
[10:52] <davmor2> E524: We need the ubuntu desktop to be on unity8 too so it most likely won't be on this phone, but will be in the future, as I understand it.
[10:53] <ogra_> E524, well, the first iteration will just be a phone ... once thats out the team will have time to work on integrating a dektop/dock mode
[10:53] <sturmflut-work> Akiva-Thinkpad: I used a Nexus 5, the MX4 is only slightly larger. It is quite nice to have such a large display.
[10:53] <ogra_> and what davmor2 said too ...
[10:54] <ogra_> it will only work if both UIs use the same code
[10:54] <E524> ah ok thanks for the answers! so i will go with the bq model first i guess and have then still something to be looking for :) still great news!
[10:54] <Akiva-Thinkpad> sturmflut-work, interesting...
[10:54] <Akiva-Thinkpad> sturmflut-work, I'm afraid the larger it is, the less durable it is
[10:54] <Akiva-Thinkpad> I'd hate to have a screen cracked.
[10:55] <sturmflut-work> Akiva-Thinkpad: That largely depends on the type of glass. I have never cracked any of my devices.
[10:56] <Akiva-Thinkpad> does it fit well in a pocket?
[10:58] <sturmflut-work> Akiva-Thinkpad: The Nexus 5 did. The additional diagonal inch does not automatically translate into a much bulkier device. Which phone are you used to? The Nexus 4 for example has a 4.7 inch screen and some additional space around the screen, at the end it is nearly exactly as large as the Nexus 5.
[10:59] <sturmflut-work> Screen size alone doesn't mean much, you have to look at the actual size of the device.
[10:59] <Akiva-Thinkpad> sturmflut-work, the last phone I had was the htc dream
[11:00] <Akiva-Thinkpad> sturmflut-work, sort of ironic considering that I am developing phone apps. I am really looking forward to the touch.
[11:01] <sturmflut-work> The HTC Dream is 117.7 x 55.7 x 17.1 mm in size. The MX4 is rumored to be 144 x 75.2 x 8.9 mm. I think the reduction in thickness alone makes the MX4 less bulky than the HTC Dream. You might miss the physical keyboard though.
[11:03] <sturmflut-work> Akiva-Thinkpad:
[11:04] <Akiva-Thinkpad> sturmflut-work, well its the ubuntu touch; don't think I'll miss it much
[11:05] <Akiva-Thinkpad> i was so non-impressed with android, didn't feel like touching it again.
[11:32] <ogra_> sergiusens, hmm, do we store persistent properties anywhere in the emulator ?
[11:34] <sergiusens> ogra_: afaik all props are set throuh the init script
[11:34] <ogra_> aha
[11:34] <ogra_> that might be the adbd issue then
[11:35] <ogra_> god ... thats time consuming
[11:36]  * ogra_ guesses his next laptop will have a touchscreen just for the emulator :P
[11:38] <E524> i have a phone with physical keyboard (xperia pro) and really hope there will be one with ubuntu in the future. working with ssh is so much more conveniet!
[11:38] <tbr> ogra_: skip the emulator, run it native then!
[11:39] <ogra_> haha
[11:39] <ogra_> tbr, i need to fix a bug that only shows in emulator :P
[11:39] <tbr> excuses, excuses ;)
[11:51] <ogra_> hmpf, so stuffing the property in build.prop doesnt help :/
[11:59] <cjwatson> dobey: so, I've analysed bug 1342858 some more, and I think I have most of a fix for it, but it doesn't cover the situation that you raised in a comment there after all.  Sorry for the inadvertent misdirection.  Would you mind filing a fresh bug?
[12:15] <ogra_> sergiusens, i'm lost, where do i find that init script
[12:16] <ogra_> (and why cant i mount the image files ... i thought they are plain qemu qcow images)
[12:17] <sergiusens> ogra_: need to create with --use-raw-disk
[12:17] <ogra_> gah
[12:18] <ogra_> ok
[12:18] <sergiusens> ogra_: the scripts are under devices/generic
[12:18] <ogra_> cool, thanks
[12:20] <popey> Saviq: do we have a unity8 bug for being unable to launch apps after they're updated?
[12:21] <mvo_> would anyone mind if I upload a new ubuntu-touch metapackage with updated deps for the ubuntu-sdk-libs-dev ?
[12:21] <Saviq> popey, right, I was meaning to look for one / file one
[12:21] <Saviq> popey, it's actually not a u8 bug but a unity-scope-click one
[12:21] <Saviq> popey, please file with them
[12:21] <popey> k
[12:28] <ogra_> grmblfjx
[12:28] <ogra_> now system-settings doesnt start :(
[12:30] <ogra_> sergiusens, do you have any clue waht /system/bin/qemud is ? it seems that replaces adbd (or at least manages it) in the emulator
[12:30] <sergiusens> ogra_: it's the bridge to your host
[12:31] <ogra_> ah
[12:31] <sergiusens> ogra_: such as the egl bridge
[12:31] <ogra_> so the equivalent to the kernel gadget
[12:31] <ogra_> man this is awful
[12:32] <sergiusens> ogra_: https://code-review.phablet.ubuntu.com/gitweb?p=aosp/platform/external/qemu.git;a=blob;f=android/adb-qemud.c;h=9d82251cd18fabfafc22177df06b5ac7dc6e10e4;hb=refs/heads/phablet-4.4.2_r1
[12:33] <sergiusens> ogra_: all emulator things are complicated; took me a lot to get the sdcard stuff working
[12:33] <om26er> screen not turning off during call - - which package controls that ?
[12:39] <ogra_> ha !
[12:39] <ogra_> now that was to easy
[12:39] <om26er> !changelog
[13:00] <thc2cat> Hi anyone. Can someone help me with a NFS issue ( Ubuntu 14.04.1 LTS) ?
[13:02] <thc2cat> ,usrquota, is not understood by mount ( mount.nfs: an incorrect mount option was specified error )
[13:08] <dobey> cjwatson: sure
[13:08] <popey> thc2cat: you probably want to /join #ubuntu    which is the support channel
[13:09] <dholbach> if I want to back up my Ubuntu phone - which parts should I adb pull over? /home/phablet and /var/lib - anything else?
[13:10] <popey> dholbach: what you expecting to be in /var/lib?
[13:10] <dholbach> popey, I think I remember sergiusens mentioning it the last time I asked :-)
[13:10] <dholbach> maybe stuff like previously used networks?
[13:11] <dholbach> I was sort of hoping somebody would say "oh, we have ubuntu-device-backup for that now" :-P
[13:11] <sergiusens> dholbach: popey you want to tar preserve perms /userdata/[user-data|system-data]
[13:12] <popey> dholbach: "oh, we have ubuntu-device-backup for that now"
[13:12] <dholbach> <3
[13:13] <dholbach> thanks sergiusens
[13:24] <derek-g> are we there yet? Ubuntu phone release date anyone?
[13:29] <davmor2> derek-g: some time in the next billion minutes
[13:30] <derek-g> davmor2, that's about 1,901 years
[13:30] <popey> He's right!
[13:31] <davmor2> popey: you say that like you are surprised I'm right ;)
[13:32] <popey> I meant derek-g was right, I'd never say you were.
[13:32] <davmor2> popey: phew
[13:32] <derek-g> Launch date is still this year - right? RIGHT?
[13:33] <davmor2> popey: I was also right it will be released with in that time though :P
[13:36] <derek-g> I just hope I can get it by christmas time.
[13:45] <nerochiaro> bfiller: regarding bug https://bugs.launchpad.net/gallery-app/+bug/1366820, the share does not work because it has never been implemented for selections. i started implementing it, but right now it occurred to me that maybe it would be better to just remove the share option when a selection is available
[13:45] <nerochiaro> bfiller: btw it's also broken from events tab
[13:46] <bfiller> nerochiaro: we should try to support that
[13:47] <bfiller> nerochiaro: seeing we can share a single photo doesn't seem like it should be too hard to support single or multiple from the selection view
[13:47] <nerochiaro> bfiller: ok, i'll keep working on it then. it's not hard, except for the fact that the hub doesn't support mixed type shares, so when videos and photos are in the same selection we need to disable the option
[13:48] <bfiller> nerochiaro: yup ok
[13:50] <nerochiaro> bfiller: do you know who's responsible for qtubuntu camera backend ? i ended up using Florian's suggestion in the end (I'll explain why on the standup) to fix bug https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1234130 but I'll need someone to review it
[13:50] <bfiller> nerochiaro: jhodapp can help review it
[13:51] <jhodapp> nerochiaro, yes, I can review it for you...just assign me to any MR
[13:51] <nerochiaro> jhodapp: done
[13:51] <nerochiaro> thanks
[13:52] <jhodapp> nerochiaro, cool...I'll get to it a bit later today if you're not in a huge hurry...I have some other MRs to look at first
[13:52] <nerochiaro> jhodapp: no rush at all
[13:52] <jhodapp> nerochiaro, cool thanks
[14:03] <ogra_> sergiusens, hmm, u-d-f doesnt halt anymore if i'm not in the bootloader with --bootstrap ... it downloads and then hangs silently until i reboot into bootloader ... no message
[14:04] <ogra_> hmm
[14:04] <ogra_> s/doesnt halt/doesnt notify
[14:04] <sergiusens> ogra_: ah, if you pass --device it doesn't halt
[14:05] <ogra_> sergiusens, oh, i didnt know that
[14:05]  * ogra_ only ever passed device in recovery before :) 
[14:06] <ogra_> (whithout --bootstrap)
[14:06] <ogra_> slangasek, FYI i got around using pam_exec (or any other pam hook)
[14:09] <zyga> nik90: hey
[14:10] <nik90> zyga: hey
[14:10] <zyga> nik90: how's your plainbox stuff going on
[14:11] <nik90> zyga: I created my demo example provider and then started reading through the demo example to see how I can split up my jobs and whitelist
[14:12] <nik90> zyga: I should be able to push it to a branch in a few hours
[14:13] <nik90> zyga: when do you EOD? I can try to have something to show you by that time
[14:15] <zyga> nik90: late, I'm working on cool features
[14:15] <zyga> nik90: ping me any itme
[14:15] <zyga> time
[14:15] <nik90> cool, will do
[14:18] <rickspencer3> ogra_, what channel would you suggest for my Nexus 7?
[14:19] <nik90> rsalveti: hey, I talked to the designer yesterday and they strongly feel that calls, alarms must always (also) be played in the speaker phone regardless of whether a headphone is connected to the phone.
[14:19] <ogra_> rickspencer3, well, we check flo on neither channel ... the test results for rtm look not worse than mako http://ci.ubuntu.com/smokeng/utopic/touch_stable/ ... so probably that one
[14:20] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/ doesnt really have enough info with failing devices etc
[14:20] <rickspencer3> thanks ogra
[14:20] <ogra_> (the latter is devel-proposed)
[14:20] <rickspencer3> yeah, I figured
[14:20] <nik90> rsalveti: we are tracking that request at bug 1364647
[14:24] <rickspencer3> barry, when you ran QtCreator, could you not cancel out of the wizard?
[14:26] <barry> rickspencer3: didn't see a cancel button
[14:28] <beuno> rickspencer3, I just for the same
[14:28] <beuno> I cancel, it warns me I'll die if I do
[14:28] <beuno> I accept
[14:28] <beuno> nada.
[14:28] <beuno> *I just had the same
[14:29] <rickspencer3> awesome
[14:29] <rickspencer3> barry, are you coming tonight?
[14:30] <barry> rickspencer3: yep, planning to!
[14:30] <rickspencer3> cool!
[14:31] <barry> rickspencer3: i might bring my son, if he's homework clear and doesn't mind being bored by a bunch of geek talk ;)
[14:33] <rickspencer3> hehe
[15:04]  * cjwatson wonders why the dual-boot app on android isn't seeing any ubuntu-touch/devel-proposed updates beyond 226
[15:06] <slangasek> ogra_: ah?  How did you get around pam?
[15:08] <ogra_> slangasek, adb is poretty tricky since it has two disconnect parts ... (gadget driver and adbd) and the world ends if they go out of sync ... so i have an upstart job that watches the gadget property anyway, this also already checks the PW lenght on boot ... i just had to add a simple upstart-file watch for the shadow file ... works awesome :)
[15:08] <ogra_> *pretty tricky
[15:08] <rsalveti> niemeyer: ok, cool, will take a look at that later this week then
[15:08] <rsalveti> niemeyer: sorry
[15:09] <rsalveti> nik90: ^
[15:09] <ogra_> slangasek, i'll outline all that (and why i did it like that) in the document ...
[15:09] <nik90> rsalveti: cool
[15:12] <slangasek> ogra_: ok
[15:13] <ogra_> it is effectively the same ... just without involving pam
[15:26] <jgdx> seb128, hey, I'm looking at bug 1364366 – it strikes me as odd. Everything is in order, but the icons aren't showing. In fact, without changing any code except using "fallbackIconName" instead of "iconName" shows the icons.
[15:26] <jgdx> seb128, any idea?
[15:29] <sturmflut-work> Does anybody know what the plans for ARM64/ARMv8 support are? 64 bit CPUs will become mainstream shortly, will there just be a new type of kit in Qt Creator (e.g. "UbuntuSDK_for_arm64_GCC_ubuntu_sdk_14_10_utopic") and everything is fine?
[15:29] <ogra_> sturmflut-work, ubuntu has an arm64 distro since about a year
[15:30] <ogra_> but i doubt anyone will target arm64 in the SDK before we even have any devices running ubuntu touch on an arm64
[15:31] <dobey> ogra_: also, all the packages in the ubuntu-touch images aren't necessarily built on arm64 yet. lots of things aren't yet, unfortunately
[15:32] <sturmflut-work> ogra_: I know. My question is if the SDK has to be changed in a major way to support ARM64, or if it is flexible enough already.
[15:32] <ogra_> dobey, yeah, who cares :)
[15:32] <ogra_> sturmflut-work, the SDK is just a UI for various tools ... i think all the tools it uses should already be able to do arm64
[15:33] <ogra_> so its most likely some config adjustments you will need to do once that becomes an issue
[15:34] <jgdx> seb128, figured it out.
[15:35] <sturmflut-work> We looked into ARM64 server hardware a short time ago. Sadly it is still too expensive, otherwise I could have tested Ubuntu ARM64 on a real machine instead of just inside the emulator.
[15:36]  * ogra_ doesnt expect any ubuntu touch arm64 devices within the next year at least 
[15:36] <ogra_> so nothing i would bother with just yet
[15:38] <kenvandine> barry, does this make sense to you ?
[15:38] <kenvandine> http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/plugins/system-update/system_update.cpp#L209
[15:38] <dobey> ogra_: you're not porting to the iPhone 6? :P
[15:39] <ogra_> dobey, send me one
[15:39] <kenvandine> barry, you can see that is what we do on UpdateAvailableStatus from s-i-d
[15:39] <kenvandine> barry, it's calling downloadUpdate if the state is downloading
[15:40] <kenvandine> barry, i suspect that's what's triggering the multiple downloads
[15:40] <kenvandine> barry, but... i'm also not sure if we want the inverse of that
[15:40] <kenvandine> if s-i-d doesn't show it as downloading, we don't want to just tell it to start downloading
[15:41] <kenvandine> barry, we'd want to check the setting right?  or does s-i-d do that for us?
[15:41] <Chipaca> barry: ping
[15:41] <barry> Chipaca: hey, can you hold on for a sec? ;)
[15:41] <kenvandine> uh oh... barry is getting flooded :)
[15:41] <Chipaca> hah, DOSing barry
[15:41] <kenvandine> Chipaca, we can fight for him :)
[15:41] <barry> ENOEGO
[15:42] <Chipaca> kenvandine: no fair! I'm tired out after hauling two 9yo kids back from school
[15:42] <kenvandine> :-p
[15:42] <kenvandine> Chipaca, on your back? or in the back seat?
[15:42] <kenvandine> if the later, i'd say you're out of shape :)
[15:42] <Chipaca> kenvandine: one on my back, both of them on the bus
[15:42] <Chipaca> anyway. in answer to barry's first, serious question: sure, i can wait
[15:43] <Chipaca> i'll go make myself more tea and grab some ginger biscuits
[15:43] <Chipaca> mmm
[15:43]  * Chipaca goes
[15:43] <barry> kenvandine: yeah, you don't want to be calling DownloadUpdate if it's already downloading.
[15:43] <kenvandine> barry, so i think we could either just drop that or we need to do a check for the setting and then call downloadUpdate
[15:44] <barry> kenvandine: if you see the downloading flag is true, then that means it will automatically download and you don't need to do so explicitly.  if downloading is false, you need to explicitly initiate the download
[15:44] <kenvandine> barry, but we should check the autodownload setting right?
[15:44] <sturmflut-work> dobey: There also already is at least one 64 bit Android phone in the market, the HTC Desire 510. Amusingly it does come with a 32 Bit version of Android. Android will not have 64 bit support until Android L is released.
[15:44] <Chipaca> barry: question while you're there, if it's on 3g but set to auto-download on wifi, will downloading be true?
[15:45]  * barry still thiking about kenvandine's q
[15:45]  * Chipaca really goes for tea
[15:45] <barry> Chipaca: if we're wifi-only, we pass that flag straight to ubuntu-download-manager and expect it to dtrt
[15:45] <kenvandine> if (!downloading && (m_downloadMode == 0))
[15:46] <barry> e.g. udm.allowGSMDownload(allow_gsm)
[15:47] <barry> kenvandine: i think the idea was that if auto-downloads are *not* enabled, it would only download on explicit action by the user
[15:48] <kenvandine> barry, right, so i need to check that before i call downloadUpdate
[15:48] <kenvandine> except where they click the button
[15:48] <kenvandine> which is handled elsewhere
[15:49] <barry> kenvandine: i don't totally understand this code though.
[15:49] <kenvandine> barry, but also, would isAvailable mean it has already been downloaded?
[15:50] <barry> kenvandine: not necessarily. it just means the device is behind revs on the server
[15:50] <cjwatson> ondra: I can't figure out why humpolec isn't showing me versions of ubuntu-touch/devel-proposed newer than 226.  The last useful thing in "adb logcat" output is "D/UbuntuInstallService( 5144):  onHandleIntent>>: CHECK_IF_UPDATE_AVAILABLE".  How do I go about tracking this down further?
[15:50]  * Chipaca dunks his ginger biscuits in the tea and reads the backlog
[15:50] <kenvandine> barry, ok, so when i get UpdateAvailableStatus, there is no way to know if it is already downloaded?
[15:51] <jgdx> mpt, hey, you have to remember to re-assign that background bug you stole from me :p
[15:51] <jgdx> (when you're done)
[15:51] <mpt> jgdx, I haven’t forgotten, it’s Critical
[15:51] <barry> kenvandine: correct.  you need to watch for the UpdateDownloaded signal, which always tells you the download is done (or UpdateFailed for error cases)
[15:51] <Chipaca> jgdx: mpt: now now, no squabbling over the bugs, i'm sure there are enough for both of you
[15:52] <ondra> cjwatson that is known, it's because there is no delta from from version you are on ( at least I saw this in other channel)
[15:52] <pindonga> jdstrand, hi there... was wondering about click-reviewers-tools and the way it triggers checks for manual review
[15:52] <kenvandine> barry, ok, so when i have this signal i just need to call downloadUpdate if it isn't currently downloading and assume s-i-d will not crash :)
[15:52] <cjwatson> ondra: Ah, do I have to just uninstall and reinstall then?
[15:52] <pindonga> jdstrand, so far I was hooking on (MANUAL_REVIEW) being part of the check text
[15:52] <jdstrand> pindonga: in the sdk?
[15:52] <pindonga> jdstrand, are there more hooks like this? or a better way to track checks requiring manual review? maybe we can expand the return json
[15:52] <ondra> cjwatson so dualboot won't see new verson, but reboot to Ubuntu and run updater there
[15:52] <pindonga> to avoid depending on a string?
[15:53] <cjwatson> ondra: Oh, does that work now?
[15:53] <kenvandine> barry, i'd expect if i call downloadUpdate on a download that has already downloaded, s-i-d would just emit the updateDownloaded signal right?
[15:53] <pindonga> jdstrand, this is for the checks run in the store
[15:53] <ondra> cjwatson you can download update with Ubuntu upgrader then reboot to Android and dualboot will pick that downloaded update
[15:53] <barry> kenvandine: correct. :)  but i'm having a difficult time reproducing this bug locally because 1) the crash happens *after* the UpdateDownloaded signal is sent so there's no change in client behavior; 2) in my test suite the si-dbus process does not seem to exit, even though logging proves that the lock release fails.  so i'm not sure how the crash reporter is registering the crash and traceback!
[15:53] <cjwatson> ondra: ah, brilliant, thanks
[15:53] <jgdx> Chipaca, I've got bugs in my room/ears/pocket/shoes. Do I kill them? Become their friend?
[15:53] <ondra> cjwatson that was wortking since last release in june or when I did it
[15:53] <pindonga> jdstrand, we run the click-reviewers-tools checks on uploaded pkgs, and need a way to mark pkgs that need manual review
[15:54] <barry> kenvandine: correct, and it does!  it's just that on the device it also crashes after the signal is sent ;)
[15:54] <jdstrand> pindonga: so, there are three types of output-- error, warn and info. manual review happens in error, but there are other errors in there
[15:54] <pindonga> right
[15:54] <kenvandine> barry,  so the crash happens if the download is already in /android/cache/recovery
[15:54] <kenvandine> i can reproduce that reliably
[15:54] <jdstrand> pindonga: so, you want to somehow display something different if there is only manual reviews and if there are errors?
[15:54] <pindonga> jdstrand, so, my understanding was that erros requiring manual review were marked as (MANUAL_REVIEW)
[15:55] <pindonga> jdstrand, however I now see there is another case (EMAIL NEEDS HUMAN REVIEW)
[15:55] <kenvandine> and it happens before i get the updateDownloaded signal
[15:55] <pindonga> was wondering if there is a list of such tags
[15:55] <kenvandine> barry, it crashes very quickly...
[15:55] <barry> kenvandine: the crash happens if a DownloadUpdate is called without a matching CheckForUpdate.  i can reproduce reliably on my device too, i just can't see the process exit for some reason
[15:55] <pindonga> or if we can maybe expand the error structure to include a 'manual_review': True in the json
[15:55] <pindonga> instead of relying on these tags
[15:55] <kenvandine> barry, ok
[15:55] <jdstrand> I think that makes sense
[15:55] <barry> kenvandine: that makes sense.  the validity check for the already downloaded files should be quick-ish.  just checks some gpg sigs.  if all that looks okay, it should send the UD signal rather quickly
[15:55] <jdstrand> the manual review tag
[15:56] <kenvandine> yeah, but i never get the signal
[15:56] <pindonga> jdstrand, will work on an mp for that then
[15:56] <kenvandine> it just crashes while i wait for it
[15:56] <Chipaca> jgdx: I can't comment on what you choose to do in the privacy of your home
[15:56] <jdstrand> pindonga: cool, thanks!
[15:57] <barry> kenvandine: okay, that part doesn't make sense ;)  unless something about the device environment would cause the process to crash before dbus has a chance to put the signal on the wire.  and that environment is different than the test suite
[15:57] <kenvandine> barry, ok, it'll take some time to get a build of this to test on the device, but this should fix some nasty conditions caused by system-settings at least
[15:57] <jgdx> Chipaca, lol.. your comment reminded me of Pearl Jam – Bugs. A fitting song in these bug squashing days.
[15:58] <barry> kenvandine: cool.  i'm going to keep thinking about this.  i think i need to know more about how the crash reporter is hooked into all this
[15:58] <barry> Chipaca: so what's up?
[15:59] <Chipaca> barry: hiya. the other day a mock/testing system image service was mentioned, something about --testing=potato. There's an in-passing reference on https://wiki.ubuntu.com/ImageBasedUpgrades/Client but .. dunno more
[16:00] <Chipaca> jgdx: heh, i hadn't heard this. Nice.
[16:00] <Chipaca> barry: like, what is --testing an option of?
[16:01] <barry> Chipaca: it's an option of /usr/bin/system-image-dbus but only if the system-image-dev package is installed, which it generally isn't on devices
[16:01] <Chipaca> barry: but it needs running as root?
[16:02] <jgdx> later all
[16:02] <barry> Chipaca: not necessarily.  e.g. the s-i test suite runs all this stuff on private system buses
[16:02] <barry> as $USER
[16:02] <Chipaca> barry: i need to run this stuff for testing the settings push helper
[16:02] <barry> Chipaca: it's possible, but not currently *easy* to do the same outside the s-i test suite
[16:02] <Chipaca> augh
[16:03] <barry> Chipaca: you might want to talk to kenvandine or other system-settings folks, because i'm pretty sure they run it with --testing in their test suites (at least, that's why i added it :)
[16:03] <Chipaca> so i might be better off mocking the bits i want to use myself
[16:03] <Chipaca> ah
[16:03] <Chipaca> kenvandine: well hello there :D
[16:03] <barry> Chipaca: the trick is to start a private system bus via dbus-launch and then connect to that
[16:04] <kenvandine> Chipaca, off hand, i have no clue how we test that :)
[16:04] <kenvandine> i just recently looked at the update code for the first time
[16:04] <barry> Chipaca: all the si test suite horribleness is here: http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client/view/head:/systemimage/testing/controller.py
[16:05]  * barry thinks you don't actually need an ubuntu-download-manager process for --testing
[16:05] <Chipaca> yowza
[16:05] <barry> Chipaca: welcome to the beauty that is dbus :)
[16:06] <barry> and i'm sure it will all be easier when systemd subsumes dbus

[16:06] <barry> Chipaca: the real goodness is here: http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client/view/head:/systemimage/testing/controller.py#L197
[16:07] <barry> that's what fires up dbus-daemon and sets the envar for the private system bus
[16:07] <barry> Chipaca: but be aware, once you set $DBUS_SYSTEM_BUS_ADDRESS and initialize libdbus, you cannot change that value in process, which is why the si test suite goes to great lengths to only terminate the child processes, never dbus-daemon itself
[16:08] <barry> Chipaca: because if dbus-daemon exited, the foreground test process could never reset the private system bus address and it would be beyond its event horizon ;)
[16:08]  * barry is getting an idea for a pycon 2015 talk ;)
[16:09] <Chipaca> barry: out of academic curiosity, is reload (imp.reload) smart enough to make that work again?
[16:10] <barry> Chipaca: no because it's a libdbus problem, nothing to do with python, so i think once libdbus is dynamically loaded, it gets initialized once and for all in the process's address space.  i don't *think* reload() will cause libdbus shlib to reinitialize, though i'm not certain about that
[16:11] <barry> it would be a fun experiment
[16:14] <barry> kenvandine, Chipaca i'm getting some lunch.  bbs
[16:22] <kenvandine> seb128, can you do review?  renatu has a packaging change that will add a NEW binary
[16:22] <kenvandine> https://code.launchpad.net/~renatofilho/ubuntu/utopic/ttf-ancient-fonts/fix-1269017/+merge/234013
[16:22] <kenvandine> seb128, i looked it over and made some fixes already, which he merged
[16:38] <sturmflut-work> Does anybody know if 802.1x (WPA2 Enterprise) wifi authentication will be supported at launch date?
[16:40] <mterry> ogra_, you mentioned some bug with adb and having to change udev permission order -- what's the bug # for that?
[16:41] <ogra_> mterry, that got immediately fixed i dont have a bug for it
[16:42] <mterry> ogra_, oh hrm.  I'm having troubles adb'ing into a nexus 10 that appears to have developer mode enabled
[16:42] <mterry> ogra_, any other reports of tha?
[16:42] <mterry> *that
[16:44] <ogra_> mterry, i was just looking into that and see it without even having the developer mode stuff installed ... in fact i dont even see anything in dmesg from USB on my PC after the device is running
[16:45] <ogra_> i think this is not dev mode related
[16:45] <mterry> ogra_, oh so nexus 10 just isn't accessible for other peeps too?  seems bad  :-/
[16:45] <ogra_> we had to make some adjustments in the upstart job for supporting krillin ... i assime it is related to that
[16:45] <ogra_> mterry, it is a bug ... and i will fix it
[16:46] <mterry> ogra_, ah but I can ssh in...
[16:46] <ogra_> (its just not as high on my prio list as krillin or mako are thogh)
[16:46] <ogra_> mterry, yes, if your key is on the device :)
[16:46] <ogra_> people that did a fresh flash are a bit screwed
[16:48] <ogra_> if you ssh in, you will see that adbd is running fine and that it is also properly set in the android properties ...
[16:48] <ogra_> there is something low level broken
[16:49] <mterry> ogra_, haha!  I'm in
[16:50] <ogra_> :)
[16:57] <mterry> ogra_, whoa..  ssh is super slow for me
[16:57] <mterry> like long delays in even typing
[17:12] <ogra_> mterry, same for me in the terminal app when typing locally
[17:28] <barry> pitti: any chance you're still around?
[17:28] <seb128> kenvandine, sure
[17:29] <seb128> jgdx, still blocked on that icon thing?
[17:43] <arun12> hi guys, is it possible to try ubuntu phone in samsung s2 ?
[17:43] <dobey> !devices | arun12
[17:44] <arun12> dobey: can I get a manual to install it too >
[17:45] <dobey> that page has all the info, or further links to it
[17:46] <dobey> hrmm
[17:46]  * dobey wonders how to set up a system-image server
[17:55] <nerochiaro> zbenjamin: do you know where the click-review is executed when i tell qtc to run a click on the device ? dpkg-deb -R fails for lack of space but as far as I can see both my phone and my desktop have space
[18:10] <zbenjamin> nerochiaro: click-review is executed locally, check if your tmp folder has space
[18:18] <dobey> nerochiaro: the click is built in a chroot, and click-review is run inside it. maybe your /var or something is running a bit low on available space?
[18:19] <balloons> zyga, you about?
[18:24] <nerochiaro> dobey: zbenjamin: it was actually low space on / , sorry for the noise. i hadn't realized that all this stuff was done in / and could not be moved elsewhere
[18:26] <nerochiaro> dobey: zbenjamin: but i notice something that i don't like: click review creates in /tmp a ton of clickreview directories and each one is 25MB and they are never deleted. I have 3.6Gb of them after a day of work
[18:26] <dobey> nerochiaro: eh? it's not in / for me
[18:26] <nerochiaro> dobey: /tmp is in / :)
[18:27] <nerochiaro> dobey: on the same partition, in a normal ubuntu installation I mean
[18:27] <dobey> yes, but my /tmp isn't full of clickreview directories...
[18:27] <dobey> and i've built the same click package like 30 times over the past few days
[18:30] <dobey> oh well
[18:30] <dobey> nerochiaro: if it's creating lots of tmp directories and not deleting them, i'd consider that a bug.
[18:30] <nerochiaro> dobey: me too
[18:44] <elopio> Saviq: tedg, balloons, bzoltan, ubuntu-qa: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1367871
[18:44] <elopio> please leave your comment on that bug if it affects you some way ^
[18:45] <ToyKeeper> elopio: If my guess is right, wouldn't that prevent the media scopes from being able to launch media?
[18:45] <ToyKeeper> (would run the app but the app wouldn't know what to do)
[18:45] <elopio> cjwatson: it may interest you too ^
[18:45] <elopio> ToyKeeper: I don't think so. I guess media is launched with url-dispatcher
[18:46] <elopio> and you can pass arguments to the receiving app. That's how you store a phone on the address book from the dialer.
[18:52] <tedg> ToyKeeper, We support passing of URLs not command line arguments.
[18:53] <ToyKeeper> Hmm.  I obviously haven't looked into the implementation, but still, it's a unix system.  Eating argv is rude.
[18:53] <tedg> ToyKeeper, We're not eating it at all.
[18:54] <tedg> ToyKeeper, We using the desktop file to build it, and using that.
[18:54] <tedg> ToyKeeper, So the desktop file can have as many parameters as you want, and your app will get those.
[18:55] <ToyKeeper> tedg: What about giving it a '--' option, which will send everything after directly to the app?
[18:56] <tedg> ToyKeeper, How would those be inserted into the exec line in the desktop file? Before or after the "--" that it has in there already?
[18:57] <tedg> UAL isn't a "binary runner" it's an application launcher.
[18:57] <tedg> Applications are defined by desktop files.
[18:57] <tedg> (and other things)
[18:59] <brendand> ToyKeeper, we tracked down the media scopes issue
[19:00] <ToyKeeper> tedg: The desktop file could perhaps have a '$*' on its Exec line which specifies where to put extra args.
[19:01] <tedg> ToyKeeper, It could, but that's not currently in the desktop file spec. And $ isn't a special character there, nor *.
[19:01] <sergiusens> I had the same problem elopio is having here a while back; but I agree with tedg on this one; testing parameters should be stubbed in a different way
[19:01] <sergiusens> envvars perhaps
[19:04] <ToyKeeper> tedg: Or %* or whatever fits the syntax best.
[19:04] <tedg> For instance QtCreator will build click packages with probes included for gdb/etc.
[19:04] <elopio> sergiusens: please comment on the bug.
[19:04] <tedg> There it's modifying the desktop file in the click and executing that.
[19:04] <tedg> So you can always distinguish what you're running.
[19:08] <sergiusens> tedg: elopio you can always use --desktop-file-hint and run unconfined
[19:09] <tedg> sergiusens, That should hopefully be going away soon :-)
[19:09] <elopio> sergiusens: we are doing more or less that on the reminders case.
[19:09] <sergiusens> I woulnd't want the click's default apparmor rules to be laxed next just for testing
[19:09] <elopio> not with --desktop-file-hing because Saviq said that was a workaround that we need to remove.
[19:09] <elopio> but with our own desktop file prepared on the fly.
[19:09] <sergiusens> tedg: right, so new click (or rebundle) with specific apparmor tuning is the way to go
[19:10] <sergiusens> elopio: right, and apparmor will eventually get in your wa, so think about that too
[19:11] <elopio> sergiusens: we are using aa-exec to launch the app. tedg said we should run it without that, but I don't know how to make it work.
[19:11] <dobey> command line arguments and app confinement just don't go toether
[19:11] <dobey> together
[19:11] <tedg> For the lttng testing we change the default apparmor profile and rebuild them to let the LTTng events through.
[19:11] <elopio> sergiusens: but I'm not sure if I prefer that to env vars.
[19:11] <sergiusens> dobey: +1
[19:12] <dobey> nor do env vars
[19:12] <elopio> dobey: please comment on the bug https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1367871
[19:13] <elopio> everybody seems to be pointing that we shouldn't have that arguments helper on the API.
[19:19] <tedg> elopio, The command line argument utility can be used for the arguments in the desktop file.
[19:19] <tedg> elopio, And we'll have multiple exec lines when we support actions.
[19:20] <tedg> elopio, So those could be the same binary with different arguments, depending on the application author's preference.
[19:21] <elopio> tedg: I find that useful. But then I'm not sure I get why don't make u-a-l a little more intelligent where what changes is only the argument that the app receives.
[19:21] <elopio> if that will cause issues with app armor and the app won't run nicely, that's the fault of the guy calling it that way.
[19:22] <tedg> elopio, Well the actions spec isn't that simple, for instance, with running apps and such. It's based on declarative definitions of the actions, and one of the keys there is the exec line.
[19:22] <zyga> balloons: hey
[19:23] <dobey> elopio: u-a-l can't change what arguments the app receives, because that's not how .desktop files work
[19:23] <elopio> tedg: I understand all your points, and they make sense. I would prefer an easier way to launch apps, but making an alternate desktop file is not that hard.
[19:24] <elopio> now I'm not sure if that desktop should be made on the fly, or it should come from the package.
[19:25] <balloons> zyga, we had quite a conversation earlier about plainbox and ubuntu touch. I'm curious as to what you had in mind. I also have comments about the testcase format. But mostly, I'm wondering if there is plans to automate and collate the results from test runs on the device somewhere
[19:25] <dobey> elopio: for example, if an app is run with qmlscene, how does it know if you're trying to pass an argument to qmlscene itself, or to the app? or to anything else in the Exec line? the way it works is things like "%u" get replaced with their appropriate values, or dropped, and then the command is executed
[19:25] <dobey> elopio: i think changing the .desktop file is a hack solution to a much larger problem, and not the way to go either
[19:26] <elopio> dobey: I understand that. Our initial assumption was that it will just append the arguments at the end on the exec, but now looking how it works with aa-exec, appending at the end won't make sense in many cases.
[19:26] <elopio> dobey: what's that larger problem?
[19:26] <zyga> balloons: ok
[19:27] <dobey> i think the way actions are done in .desktop files is totally wrong too. one shouldn't need to add special command line args to be implementing actions in an app
[19:27] <zyga> balloons: so, we're working hard on getting plainbox to work on ubuntu touch with a UI, all the UI bits are done, we're working on integrating them into a whole application
[19:27] <dobey> elopio: testing is hard, and all the tools aren't there yet
[19:28] <zyga> balloons: we're expand that to get to a point where we can generate a click package with any set of supported tests, some meta-data (name, constraints, etc) and generate a custom testing application
[19:28] <zyga> balloons: on top of that nik90 is working on a set of plainbox-compatible manual tests for the clock application
[19:28] <elopio> dobey: well, you are right :) But in order to make testing easier, one of the steps is to be able to launch the apps in different modes. So we might as well start there.
[19:28] <balloons> zyga, yes nik90's mp proposal kicked off the discussion :-)
[19:28] <zyga> balloons: I'd like to see where we could take all your current manual test cases, conver them over to plainbox format, then write a small tool that loads those plainbox-formatted tests and recreates your current format
[19:28] <elopio> dobey: if you have a better suggestion of where to start, that will be useful too.
[19:28] <zyga> balloons: so that you can keep using all your current stuff while we build the missing pieces
[19:29] <zyga> balloons: there's also a different effort to build a test provider (test) store (similar to the charm store)
[19:29] <dobey> elopio: no. apps having "different modes" for testing is wrong. app behavior shouldn't change (some aspects of communication with external things should change perhaps, but the app itself shouldn't behave differently)
[19:29] <zyga> balloons: and an early effort to be able to *run* tests online, form a browser
[19:29] <zyga> balloons: all in all, I'd like to know what can help your team the most to consider transitioning over
[19:30] <balloons> zyga, I think we should have a talk about the possibilities. I have some questions and thoughts. I know we started hashing on this in the ml thread a few weeks ago, but never talked further. I think this might work well for ubuntu touch stuff, and we could then carry that over to the desktop manual tests
[19:30] <zyga> balloons: yeah, I think we need to get started and iterate
[19:30] <elopio> dobey: the modes we are discussing so far are things like using a server that's not production, and defining the geometry of the app.
[19:30] <dobey> elopio: well, mir doesn't have Xnest or xvfb; but if you can run the autopilot tests with those instead of mir, you can test the app at different screen sizes easily enough, but will lose confinement aspects in that test run
[19:30] <zyga> balloons: the touch app will bring a lot of momentum with it
[19:30] <balloons> zyga, if you plan to have a clearing house for test results, than I am interestedindeed
[19:30] <zyga> balloons: right now it's a bit early but what nik90 is doing is helping a lot
[19:30] <zyga> balloons: what do you mean by clearing house?
[19:31] <elopio> dobey: and at some point, we might want to change the security mode also. But I agree with you there, the app shouldn't change, we should just set up the environment with those different modes.
[19:31] <dobey> elopio: right. unfortunately apparmor is not particularly great, but i'd say it should be the way that what server the app is talking to, gets redirected
[19:31] <balloons> zyga, I mean, when I run tests on the device via an plainbox app. It will prevent with me something to do, then I can tap passed or not, yes? That information on those test runs needs to go somewhere. Ideally to the dashboard, where it is collated and viewable
[19:32] <dobey> elopio: right. the app should be confined and nothing in it should change. what should change is stuff in the confined environment
[19:32] <balloons> if we don't have this, the tools looses so much value
[19:32] <elopio> dobey: I need to check with xvfb. With my xephyr attempts, it didn't matter the size of the framebuffer, the app started always with a portrait mode.
[19:32] <zyga> balloons: (as for what the touch app will do, yes, I think so though I don't know what you mean by 'prevent' there)
[19:32] <stgraber> cwayne: I don't suppose you can easily rev a custom image (no change rebuild kind of thing)?
[19:32] <dobey> elopio: changing gemoetry is at least easy
[19:33] <zyga> balloons: we can process and handle results anyway you like, if there's a documented way on how to send data to the dashboard I can code that for you in a few hours
[19:33] <dobey> elopio: at least, it's easy with X11. i don't think mir has any tools to do that yet (but i am not 100% sure as i haven't really done much with mir itself yt)
[19:33] <dobey> yet
[19:33] <balloons> zyga, sorry.. horrible typing. "present". I will be presented with a test, and it will collect my responses of pass and fail. right now this is json that stays on the device right?
[19:33] <zyga> balloons: currently we support two sinks: launchpad and the certification site
[19:33] <zyga> balloons: ah :)
[19:33] <zyga> balloons: yes
[19:33] <stgraber> cwayne: I just updated system-image to use hash-based filenames and I'd like to confirm this all works as expected (currently I've confirmed that the backward compat works and that the hash works in the testsuite but I'd like to see it work in prod too)
[19:33] <zyga> balloons: https://docs.google.com/a/canonical.com/document/d/12gpgFGtNBoPet8215bUdeJ-QXLL_peQOsGCzipd4gh0/edit#
[19:33] <zyga> balloons: you will get exactly that
[19:33] <elopio> dobey: well, a virtualframebuffer for mir is a long standing testability bug.
[19:33] <elopio> I don't know about starting real mir with a predefined geometry.
[19:33] <elopio> that's one important thing to try.
[19:34] <zyga> balloons: right now is is stored in an internal format, the idea is that concrete apps we can generate will tell us what to do (out of a list of supported options), sending stuff to the dashboard can be one of those options you can pick while making the app
[19:34] <elopio> dobey: but well, that leaves the sandbox or fake server case. Do you think it's not ok to make an alternate desktop file for that case?
[19:34] <balloons> zyga, right. I feel like for manual testing to take hold, it needs to live and be displayed in the same place as the automated results. Perhaps others won't agree, but :-)
[19:35] <zyga> balloons: well, I agree :)
[19:35] <zyga> balloons: we're the frontend
[19:35] <zyga> balloons: and the core logic
[19:35] <dobey> elopio: i think alternate .desktop file is the wrong way to do that, yes
[19:35] <zyga> balloons: we're not the central result store
[19:35] <zyga> balloons: but I can easily support sending data to one more place in one more format
[19:35] <zyga> balloons: as that's a central part of plainbox today
[19:35] <balloons> zyga, so I do like the UI concept and the overall thought process behind it on touch devices
[19:35] <elopio> dobey: env vars then? or do you have something else in mind?
[19:36] <dobey> elopio: what does "sandbox" even mean?
[19:36] <balloons> zyga, yes totally fair. I think CI then needs to become a part of it. Have you spoken with anyone in CI?
[19:36] <zyga> balloons: one thing that is not presented there in that document (that's for +1) is also a way to have custom QML tests
[19:36] <elopio> dobey: the evernote sandbox server it's like what we call staging.
[19:36] <zyga> balloons: so you can have a non-standard test "page" where everything is specialized (e.g. live feedback from sensors)
[19:36] <balloons> zyga, this could plug in very nicely I think with the whole silo process.. But you'll need buy in from everyone.
[19:36] <zyga> balloons: nope, but I'd love to
[19:36] <zyga> balloons: I don't know who to talk to
[19:37] <dobey> elopio: oh. usually when i see "sandbox" and "apps" in the same sentence, it's about confinement, not testing servers :)
[19:37] <elopio> dobey: the problem in general it's just to use a server that's not the production one. We will like to run tests on staging and on other kinds of tests servers, like a fake that has just hardcoded replies.
[19:37] <zyga> balloons: I agree, I'm really willing to do as much as I can to help everyone get on the same boat with the format and UI
[19:37] <dobey> elopio: apparmor/iptables :)
[19:37] <zyga> balloons: including supporting things that we traditionally didn't need in certification
[19:37] <balloons> zyga, I can help with opening a conversation thread
[19:37] <zyga> balloons: I would be grateful for that
[19:37] <dobey> elopio: so you redirect the network requests in the system network layer, and not in the app
[19:37] <elopio> dobey: oh, like redirecting a domain name to an ip we control?
[19:38] <zyga> balloons: I'll be in VA (hopefully) so if all the involved parties are also expected to be there we could have a bigger conversation in real life
[19:38] <elopio> I haven't thought of that before because that sounds way more complicated than using a variable. But I'll explore what would be needed for that.
[19:38] <zyga> balloons: though I'd like to start talking sooner
[19:38] <dobey> elopio: something like that, but a bit more complex, yes
[19:38] <zyga> balloons: we have one more thing
[19:38] <balloons> zyga, excellent, I'll be there as well, and yes we can ensure a session on this. Manual testing is already a hot topic
[19:38] <zyga> balloons: remote testing (either a sever or a touch device) from some host running normal ubuntu
[19:39] <zyga> balloons: so you can have partially assisted tests where you get something started and still mainly interact with your laptop while tests are rolling on the device
[19:39] <zyga> balloons: plus, our goal is to build a solid cert programme
[19:39] <zyga> balloons: so we need to work together not to duplicate the effort
[19:40] <zyga> balloons: and that makes it even more natural to lend everyone a hand so that our job is easier later :)
[19:40] <balloons> zyga, so have you seen this? https://wiki.ubuntu.com/QATeam/TestCase. Would it be possible to have expected results for each step in your testcases?
[19:40] <zyga> nope
[19:40] <zyga> looking
[19:40] <dobey> elopio: it is more complicated, but it's the right way to do things. we're just used to hacking in command line args and tweaking env vars, because we're used to building unconfined apps in an insecure environment, and those things are really easy to do
[19:40] <zyga> awesome
[19:40] <balloons> zyga, right, I know you have a different endgoal in mind for this ofc
[19:40] <zyga> balloons: yes
[19:40] <zyga> balloons: I think this fits our format very well
[19:40] <elopio> dobey: also we need to take into account that evernote needs to use the online accounts sandbox plugin in order to use the sandbox. It's not just changing the ip.
[19:41] <elopio> but I think I'm starging to agree with tedg here. If it uses the sandbox plugin, it's a different app.
[19:41] <dobey> elopio: problem is that we can't just change dns, because sometimes the url path needs to be changed as well, and other things
[19:41] <zyga> balloons: we also have a notion of chaining tests, so you could have say, three tests where each encodes Nth action and expected result for that action
[19:41] <balloons> zyga, so if you can support that format, I think that's the largest hurdle for using the current tests. I don't like the breakdown in the app
[19:41] <zyga> balloons: depending on the intent
[19:41] <zyga> balloons: it could be better (you can e.g. abort early if Ith step fails and not go to I+1)
[19:42] <zyga> balloons: ok, I'd love to see some realistic tests so that I can conver them over manually, show you how that looks like and see what we need to improve to make you happy
[19:42] <balloons> zyga, I'm also curious to see how much easier it's gotten to plug in arbitrary tests.. I've not tried for a long time. the plainbox changes look like this is sane now
[19:42] <zyga> balloons: and let's do this every week so that we can iterate (meet/plan/talk)
[19:42] <dobey> elopio: i think that's another problem with online-accounts and the way plug-ins work there. (separate issue, but makes things harder for testing)
[19:42] <zyga> balloons: oh its super easy
[19:42] <zyga> balloons: it's been designed from that from ground up
[19:42] <zyga> balloons: it's nothing like the old checkbox
[19:42] <balloons> zyga, right, I'm looking at https://code.launchpad.net/~nik90/ubuntu-clock-app/checkbox-manual-tests/+merge/234164
[19:43] <zyga> balloons: looking
[19:43] <dobey> elopio: the oauth based plug-ins are very static. the URLs can't be changed or anything like that
[19:43] <elopio> dobey: also, an interesting point is that even while the app is confined, the test runner is not. So we are not constrained while preparing the test bed during set up, but once we launched the app we should respect the confinement constraints.
[19:43] <dobey> elopio: exactly
[19:44] <balloons> zyga, so the changes I would make to those tests would be in the _description field. I would have the steps have a verification step for each one. The final verification could still be 'special' if needed I guess
[19:44] <dobey> elopio: confinement/isolation are very good things for testing, but we are way lacking in tooling to do things right
[19:44] <dobey> (well, everyone is lacking in tooling to do things right, not just us)
[19:44] <balloons> zyga, otherwise I'm familar with the format and understand it.. Did you know we used checkbox at one point for manual tests?
[19:44] <zyga> balloons: nope, I didn't know that
[19:45] <zyga> balloons: what kind of UI would you like for that kind of tests
[19:45] <zyga> balloons: where each action / verification is separate?
[19:45] <zyga> balloons: note that description is totally free form, you don't need the PURPOSE or STEPS or VERIFICATION
[19:45] <zyga> balloons: it's totally devoid of meaning, we just display it
[19:45] <balloons> zyga, oh really? free form now?
[19:45] <balloons> wow
[19:46] <balloons> wow owow
[19:46] <zyga> balloons: yes
[19:46] <zyga> balloons: :)
[19:46] <zyga> balloons: plainbox is also very extensible
[19:46] <elopio> dobey: I would like to present a list of testability things we are missing during the sprint. I'll send an email to the mailing list after RTM to collect more things we might have missed.
[19:46] <zyga> balloons: so we can simply add new stuff you may need
[19:46] <dobey> elopio: i'm sure we won't have that tooling before the sprint either, so maybe it would be a good thing to get some discussion on there with qa/security/etc
[19:46] <zyga> balloons: and it won't be required
[19:46] <zyga> balloons: or won't break anything
[19:46] <zyga> balloons: it's very flexible
[19:46] <dobey> heh :)
[19:46] <elopio> what we would like is to stop doing workarounds for those missing features. And instead start investing on the right solution.
[19:47] <zyga> balloons: so
[19:47] <dobey> exactly
[19:47] <zyga> balloons: let's start with one thing
[19:47] <dobey> and tweaking .desktop files and env vars is workarounds
[19:47] <balloons> zyga, sure. so for the manual tests now (non-phone stuff), here's an example of what it looks like: http://iso.qa.ubuntu.com/qatracker/milestones/315/builds/78516/testcases/1301/results
[19:47] <balloons> look inside the testcase grey box.
[19:48] <balloons> you see bold text, italics text (verification step)
[19:48] <balloons> aka, do something, expect something
[19:48] <elopio> dobey: I still have the feeling that we will need arguments or vars for something. But so far from our discussion I can't think of anything, so I agree.
[19:48] <zyga> balloons: "Proceed in your native language if you wish. Instructions will remain in English"
[19:48] <zyga> balloons: you can translate our test providers and the whole app + tests will be 100% localized
[19:48] <balloons> yes translations would be cool ofc
[19:49] <zyga> balloons: oh, one quick idea, we could support simple formatting like that (bold, italics, etc)
[19:49] <balloons> zyga, but you see the same basic elements are there. A summary / purpose description, then each step listed out
[19:49] <zyga> balloons: so how can we submit results back to where they are useful for you?
[19:49] <zyga> balloons: our summary is only used in listings where you don't want to show the long description
[19:49] <balloons> zyga, the tracker itself has  a python api. you could easily do that
[19:50] <zyga> balloons: do you have any links to documentation on that API?
[19:50] <balloons> zyga, well I didn't mean to sidetrack us too much, as I'd rather focus on the phone stuff. I think that will be easier to nail and more imperative
[19:50] <balloons> I was just pointing out that's the format ;-)
[19:50] <zyga> balloons: ok
[19:51] <zyga> balloons: so what would you like to see next week?
[19:51] <zyga> balloons: 1) some real existing tests working, apart from those that nik90 is working on
[19:51] <zyga> balloons: 2) support for a test result format you want
[19:51] <zyga> balloons: 3) ???
[19:52] <balloons> zyga, well it sounds like you are saying #2 is done. If so, I will push back on nik90 to do his MP in that format. That solves that riddle for me. The next step then would be to complete the experience. So get the tests and app all loaded, figure out the tech and have it working
[19:53] <zyga> balloons: *result*, not test description format
[19:53] <zyga> balloons: ok, so I'll focus on supporting nik90
[19:53] <balloons> the final piece of the puzzle is pushing the results somewhere useful. So in tandem, I'll open a thread with CI about where to put the results
[19:54] <balloons> zyga, ahh yes.. the result format is variable.. It depends on what we can get buy-in from everyone on.
[19:54] <zyga> balloons: ok
[19:54] <zyga> balloons: so we can support ... all the formats
[19:54] <balloons> zyga, I don't forsee it as a real problem. The problem is having a system to display it and people use it.. making it fit within the workflow that is being built
[19:55] <balloons> zyga, from your end, sounds like all the technical work is solved
[19:55] <balloons> which is great to hear
[19:55] <zyga> balloons: we're doing our best :)
[19:55] <zyga> balloons: it took a while to dust the project and get something fresh out
[19:55] <zyga> balloons: but I think we're ready to help others
[19:56] <zyga> balloons: ok, let's start the CI thread and see what we can achieve
[19:56] <balloons> elopio, dobey, et la, leave your comments / intentions in the bug, lest we all forget.. Don't make me paste the IRC log :-)
[19:57] <balloons> zyga, right. I'll have a closer look at his mp and try it out. It might be next week before I can quick things off though
[19:57] <dobey> balloons: i'd need more specific examples of what needs to be tweaked for testing, bot provide further useful commentary beyond what i alread posted there :)
[20:15] <pindonga> jdstrand, the mp I mentioned earlier... what do you think? https://code.launchpad.net/~ricardokirkner/click-reviewers-tools/manual-review-flag/+merge/234204
[20:26] <dobey> anyone know how to have online-accounts working again under x11? seems the trusted prompt sessions stuff in it sort of made it impossible to add an account when running it under X :(
[20:27] <jdstrand> pindonga: responded in the mp. thanks!
[20:47] <pindonga> jdstrand, updated and pushed
[20:50] <jdstrand> pindonga: thanks! merged
[20:50] <pindonga> cool, thx
[20:50] <pindonga> will update the server to look for this now
[20:57] <mkottre> What is the current state of ubuntu touch on the 2012 Nexus 7. I'm aware that official support ended in January but was curious if their is a community supported version yet.
[20:58] <dobey> mkottre: if there is, i wouldn't expect it to work any better than ubuntu did when we stopped supporting it directly
[20:59] <mkottre> dobey: ok. Thank you.
[20:59] <dobey> mkottre: it's a different set of hardware than what all the other nexus devices we support are
[20:59] <mhall119> ^^ what dobey said, the hardware just wasn't up to the task
[20:59] <mkottre> thanks
[20:59] <mhall119> IIRC, we spent more time fighting to make drivers behave than getting things done
[20:59] <dobey> it's a tegra iirc, and i don't think mir works very well on that
[20:59] <mkottre> yes it is
[21:00] <dobey> which reminds me
[21:00] <dobey> i wish someone would buy my 2012 nexus 7 :(
[21:01] <mhall119> it turns out it's not even a really great Android tablet
[21:01] <Tassadar> well it was) just didn
[21:01] <Tassadar> didn't age very well
[21:03] <dobey> mhall119: well, imo, there is no such thing as a great android tablet
[21:03] <popey> +1
[21:04] <dobey> i tried to actually use android once, on my n5, and i couldn't even make it through a day with it
[21:05] <mkottre> that's the same way I feel
[21:05] <Tassadar> well it is obviously a very subjective matter)
[21:05] <dobey> i'm sure it's great if you've sold your soul to google, but if you want to maintain personal control over the data on your phone, it's absolutely unusable
[21:05] <nerochiaro> kenvandine: still around ? do you know if there's a way for apps to advertise if they can handle single or multiple selections as share target ?
[21:06] <dobey> anyway
[21:07] <mhall119> nerochiaro: I think the ContentTransfer.selectionType will tell your app which mode to use
[21:07] <dobey> Tassadar: are you aware of any current build issues with hammerhead? latest image doesn't seem to be inline with what's available on mako
[21:07] <Tassadar> Oo
[21:08] <Tassadar> rtm or devel-proposed?
[21:08] <dobey> devel-proposed
[21:08] <nerochiaro> mhall119: yes, but if my app wants to share some content which consists of multiple items, I would like to have the picker only propose the apps that can handle multiple media. right now, both apps it propose me can't do that
[21:08] <Tassadar> like, the image is bad or the versions numbers don't match?
[21:09] <dobey> Tassadar: version numbers don't match. i've got 232 on my n5, and no updates available, and its 235 on mako
[21:09] <mhall119> nerochiaro: ah, I understand now
[21:09] <Tassadar> wtf, mako has 235 but flo only has 232
[21:09] <mhall119> nerochiaro: I don't know of a way to do that, sorry
[21:09] <nerochiaro> mhall119: ok, thanks anyway
[21:09] <dobey> Tassadar: oh
[21:10] <Tassadar> dobey: my server is tracking flo's versions, not sure why mako has more images Oo
[21:10] <dobey> Tassadar: ah ok, i guess flo is behind for some reason
[21:10] <Tassadar> maybe the build is failing on ubuntu servers?
[21:10] <dobey> could be
[21:10] <Tassadar> I can switch it to mako if you wanna
[21:10] <dobey> i don't know where to look or who to ping about that
[21:10] <Tassadar> I bet ogra_ knows)
[21:11] <dobey> probably, but i also expect him to not be around at this hour
[21:11] <Tassadar> oh, yeah, it is pretty late already
[21:11] <dobey> yeah, wasn't expecting you to be around either :)
[21:12] <Tassadar> I'm extremely bad with keeping my sleep schedule when I don't have to wake up early every morning :/
[21:13] <Tassadar> dobey: do you want me to switch to mako so it builds new image or is it fine? I suppose flo builds will resume shortly and this is just some temporary problem though
[21:15] <dobey> Tassadar: mako is probably the better thing to track in general
[21:15] <Tassadar> okay
[21:22] <Wellark> ok. something broke qtcreator
[21:22] <Wellark> it can't find compiler anymore
[21:22] <Wellark> Mirv: !!!
[21:25] <balloons> zyga, one other thing.. can I see the current touch application now?
[21:32] <Tassadar> dobey: there are some shenanigans happening, mako version 235 == flo version 232
[21:32] <Tassadar> maybe mako needed some extra images to fix some device-specfic thing?
[21:32] <Tassadar> anyway, I'll leave it to track mako, so next image will be 236
[21:33] <Tassadar> (it won't generate 235 because the files are already there)
[21:33] <dobey> huh
[21:33] <dobey> ok
[21:33] <dobey> evil shenanigans
[21:34] <Tassadar> hopefuly skipping versions like that won't break anything
[21:35] <Tassadar> rtm images on flo are 3 versions behind mako too
[21:35] <Tassadar> weird