[00:35] <harris> on the status page why are there still two broken features for the nexus 7
[00:37] <harris> on the status page why are there still two broken features for the nexus 7
[01:35] <cwayne> mardy: i don't suppose you're still around?
[01:37] <tinix> has anyone here tried running ubuntu-touch on a chromebook pixel?
[01:57] <OrokuSaki> well.. I got mer with hybris working.. interesting... my surface test fails... Hmmm Still waiting for video hardware decoding and ubuntu touch.. =)
[01:57] <OrokuSaki> test_glesv2 works
[01:57] <OrokuSaki> I think I know why the test failed..
[03:11] <OrokuSaki> @harris... broken would assume that it was working at one time..
[04:09] <o_be_one> hi all
[04:09] <o_be_one> ubuntu touch is in final release right ?
[04:21] <bjv> am I envoking this QtQuick application incorrectly?
[04:22] <bjv> marked image r/w, rebooted and installed python3-pyqt5.qtquick and downloaded the example pyqmldemo.py and pyqmldemo.qml mentioned in https://lists.launchpad.net/ubuntu-phone/msg04281.html
[04:23] <bjv> created an ~phablet/.local/share/applications/pyqml.desktop per https://lists.launchpad.net/ubuntu-phone/msg04491.html
[04:24] <bjv> added execute permissions to /home/phablet/pyqmldemo.py
[04:24] <bjv> but when running $ ./pyqmldemo.py --desktop_file_hint=pyqml      from either adb shell, or from the Touch terminal app
[04:24] <bjv> i am presented with only a blank grey screen, i can minimize, and re-focus the app through Unity shell
[04:24] <bjv> but no components are visible
[04:25] <bjv> (this is image 11 on maguro)
[04:26] <bjv> I suspect i am not envoking the QtQuick application correctly, because I can swipe away swipe the left launcher
[04:27] <bjv> tap the .desktop icon to bring up the grey QtQuick canvas, or return to the home screen and click the thumbnail to bring up the same
[04:27] <bjv> but if i swipe to another running task
[04:27] <bjv> i am *not* able to right-swipe and rotate through
[04:28] <bjv> QtQuick app is only focusable via 2 of the 3 unity shell multitasking mechanisms
[04:28] <bjv> *and doesnt seem to actually be running/painting any components
[07:28] <abigdreamer> hi
[07:29] <abigdreamer> trying to get touch to run on nexus7 with jdk8 -- its working
[07:29] <abigdreamer> jkd8 and javafx is not working yet.
[08:11] <holymac> why doesn't android touch come pre installed in my phone?
[08:17] <nhaines> holymac: can you be more specific?
[08:17] <popey> holymac: what is android touch?
[08:17] <holymac> I meant android touch
[08:18] <holymac> ahhh... i meant ubuntu touch
[08:18] <holymac> sorry, i am kind of tipsy.
[08:18] <popey> bed is -> that way
[08:19] <holymac> It is <-- way
[09:54] <aquarius> cjwatson, ping about fat click packages. Specifically, I have a binary QML plugin. I can happily create folders named for an architecture triplet, and put the appropriate compiled binary plugin into each triplet folder, and I can make my startup script actually be a script rather than just "qmlscene whatever.qml". What I don't know is how I find my architecture: I can run dpkg-architecture -qDEB_HOST_MULTIARCH but is
[09:54] <aquarius>  a click package allowed to do that? Does the click stuff provide any help here, or is working out my architecture at runtime and loading appropriate architecture-specific stuff something I need to do by hand?
[09:57] <cjwatson> aquarius: That was one of the things I was dropping heavy hints about at the Canonical planning sprint last week :-)
[09:58] <aquarius> heh :)
[09:58] <cjwatson> aquarius: We need some kind of dispatcher, ideally centralised
[09:58] <cjwatson> dpkg-architecture is in dpkg-dev, so isn't the ideal base
[09:59] <cjwatson> I think we need a common dispatcher somewhere that's Architecture: any, built with knowledge of the correct multiarch triplet, and sets up some appropriate LD_LIBRARY_PATHs or whatever; but that has to go with some conventions for actually laying out the package
[09:59] <cjwatson> So I attempted to punt that to the SDK guys; dunno if I succeeded
[09:59] <aquarius> cjwatson, yeah. In theory I can do all the work myself in my startup script, but it would be much much nicer if it somehow all worked by magic... so I provide in my click package a folder named "architecture-specific-stuff" and then "architecture-specific-stuff/arm-linux-gnueabihf" and "architecture-specific-stuff/x86_64-linux-gnu" and the app runner magically makes sure that the arch folder is on the ld_library_path
[09:59] <aquarius>  and the qml_import_path and etc.
[10:00] <aquarius> we seem to have arrived at the same place, which is good
[10:00] <aquarius> just to confirm: this is just a good idea at this point rather than anything that works, yes?
[10:06] <cjwatson> aquarius: Right.  If I get my way it will be s/architecture-specific-stuff/lib/g
[10:07] <aquarius> well, I concede that my name is not actually a good one :) Not too sure about "lib", since lots of QML stuff seems to use that, but whatever the name is, not worried.
[10:07] <cjwatson> QML stuff isn't going to use lib/<triplet> surely
[10:08] <cjwatson> Now, if it weren't an insufficiently-caffeinated morning I might be able to remember how to get the multiarch triplet without dpkg-dev
[10:08] <aquarius> pure QML stuff isn't, indeed -- but it may be weird to have a "lib" folder which the QML bit of your app puts a bunch of QML in *and* which contains arch-specific folders
[10:09] <cjwatson> I dunno, seems no less weird than /usr/lib/ having both random package-specific helper directories and libraries
[10:09] <cjwatson> seems precisely cognate in fact :)
[10:09] <aquarius> a reasonable point, although I'm not sure that "/usr/lib? wild wild west! do whatever you want" is the ideal role model ;-)
[10:10] <aquarius> I suspect we might want lib/x86_64-linux-gnu/so and lib/x86_64-linux-gnu/qt or something, and the dispatcher puts lib/x86_64-linux-gnu/so on LD_LIBRARY_PATH and lib/x86_64-linux-gnu/qt on QML2_IMPORT_PATH or something.
[10:10] <aquarius> (handwaving the actual names)
[10:10]  * popey pictures aquarius handwaving
[10:10] <cjwatson> oh, I see, you're talking about overlap between random other libraries and QML .sos
[10:10] <aquarius> ah, not quite
[10:12] <aquarius> three things here: random libraries, QML plugins, and importable QML library scripts (such as a useful JavaScript thing which many people import into a project). People writing QML stuff who import scripts quite often stick them in a folder called lib/. But I think you're right: the package can use the lib folder for whatever it wants, and *in addition* there are specially named subfolders which the dispatcher puts
[10:12] <aquarius> on various paths
[10:13] <aquarius> and that way we can support different "types" of binary thingies. So lib/x86_64-linux-gnu/bin would contain executables and the dispatcher would put it on $PATH if it exists. That sorta thing.
[10:13] <cjwatson> I think I'd prefer bin/<triplet>, but yeah, whatever
[10:13] <cjwatson> https://wiki.debian.org/Multiarch/Tuples gives two existing interfaces for getting the multiarch triplet: dpkg-architecture -qDEB_HOST_MULTIARCH and gcc -print-multiarch.  Neither is on the default touch image AFAICS from a quick look at seeded-in-ubuntu
[10:14] <cjwatson> Still, I'm inclined to maintain that the triplet is the right thing to use by analogy with existing library directories, and we should make it workable :)
[10:23] <lool> cjwatson: getting triplet without dpkg-dev >> wasn't this direct parsing of e.g. /usr/share/dpkg/archtable?
[10:27] <cjwatson> lool: EWW
[10:28] <cjwatson> No, definitely not
[10:43] <pk__> i dont have an ubuntu computer ..cant i flash my phone with a windows laptop?
[10:57] <marinellafor> Hello guys, how can i add ringtones on ubuntu touch? have you a solution?
[10:59] <ogra_> iirc cjwatson and jdstrand were talking about hooks for click packages that could copy wallpapers or sounds in place so you could package them
[10:59] <davmor2> Morning all
[10:59] <ogra_> not sure where that stands or how hard it would be to implement yourself
[11:00] <pk__> which image should i download for samsung galaxy note 2?
[11:00] <ogra_> !devices| pk__
[11:00] <ogra_> pk__, see the link on that wikipage, it should point to an xda thread
[11:00] <pk__> okay
[11:15] <lool> cjwatson: then I cant find how this was done either; it does ring a bell, but I didnt find what provided this
[11:15] <lool> maybe it was some libc thing instead
[11:29] <JamesTait> Good morning all; happy Guy Fawkes Day! :-D
[11:29] <ogra_> remember remember ...
[11:29] <ogra_> :)
[11:32] <marinellafor> there?
[11:32] <marinellafor> how can i add ringtones on ubuntu touch? have you a solution?
[11:34] <kalikiana> as I just wasted time on trying to do "touch /userdata/writable_image" which was mistyped into a pastebin… is there any chance of getting a command line that can fail if it's wrong?
[11:34] <kalikiana> it's not fun to work with silent failures
[11:37] <ogra_> marsee what i wrote above
[11:37] <ogra_> marinellafor, ^^^
[11:38] <marinellafor> uogra
[11:38] <marinellafor> ogra
[12:02] <sil2100> oSoMoN: ping!
[12:43] <timppa> Hi, I just installed touch (trusty-devel), it stopped to: ROM may flash stock recovery on boot. Fix? THIS CANNOT BE UNDONE.
[12:43] <timppa> should I enter yes or no to that?
[12:43] <timppa> Device = grouper
[12:45] <timppa> At the bottom of the screen it says: Ubuntu update complete.
[12:46] <timppa> Options are No and Yes - Disable recovery flash
[12:46] <timppa> I don't want to brick the device
[12:53] <timppa> took my changes :)
[12:53] <timppa> It's working now
[12:56] <eraserhd> How does one remove a click package?
[12:56] <eraserhd> shell command is ok.
[12:56] <eraserhd> (It's not showing up in the UI)
[12:56] <davmor2> eraserhd: press and hold the app then select uninstall
[12:57] <eraserhd> davmor2: Unfortunately, I'm trying to reinstall because the first click package I made didn't give me an icon.
[12:58] <davmor2> eraserhd: ah no idea then sorry, I'm assuming click --help might point you in the right direction though
[12:58] <popey> adb shell
[12:58] <popey> sudo -u phablet -i
[12:58] <popey> click list
[12:58] <popey> then find the package you want to remove
[12:58] <eraserhd> davmor2: OK, weird.  It worked the second time I tried to reinstall over top (or at least didn't error out this time).
[12:58] <popey> sudo click --unreigster appname verno
[12:59] <eraserhd> popey: Oh, thanks.
[12:59] <eraserhd> popey: Does 'click install' imply 'click register'?
[13:00] <ogra_> timppa, for the future: you cant brick nexus devices with any of the ubuntu tools :)  (you would have to screw around with the bootloader itself, which we dont touch at all)
[13:01] <popey> eraserhd: not if the package isn't installed
[13:01] <popey> eraserhd: you need to install the package, then register it to a user
[13:03] <eraserhd> popey: Is this the usual way to try a phone app when developing?:  adb push *.click /tmp/; adb shell click install /tmp/*.click; adb shell click register <something> <something>; ?
[13:04] <cjwatson> that's not a correct way to install a package
[13:04] <cjwatson> popey: (I wouldn't recommend the "install, then register" language, it just confuses people)
[13:04] <cjwatson> use   pkcon install-local foo.click
[13:04] <popey> does that actually work now?
[13:04] <cjwatson> has for ages
[13:05] <popey> hm
[13:05] <cjwatson> it's the recommended CLI method
[13:05]  * ogra_ uses it all the time 
[13:05] <popey> ok. thanks
[13:05] <popey> eraserhd: ^
[13:05] <popey> cjwatson: as root?
[13:05] <ogra_> no
[13:05] <ogra_> as phablet
[13:06] <cjwatson> What he said
[13:06] <ogra_> i wiish we had a similar easy way to uninstall though ...
[13:06] <cjwatson> The only problem I'm aware of with pkcon install-local on the phone is bug 1245677
[13:07] <cjwatson> ogra_: It can be done through pkcon too, but the interface is annoying, I'll grant
[13:07] <ogra_> yeah, i usually do it as root with unregister --user=phablet ...
[13:07] <timppa> I was a bit disappointed that grouper did not have the tablet version of touch, should it have?
[13:07] <popey> timppa: no
[13:08] <popey> timppa: aiui the screen isn't wide (tall) enough
[13:08] <cjwatson> popey: If you must use the low-level click interface for some reason, then "click install --user=phablet foo.click" - no reason to expose the install/register separation to people
[13:08] <davmor2> cjwatson: and what about removal is there a similar pkcon for that?  Or is click --unregister the correct way?
[13:08] <timppa> popey: why?
[13:08] <timppa> ok
[13:08] <ogra_> the sidestage needs some space
[13:08] <cjwatson> davmor2: https://lists.launchpad.net/ubuntu-appstore-developers/msg00553.html
[13:08] <popey> thanks cjwatson
[13:08]  * popey updates his scripts
[13:09] <cjwatson> davmor2: i.e. pkcon remove 'com.ubuntu.test;1.3;all;local:click'   to translate that last bullet point
[13:09] <eraserhd> So if I do sudo -u phablet pkcon install-local /tmp/*.click, I still don't see the icon on the home screen.
[13:10] <cjwatson> I suspect that's the click scope not refreshing properly
[13:10] <davmor2> cjwatson: thanks it was only if the question came up again the correct advice could be given :)
[13:10] <cjwatson> you might find that a session restart (simplest: reboot) shows the icon
[13:10] <ogra_> eraserhd, do a search
[13:10] <ogra_> eraserhd, that forces a refresh of the click lens
[13:17] <eraserhd> ogra_: er, well rebooting the phone worked
[13:18] <ogra_> eraserhd, well, i dont like to wait minutes to test my change to an app :)
[13:18] <ogra_> i usually use the search
[13:20] <eraserhd> Yay!  My Starbucks app works!
[13:20] <ogra_> cool
[13:21] <popey> \o/
[13:21] <eraserhd> Is there a non-gui way to build the click installer?
[13:21] <ogra_> popey, btw, i shold have a usable qml wrapper for webapps ready by the weekend ... (already have a back button working, just need to read into url-dispatcher fro opening external links)
[13:21] <eraserhd> (It's time to automate some steps.)
[13:22] <popey> oh nice
[13:23] <popey> eraserhd: click build ./appfolder
[13:25] <eraserhd> popey: When I build through the GUI, I get 45K package.  When I use click build, I get a 27K package.
[13:25] <sergiusens> ogra_, why that and not the webbrowser --webapp method?
[13:25] <popey> eraserhd: I'd unpack each and look at the difference, then maybe file a bug against the sdk
[13:25] <ogra_> it rpobably adds the project files if you use the UI
[13:26] <ogra_> sergiusens, because you cant set a UA string without having it added to the system wide override file
[13:26] <eraserhd> I figured out that click packages are .debs, but I don't remember that toolchain 'cause I haven't used it in ages.
[13:27] <ogra_> sergiusens, i have  a bug open for this against webbrowser-app (to add a cmdline option) but want to use certain apps before that appears
[13:27] <ogra_> and it is a nice fingertraining too ;)
[13:27] <ogra_> getting warm with QML and all
[13:35] <eraserhd> Where does the app title come from?  It doesn't seem to be picked up from the manifest.
[13:36] <beuno> eraserhd, it is specified in the web ui on upload
[13:37] <eraserhd> beuno: So there's no way to specify for pkcon?
[13:37] <beuno> eraserhd, well, the .desktop file has a field for this as well
[13:37] <beuno> not sure pkcon would be able to read that
[13:38] <beuno> cjwatson may know
[13:44] <cjwatson> pkcon doesn't care what the app title is
[13:44] <cjwatson> But indeed I suspect you just need a suitable .desktop file
[13:51] <jdstrand> cjwatson: I see you assigned yourself to bug #1245677
[13:51] <jdstrand> cjwatson: is there more needed for that?
[13:53] <jdstrand> cjwatson: I ask because I was writing ci testing for click-apparmor and was going to upload it once that was in place
[13:53] <jdstrand> and I plan to have that in place today
[13:58] <cjwatson> jdstrand: I just assigned myself for completeness
[13:58] <cjwatson> Nothing more needed AFAIK
[13:59] <jdstrand> cjwatson: ok. like I said, I'll upload that in a bit
[14:00] <cjwatson> Sure
[14:00] <cjwatson> I only fixed the metadata because I wanted to mention the bug in IRC so I wanted the bot to show it as fix-committed, really :)
[14:01] <jdstrand> :)
[14:01] <jdstrand> cjwatson: np and thanks for the patch :)
[14:18] <eraserhd> Ok, so how do I specify to pkcon the package to remove?
[14:18] <eraserhd> Alternately: are there any road-tested scripts or make targets for installing to a phone?
[14:19] <cjwatson> eraserhd: I mentioned the pkcon remove interface above
[14:19] <cjwatson> 13:09 <cjwatson> davmor2: i.e. pkcon remove 'com.ubuntu.test;1.3;all;local:click'   to translate that last bullet point
[14:20] <cjwatson> (it's not ideal, pkcon has funny ideas about this)
[14:20] <cjwatson> eraserhd: You probably just need to substitute the first and second field there
[14:22] <eraserhd> cjwatson: Ok, thanks.
[14:25] <eraserhd> cjwatson: Would you expect this to work in r100?
[14:26] <ogra_> definitely
[14:26] <lool> xnox: hey
[14:26] <lool> xnox: trying the emulator, it gets a bit confused while generating apparmor profiles
[14:26] <lool> xnox: I've noticed some kernel warnings in dmesg related to this, are these known / did you already pass these to security team?
[14:27] <jjohansen> lool: yep known, I'm looking into it
[14:27] <lool> jjohansen: cool thanks
[14:27] <eraserhd> cjwatson, ogra_: I'm getting: Command failed: This tool could not find the installed package: could not find net.eraserhead.ubuntu-touch.starbucks-app;0.1;all;local;click
[14:28] <eraserhd> 'click list' shows net.eraserhead.ubuntu-touch.starbucks-app       0.1
[14:28] <cjwatson> eraserhd: local:click not local;click
[14:29] <eraserhd> oh
[14:29] <cjwatson> i.e. replace last semicolon with colon
[14:29] <cjwatson> and yes, should work in r100
[14:30] <eraserhd> cjwatson: Thanks, that works.
[14:33] <nik90> I need some help with the nexus 4. When I power it on, it shows the google logo and then after a few seconds reboots to show the battery icon. Doesn't go all the way to the ubuntu welcome screen.
[14:33] <nik90> Do I leave it to charge for few hours before trying again?
[14:34] <ogra_> sounds like you are very low on battery
[14:34] <nik90> ogra_: ah okay .. I thought I messed it up or something
[14:34] <ogra_> well, did you hack your image in rw mode ?
[14:35] <ogra_> then this indeed can be :0
[14:35] <ogra_> :)
[14:35] <ogra_> just revert what you did then *g*
[14:35] <nik90> ogra_: yes I did to test an upstream package MP
[14:35] <nik90> ogra_: I cant adb shell until it boots to ubuntu though to undo it
[14:36] <ogra_> you should have adb access when the google logo is up
[14:36] <ogra_> adbd is started as one of the very first services
[14:36] <nik90> ogra_: yay ubuntu started up
[14:36] <nik90> i see the welcome screen
[14:36] <ogra_> great
[14:36]  * nik90 sighs a relief
[14:36] <ogra_> so it just took long
[14:36] <eraserhd> So I figured out the size thing: .excludes doesn't seem to like wildcards (or the CLI click build doesn't listen to it).
[14:37] <eraserhd> So I'm putting click packages inside click packages.
[14:38] <nik90> ogra_: no the first few times it kept rebooting itself...only now it goes all the way to the ubuntu welcome screen..I guess you were right about the battery
[14:38] <ogra_> well, check the indicator
[14:38] <ogra_> it should tell you
[14:38] <nik90> 1% battery
[14:38] <ogra_> yeah
[14:38] <ogra_> charge it
[14:39] <ogra_> quickly, before it reboots again ;)
[14:39] <nik90> ;)
[14:39] <ogra_> and on a proper wallcharger ...
[14:39] <lool> the number of things firing on first boot is impressive
[14:39] <ogra_> USB ports only provide 500mA ... thats about as much as the device uses when idling
[14:39] <lool> when you check it out with the emulator  :-)
[14:39]  * lool watches gst-plugin-registry and click grind through the initial setup
[14:40] <ogra_> lool, noticing my calendar, we shoulld probably drop that system image meeting :)
[14:40]  * ogra_ doesnt think we need it anymore
[14:40] <lool> oh yeah
[14:41] <lool> doesnt' seem like anyone missed it
[14:41] <ogra_> yeah
[14:41] <ogra_> system-image works pretty reliable nowadays ...
[14:43] <lool> ogra_: there are some things we might want to discuss at vUDS
[14:43] <ogra_> yup
[14:43] <lool> for instance, supporting community ports isn't great right now; perhaps we can do things to allow system-image to work with just the ubuntu bits
[14:43] <lool> there's a saucy SRU underway for download manager
[14:44] <ogra_> lool, we need to generally focus on helping ports more this cycle
[14:44] <ogra_> we kind of left them behind
[14:44] <lool> the question of x86 images, emulator imagees
[14:44] <ogra_> due to everyone working like crazy in the last weeks of the cycle
[14:44] <lool> We could pregenerate emulator images too
[14:44] <ogra_> lool, we need x86 images,. but the issues start on a different level before we can even think about system-image support
[14:45] <lool> wow, emulator actually starts unity8 and maliit
[14:45] <lool> on a black screen though
[14:45] <ogra_> packaging on x86 etc
[14:45] <ogra_> rootfs creatiion ...
[14:45] <ogra_> its all focused on arm and android containers atm
[14:48] <nerochiaro> sergiusens: do you know what's the way to launch a qml app with qmlscene from an adb shell these days ?
[14:49] <sergiusens> nerochiaro, same as usual, with the desktop file hint
[14:49] <nerochiaro> sergiusens: i keep getting "QUbuntu: Could not create application instance" when i do that
[14:49] <xnox> lool: starting or starting and generating crash files in /var/crash/ for both unity8 and maliit?
[14:49] <xnox> =)
[14:50] <nerochiaro> sergiusens: from an image flashed this morning
[14:50] <lool> xnox: yeah generating crash files is what it seems to be mostly doing  :-)
[14:51] <lool> xnox, sergiusens: Do we want to keep the build-emulator-sdcard.sh and run-emulator.sh as shell scripts in the future, or would we want to move them to python, perhaps even in phablet-tools?
[14:51] <lool> asking cause I think it would be nice to avoid too many different places to know about the internals of how filesystems are laid out
[14:54] <xnox> lool: once they actually work, we will be generating images on cdimage / system-image. And one would just fetch the lot with phablet-flash.
[14:54] <xnox> lool: at the moment, it doesn't make sense to invest much time into that, since we still do not have graphical output / unity8 running.
[14:54] <lool> ack
[14:55] <ogra_> yeah
[14:55] <lool> I started with chmod -x /etc/init.d/apparmor and enabled=0 in /etc/default/apport
[14:55] <sergiusens> lool, phablet-tools but encapsulated in the sdk as well
[14:55] <sergiusens> xnox, do you think it's worth trying TLS_REG_EMUL y in the kernel?
[14:57] <lool> xnox, sergiusens: Are you guys debugging the video output issue?  It sounds like you're into a lower level problem with thread local storage, but I guess that might be a result of your debugging into the GL video output?
[14:59] <sergiusens> lool, well my crash on surfaceflinger which has a nice backtrace leads to http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_development.git;a=blob;f=tools/emulator/opengl/system/OpenglSystemCommon/HostConnection.cpp;h=940f5aeab4500381495595fb2a4bfdc66d3cdb27;hb=refs/heads/phablet-trusty#l52
[14:59] <sergiusens> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_development.git;a=blob;f=tools/emulator/opengl/system/OpenglSystemCommon/ThreadInfo.h;h=032873340c654d5d54967ac1212aeca17de346d4;hb=refs/heads/phablet-trusty
[15:01] <lool> sergiusens: Do you have a link to your nice crash?
[15:03] <sergiusens> lool, http://paste.ubuntu.com/6365082/
[15:04] <sergiusens> lool, you might find this useful http://paste.ubuntu.com/6365090/
[15:11] <karni> Can't run unity8 from trunk using ./run_on_device. Known issue guys? http://paste.ubuntu.com/6365123/
[15:12] <lool> sergiusens: thanks
[15:20] <didrocks> bzoltan1: hey, so it seems Mirv couldn't release ubuntu-ui-toolkit, is that work ongoing?
[15:20] <didrocks> bzoltan1: remember we really do need to release it today to not block thomi on AP 1.4 transition :)
[15:20] <lool> Hmm how does one enter the android container now that it's not running adb anymore?
[15:21] <lool> am I supposed to kill the host adbd to get to the android one?
[15:21] <bzoltan1> didrocks: I rememer that i have promised to you not to release anything from Tuesday noon
[15:21] <ogra_> lool, yeah, thats the only safe way ...
[15:21] <didrocks> bzoltan1: yeah, we have 2 releases
[15:21] <didrocks> one with 1.3 (this is today)
[15:22] <didrocks> but for that, we need trunk to be releasable
[15:22] <didrocks> and then, one with AP 1.4 (tomorrow)
[15:22] <lool> ogra_: hmm for some reason that didn't work immediately in the emulator
[15:22] <didrocks> but it seems we are blocked on the first step, right?
[15:22] <lool> perhaps I havent waited long enough
[15:22] <ogra_> lool, you need to drop the snippet from /var/lib/lxc/android/pre-start.d/
[15:22] <ogra_> and reboot
[15:22] <cwayne> mardy: ping
[15:23] <lool> ah right
[15:23] <ogra_> lool, if you dont care about being under the init session you can determine the PID of the container with lxc-info -n android and chroot into /proc/$PID/rootfs
[15:23] <eraserhd> click build won't make a valid package without the '-m', I guess?
[15:24] <didrocks> bzoltan1: ?
[15:24] <ogra_> (that is essentially what android_chroot used to do ... but as i mentioned, wont actually get youo inside the container)
[15:25] <bzoltan1> didrocks: yes,we are blocked .. let me check out the situation
[15:26] <didrocks> bzoltan1: thanks, just keep me posted :)
[15:26] <cwayne> kenvandine: hey, i fixed the fitbit account plugin :D got time for an MR by any chance?
[15:26] <bzoltan1> didrocks:I am a little bit worried that we do not push the fix in the middle of the AP migration
[15:26] <kenvandine> cwayne, sure!
[15:26] <didrocks> sergiusens: you released all click apps (after ensuring they passed autopilot 1.3 tests of course)
[15:26] <kenvandine> cwayne, i am very curious what the fix was
[15:26] <didrocks> bzoltan1: we need to have the fix before
[15:26] <didrocks> bzoltan1: remember my email? all components need to be released first
[15:26] <cwayne> kenvandine: https://code.launchpad.net/~cwayne18/ubuntu/trusty/account-plugin-fitbit/qml-plugins/+merge/193870
[15:27] <cwayne> kenvandine: writing a qml plugin to do another api call to pull the username :)
[15:27] <sergiusens> didrocks, except for sudoku, yes
[15:27] <didrocks> bzoltan1: and I don't want the toolkit being the one blocking even starting the migration :)
[15:27] <sergiusens> didrocks, but that was ages ago
[15:27] <kenvandine> cwayne, that's annoying
[15:27] <sergiusens> didrocks, almost like 2 weeks ago
[15:27] <didrocks> sergiusens: great! what about notes-app btw? I see it's a click and in the archive?
[15:28] <cwayne> kenvandine: very
[15:28] <sergiusens> didrocks, I think bfiller still wanted the apps as deb too for desktop use
[15:28] <didrocks> sergiusens: I'm not sure when we run AP tests here, we test the click one or the new .deb we just installed, do you know?
[15:28] <didrocks> (it's confusing in some words)
[15:29] <sergiusens> didrocks, the infra doesn't support click testing yet; I thought I mentioned that to you yesterday
[15:29] <sil2100> sergiusens: hi!
[15:29] <sergiusens> hey
[15:30] <didrocks> sergiusens: not sure about "the infra", but smoke testing do test them, right?
[15:30] <didrocks> (once released)
[15:30] <lool> the image tests do
[15:30] <lool> but not the ci/autolanding I guess
[15:30] <sil2100> sergiusens: I tested calendar-app and from my side it's good for release, not sure if you already pushed the new version today?
[15:30] <sergiusens> didrocks, yes, smoke image testing yes
[15:30] <didrocks> sergiusens: so, you are running the AP tests manually before releasing, right?
[15:30] <sergiusens> didrocks, yes
[15:30] <didrocks> ok, great, thanks :)
[15:31] <karni> Hey guys, anyone familiar with unity8's ./run_on_device?
[15:31] <sergiusens> sil2100, no I haven't; didrocks where was the pad with the status of transition?
[15:32] <didrocks> sergiusens: http://pad.ubuntu.com/autopilot-1-4
[15:32] <sergiusens> thanks
[15:32] <didrocks> you have the list of all packages
[15:32] <didrocks> I think we need to sort the click vs packages in the archive
[15:32] <didrocks> seems we test/release multiple times (for click and for .debs)
[15:32] <sergiusens> didrocks, I was hoping for that to be sorted during the sprint
[15:32] <didrocks> not even sure if we install the new debs, what we do test it the .debs version or the .click
[15:32] <sergiusens> didrocks, I'll do whatever is required btw
[15:32] <didrocks> sergiusens: wasn't discussed AFAIK
[15:33] <didrocks> sil2100: do you know, once you install, let's say notes-app on device, if we test the .debs notes-app or the click one?
[15:33] <sergiusens> didrocks, today's image in proposed already has autopilot 1.4?
[15:34] <didrocks> sergiusens: no, we do the release *before* 1.4
[15:34] <didrocks> and then tomorrow, we'll have 1.3
[15:34] <didrocks> (if we can release the toolkit today, before)
[15:34] <sergiusens> didrocks, so I need to go into writable image mode to test the clicks? :-/
[15:34] <lool> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/trusty-preinstalled-touch-armhf.manifest has python-autopilot	1.3.1+13.10.20131003.1-0ubuntu2
[15:34] <didrocks> sergiusens: what I want you to test today is without 1.3
[15:35] <didrocks> so no need to go in writable mode
[15:36] <sergiusens> didrocks, I think I'm confused, but I'll reread to understand the objectives here
[15:36] <sil2100> didrocks: no idea, but I was guessing we're testing the one that was installed last
[15:36] <didrocks> sergiusens: easy, we want a snapshot before 1.3 and after 1.4
[15:36] <sil2100> Due to the desktop file being installed from the last install
[15:36] <kenvandine> cwayne, reviewed... needs fixing
[15:36] <didrocks> sil2100: can you check? (I guess cjwatson and popey would be the best to ask about it ;))
[15:36] <kenvandine> cwayne, ping me when you need another, it is minor things
[15:37] <didrocks> sergiusens: today, we try to do the snapshot before moving to 1.4
[15:37] <didrocks> to ensure we have a clean baseline
[15:37] <cjwatson> didrocks: I don't know, sorry
[15:37] <sergiusens> didrocks, ok, and sil2100 you want a calendar app with ap 1.3 tests?
[15:37] <didrocks> maybe lool would know then?
[15:37] <didrocks> sergiusens: exactly, like for all the other click apps that are going to be impacted with that transition
[15:38] <sergiusens> didrocks, nah, I just read sil2100 say it's ready and not sure the 'what' part of the 'ready' he was referring to; I'll just manually inspect the code
[15:39] <didrocks> sergiusens: I guess he installed it and tried AP tests
[15:39] <sil2100> sergiusens: yes, I meant it is ready since I ran the 1.3 AP tests on it and I didn't see any regressions
[15:39] <lool> didrocks: the question is whether we test .deb or .click?
[15:40] <didrocks> right
[15:40] <didrocks> how to know?
[15:40] <sil2100> There were failures, yes, but nothing regressing, as they were from the new parts - dogfooding showed things working as before
[15:40] <lool> didrocks: you should be calling into the specific test script and that should do the right thing
[15:40] <lool> didrocks: IIUC, the image tests are manually switched over from .deb to click
[15:40] <lool> didrocks: and they should all be up to date since we dont include the debs which are clicks
[15:41] <karni> It is the right channel to ask unity8 related questions, isn't it?
[15:41]  * karni double checking
[15:41] <lool> didrocks: we should not have both the .deb and .click installed ever
[15:41] <lool> didrocks: if it's a click, we run ./phablet-click-test-setup first to set tests up
[15:42] <lool> if it's a .deb we install the -autopilot .deb
[15:42] <lool> then we run ./phablet-test-run
[15:42] <lool> karni: hard to tell, depends on the question  ;-)
[15:42] <lool> karni: also, depends if the right person to answer is around or not
[15:43] <cwayne> kenvandine: pushed :)
[15:43] <karni> lool: 1) can't run unity from trunk 2) yeah, probably that's the reason noone's picking up my question ;)
[15:44] <lool> karni: you might want to try pinging Saviq
[15:44] <karni> lool: thanks
[15:44] <Saviq> lool, come over to #ubuntu-unity
[15:44] <Saviq> erm karni ↑
[15:51] <cwayne> mhall119: ping!
[15:51] <kenvandine> cwayne, looking
[15:54] <davmor2> karni: I read that as "1) Can't run from unity trunk"  I thought you going to make  a borg joke it made more sense when I re-read it though :(  I preferred my version :)
[15:54] <karni> davmor2: no worries https://bugs.launchpad.net/unity8/+bug/1248235
[15:56] <kenvandine> cwayne, approved and sponsored
[15:57] <cwayne> kenvandine: i think i've run out of possible beers to owe you.  by now, I think I owe you a brewery.
[15:57]  * kenvandine would love a brewery in the back yard :)
[16:00] <ogra_> brewbot !
[16:00] <cwayne> hah
[16:01] <cwayne> so next step: figure out how i can get this into the image eventually so that i can release my fitbit app as a click...
[16:03] <kenvandine> cwayne, indeed :)
[16:12] <kumar__> Hi, I installed ubuntu touch on my nexus 4 and failed to backup my phone. Is there a way for me to get back to Android OS?
[16:12] <cwayne> kenvandine: is it worth it to start a thread on the mailing list about how to get an acct-plugin into the image? or is it just known that we'll eventually have them as clicks?
[16:13] <kenvandine> just wait til we can have them as clicks
[16:13] <kenvandine> i think that is a must
[16:15] <didrocks> bzoltan: any news?
[16:17] <kenvandine> kumar__, yeah, the installation instructions includes how to flash android back
[16:17] <kenvandine> you'll just need to download the image to use from google
[16:18] <kumar__> so I can download someimage.ab from and then run adb restore someimage.ab?
[16:19] <kenvandine> https://wiki.ubuntu.com/Touch/Install#Restoring_Android
[16:19] <kenvandine> kumar__, ^^
[16:20] <kumar__> ty!
[16:20] <kenvandine> np
[16:21] <kumar__> I really like ubuntu touch, just I need my phone for work. I am mainly just missing A decent google chat app.
[16:24] <kgunn> cjwatson: ping
[16:25] <cjwatson> kgunn: ?
[16:25] <kgunn> cjwatson: hey kdub and i were just chatting about gfx on the emulator you guys are working on...i was assuming you'd use the android arm bins w/ hybris
[16:25] <kgunn> cjwatson: did i assume wrong ?
[16:26] <cjwatson> kgunn: can I redirect you to xnox?
[16:26] <kgunn> cjohnston: certainly
[16:26] <bzoltan1> didrocks:  timp and kalikiana are on it ... I had to do some parenting
[16:26] <xnox> kgunn: emulator is build from source.
[16:27] <xnox> kgunn: cause it's all open-source, without patches it wouldn't even boot our kernel.
[16:27] <didrocks> timppa: kalikiana: do you think you will have something releasable today?
[16:27] <xnox> kgunn: all branches are on phablet.ubuntu.com and in the src package android.
[16:27] <xnox> kgunn: what specifically are you after?
[16:29] <kgunn> xnox: we ( kdub and i) were wondering because the android gfx subsystem is different, e.g. if you're all open src i'm supposing its mesa (drm, kms, gbm) gfx
[16:29] <kgunn> xnox: whereas android the i/f's are totally different...gralloc, hwcomposer
[16:30] <kgunn> xnox: which might mean we're still stuck on hw more than other teams (even after the emulator becomes available)
[16:30] <xnox> kgunn: no its not mesa, it's still android specific.
[16:31] <xnox> kgunn: libGL* which are provided load up translators, that communicated with android-specific-forked-qemu which then execture/translate GL calls on the host and feed the results back to the host.
[16:32] <xnox> kgunn: the emulator is the same one as for Android / Android Open Source Project.
[16:32] <kgunn> xnox: ah...ok...so this still good in that sense
[16:32] <xnox> kgunn: but we patch it and recompile it as needed for touch.
[16:32] <xnox> kgunn: so it's still hybris, it's still lxc container with android in it, and etc.
[16:33] <xnox> kgunn: there are no binary blobs, but other than that, it's quite similar to phones.
[16:34] <xnox> phones are much faster and have more CPU cores and more RAM and faster IO.....
[16:34] <kgunn> xnox: got it...that's good, promising....mir team will never escape hw, but that'll be a handy sounding board
[16:34] <xnox> and emulator at the moment is segfaulting upon attempting to use EGL, so it's a work in progress.
[16:34] <kgunn> ack
[16:43] <kalikiana> didrocks: bzoltan1: note that it's timp the other guy is totally unrelated - apart from that there's been a mixup it seems, I'm not really looking into specific failures I only helped Mirv testing, elopio is looking at autopilot stuff, though and made some branches
[16:43] <didrocks> kalikiana: what is preventing releasing the current trunk with AP 1.3?
[16:43] <didrocks> the question is why are not all tests passing?
[16:44] <kalikiana> I don't know there's been a ton of autopilot errors
[16:44] <didrocks> and nobody worked on them?
[16:44] <didrocks> elopio is only handling autopilot 1.4 transition, right?
[16:45] <elopio> kalikiana: I have just merged a branch into the toolkit and all tests passed.
[16:46] <kalikiana> to the rescue my hero :-D
[16:46] <kalikiana> elopio: link?
[16:47] <elopio> kalikiana: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1244518-composer_sheet_object_names/+merge/192641
[16:47] <didrocks> hum, would have been nice to be pinged about it
[16:47] <didrocks> ok, let's rebuild the toolkit then
[16:49] <t1mp> I'm confused. I don't see problems with jenkins tests at the moment. What exactly is supposed to be broken? I only heard from Mirv that trusty-proposed (with AP 1.4??) has broken uitk tests on device
[16:51] <elopio> I might be confused too.
[16:52] <elopio> and sorry didrocks, I didn't know I had to notify you about changes on the toolkit. That's the last one I need for today.
[16:52] <didrocks> elopio: great! let's hope that all apps AP tests won't regress with it
[16:53] <didrocks> elopio: basically, after that, we can release the toolkit, right?
[16:54] <didrocks> sergiusens: everything on the list released for you?
[16:54] <elopio> didrocks: I'm not the right one to answer that question. t1mp, kalikiana?
[16:54] <tvoss> Saviq, ping
[16:55] <sergiusens> didrocks, please, what's my ETA?
[16:55] <didrocks> sergiusens: I guess a couple of hours
[16:55] <didrocks> sergiusens: as we need to certify the toolkit first
[16:55] <didrocks> sergiusens: then, thomi is going to merge the 1.4 AP branches
[16:55] <sergiusens> didrocks, ack
[16:56] <kalikiana> elopio: didrocks I don't really know what you want to release - this morning I understood the switch was to be prepared for jenkins/ ap 1.4 and there was no word about an image
[16:56]  * sergiusens was confused too
[16:56] <kalikiana> to me it comes as a brave move to both upgrade ap and make an image with it
[16:56] <t1mp> didrocks: our ui-toolkit trunk should always be tested and ready for an image
[16:57] <t1mp> ah, I am not the only one who is confused :)
[16:57] <t1mp> didrocks: nothing should merge into uitk trunk if it doesn't pass all the unit and AP test
[16:58] <didrocks> t1mp: kalikiana: your manager, bzoltan1, was communicated that we wanted to do one release today with AP 1.3
[16:58] <didrocks> then, thomi is going to merge the 1.4 branch this night (for europe)
[16:58] <didrocks> and tomorrow, we rerelease with only this 1.4 change
[16:58] <Saviq> MacSlow, make -C builddir pot_file doesn't work?
[16:59] <Saviq> tvoss, pong, but somewhat afk
[16:59] <tvoss> Saviq, ack, cancel the ping then
[17:00] <MacSlow> Saviq, doh... it does... had a typo
[17:00] <t1mp> didrocks: yes we were asked not to merge new stuff to trunk today and to let AP 1.4 land first
[17:00] <t1mp> didrocks: is there anything else you expect from us?
[17:00] <Mirv> t1mp: we need manual test confirmations of successful AP tests to proceed. I had 3 failing tests on mako and kalikiana had 12 failing tests on maguro.
[17:01] <didrocks> t1mp: we are going to release trunk now, so we needed to ensure we can release trunk
[17:01] <didrocks> which wasn't the case apparently :)
[17:02] <kalikiana> so the real question is why it's possible that we have ap failing even though it couldn't have merged when it did
[17:02] <kalikiana> and given it's still the good old 1.3
[17:02] <didrocks> kalikiana: I guess you know your tests, you will be able to know what changed or if someone else broke you :)
[17:02] <elopio> Mirv: here we have all tests passing in mako, as of two hours ago: http://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/3077
[17:03] <kalikiana> didrocks: how can it have changed without passing?
[17:03] <kalikiana> that's what I don't see - so I got confused in-between thinking it the image was already upgraded
[17:03] <Mirv> kalikiana: there's some magic involved like the tests in mergers not completely similarly run as when doing it oneself. for one each test is executed individually, which is why I asked you to also re-check the failing maguro tests one by one.
[17:04] <didrocks> kalikiana: I'm not responsible for that, you should *know* and *investigate* why
[17:04] <t1mp> jenkins uses trusty-proposed images now?
[17:05] <t1mp> didrocks: jenkins is (today and yesterday) saying that all our merges are good, otherwise they wouldn't merge
[17:05] <kalikiana> Mirv: so it doesn't run the phablet script?
[17:05] <t1mp> which image is jenkins using?
[17:05] <didrocks> t1mp: but elopio fixed something, right?
[17:05] <didrocks> for AP?
[17:07] <elopio> my last fix for the toolkit autopilot tests was merged yesterday: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/818
[17:07] <Mirv> kalikiana: it'd be easiest to check with the QA team, but yes they usually use a more complicated setup including https://launchpad.net/utah framework
[17:07] <elopio> it solved the failures on the gallery toggles.
[17:09] <t1mp> elopio: where did those failures come from? like kalikiana I don't see how we can break stuff if nothing that doesn't pass the autopilot tests can be merged. or did something external to UITK change?
[17:11] <elopio> t1mp: the toggles failures, I'm not sure what triggered them. But I cleaned the tests, split them and used scenarios on them, and now they are stable.
[17:12] <Mirv> t1mp: the process is not failproof, that's why you need to periodically do own checking to stay on track
[17:12] <elopio> right now I'm folloging Mirv's recipe to see if I get the same three failures on my mako.
[17:13] <t1mp> Mirv: yes of course. But if the process fails I like to know what happened.
[17:13] <Mirv> t1mp: in general, trusty has a lot of core system changes because it's a new release so it's hard to say if there's something external affecting or internal to ui-toolkit
[17:13] <t1mp> Mirv: in this case jenkins is fine with everything, but you have fails. What's the difference? Which image does jenkins use?
[17:14]  * t1mp also flashing trusty-proposed now on maguro
[17:14] <Mirv> t1mp: yep, I don't know, but it should help if you can reproduce problems yourselves like kalikiana did with maguro already
[17:16] <t1mp> the past few weeks we have been hunting a lot of these fails, and in the end it turned out we just had to do nothing and wait for another project to fix some issue
[17:16] <t1mp> are projects like mir tested with uitk and apps before changes get merged?
[17:17] <SudoAptitude> Is Ubuntu touched really designed to work with four Nexus devices? Does that mean I cannot install it on my SG Note GT-N7000 ?
[17:17] <Mirv> t1mp: bug hunting crossing team boundaries is a challenge, but at least every team can investigate the errors they see and try to find the cause. as before, ui-toolkit team is in a difficult position with a relatively low-level project with a lot of (good) autopilot tests which may be affected.
[17:17] <sil2100> bfiller: ping
[17:17] <bfiller> sil2100: pong
[17:18] <t1mp> SudoAptitude: check https://wiki.ubuntu.com/Touch/Devices
[17:18] <sil2100> bfiller: we will be publishing ubuntu-keyboard for trusty now, after which we would ask not to merge in any new commits into the trunk for the next one-two days
[17:18] <sil2100> bfiller: since we'll be doing the 1.4 autopilot transition
[17:19] <bfiller> sil2100: ok, gusch tmoenicke ^^^^^
[17:19] <t1mp> Mirv: yes I understand that. But it seems like all projects make a bunch of changes, then we throw everything together in an image, and then we debug. Is there a way to test the changes of individual projects with previous stable versions of other projects?
[17:19] <t1mp> perhaps that is already done
[17:19] <Mirv> t1mp: yes, mir is tested with uitk and apps, but only the archive versions of uitk and apps
[17:19] <t1mp> ah, ok. So what I'm asking for is already there and it is not the solution
[17:20] <Mirv> t1mp: so if mir would break some unpublished change of uitk, that wouldn't be catched. but current archive version of uitk has been tested to pass with everything that's in trusty-proposed at the moment.
[17:20] <sil2100> bfiller, gusch: thanks guys!
[17:20] <gusch> sil2100: bfiller autsch - but ok - please tell me once we can merge again
[17:20] <Mirv> t1mp: we do not throw everything together in an image, but do all kinds of testing before releasing, which is also why we didn't now update the ui-toolkit (yet) because there were problems found not happening with the earlier version of uitk.
[17:21] <sil2100> gusch: sure! I guess all should be clear tomorrow on where we stand
[17:21] <Mirv> t1mp: it's just more confusing and a bit frustrating when you find out there are problems with trunk code that the daily mergers don't spot
[17:21] <SudoAptitude> t1mp: Thanks, I see it can be installed but I can't use it as a Phone or SMS. :-( That's sad..
[17:21] <Mirv> t1mp: but that's part of the reason we have so far partially manual testing, to try to prevent breakage from happening on images.
[17:22] <t1mp> Mirv: yep. I think I've been testing with an old image (#100) because I was told that the images after that were broken
[17:23] <t1mp> Mirv: is there a bug for the new uitk ap fails?
[17:24] <Mirv> t1mp: I asked kalikiana to file one about the maguro failings he saw, but I can file now one of the mako fails I had
[17:24] <t1mp> ok
[17:24] <Mirv> (I should have done that earlier already)
[17:24] <t1mp> if it seems like the same issue, it can be one bug for both phones
[17:26] <Mirv> timppa: bug #1248264
[17:27] <bfiller> xnox, mterry : any ideas about https://bugs.launchpad.net/ubuntu-keyboard/+bug/1247994? Don't understand how it passed CI
[17:27] <ogra_> why are none of these bugs filed in ubuntu ?
[17:28] <xnox> bfiller: maybe there is something wrong with my case? I did $ bzr bd -S --split lp:ubuntu-keyboard; sbuild -d trusty *.dsc
[17:28] <xnox> bfiller: e.g. just stock trusty, trusty-release without any PPAs.
[17:28] <xnox> trusty & trusty-proposed that is.
[17:29] <bfiller> xnox: would think that should be ok, not sure how CI env differs
[17:29] <xnox> bfiller: there is a new revision, let me try that.
[17:30] <bfiller> xnox: from the error looks like it can't find the .presage file but not sure why it would find it under CI - shouldn't be there either
[17:30] <t1mp> Mirv: I'm t1mp on ircnode (timp was taken)
[17:32] <xnox> bfiller: hm, it looks up $HOME/.presage/lm.db so I wonder what $HOME is set to in the CI build and how it leaked into the build.
[17:32] <xnox> bfiller: is it not using sbuild?
[17:32] <xnox> bfiller: oh, and HOME might not be writable under sbuild.
[17:33] <Mirv> t1mp: ah sorry, and sorry timppa too :)
[17:33] <mandel_> barry, ping
[17:34] <bfiller> xnox: not sure, here is the build log from CI: https://jenkins.qa.ubuntu.com/job/ubuntu-keyboard-trusty-armhf-ci/lastBuild/consoleText
[17:35] <t1mp> Mirv: I'm following your recipy now on maguro
[17:35] <barry> mandel_: pong
[17:35] <Mirv> t1mp: just add the '.' to the writable_image
[17:36] <Mirv> t1mp: so kalikian_a had those three tests passing on maguro, but he found other failing tests when he executed the whole suite
[17:36] <mandel_> barry, can you point me to the low level downloader tests you have in the system image upgrade project, I'd like to add those to the u-d-m so that if they fail we do not land branches in trunk
[17:36] <Mirv> t1mp: anyway my meeting is over I'm again ->
[17:36] <mandel_> barry, I'm increasing the tests and integration tests before I add new features
[17:37] <mterry> bfiller, weird
[17:37] <t1mp> Mirv: ok, see you tomorrow
[17:39] <barry> mandel_: http://tinyurl.com/mvswffl
[17:39] <mandel_> barry, awesome, thx, I'll try to get that run in our make check
[17:40] <barry> mandel_: i'm happy to chat/mumble/whatever about any of the details
[17:40] <Mirv> t1mp: robru is looking at ui toolkit now. but really I just upgraded to the newest build (with elopio's change) and the problem was still there, _but_ I noticed the failures I'm seeing may be because of https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests I was doing. so also robru when trying out ui-toolkit make sure to move away /home/phablet/autopilot before running ui toolkit tests as you plan to test the apps as well
[17:40] <xnox> bfiller: I added "export HOME=/tmp" to debian/rules and it now works. I'll make a merge proposal.
[17:40] <xnox> bfiller: so I don't think it's a CI bug, but rather a bug in tests.
[17:41] <bfiller> xnox: ack
[17:41] <Mirv> t1mp: that's another detail in the test setup, that if you test apps you need use the phablet-click-test-setup which downloads tests locally
[17:41] <barry> mandel_: while you're here, do you have any further thoughts on the u/i side of LP: #1215586 ?
[17:41] <bfiller> mterry: see xnox comment above, sound right to you?
[17:41] <Mirv> t1mp: but then I don't know which failures kalikian_a was seeing then, he wasn't using click tests
[17:41] <t1mp> Mirv: huh? what does that mean for me? I need to execute phablet-config autopilot --dbus-probe enable before running the tests?
[17:42] <mterry> bfiller, sounds right.  I'm seeing if I can reproduce just by setting HOME to a bugus value
[17:42] <t1mp> uitk does nothing with click
[17:42] <mandel_> barry, bullocks! I forgot about that one!!!! m**rda m**rda
[17:42] <Mirv> t1mp: no, it means you don't need to do that when you're testing ui-toolkit only - but I wasn't, since we need to test apps as well.
[17:42] <mandel_> barry, I'll get a proposal for tomorrow
[17:42] <mterry> xnox, you're looking at fixing the tests?
[17:42] <barry> mandel_: awesome, thanks
[17:42] <barry> mandel_: oh, and LP: #1245597 :)
[17:43] <kalikiana> t1mp: I commented with my log http://paste.ubuntu.com/6364587/ on https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1248264
[17:43] <mandel_> barry, yeah, that one is in my radar, fixing first the interaction with network issues and then moving to that
[17:43] <t1mp> kalikiana: I was referring to mirv's messages above about the --dbus-probe enable
[17:43] <mandel_> barry, I think is better to return a dbus error.. I mean, if it is empty, I cannot say you finished, right?
[17:43] <t1mp> kalikiana: at 18:40:23
[17:43] <t1mp> more or less ;)
[17:44] <djeypy> hey
[17:44] <xnox> mterry: nah, i'm providing a clean & writeable $HOME
[17:44] <Mirv> t1mp: yes, just ignore the link, I was just explaining why possibly in my case I had the problems
[17:44] <Mirv> t1mp: did one more update to the bug as well
[17:44] <xnox> mterry: such that tests always run in clean environment.
[17:44] <xnox> mterry: I'll create merge proposal in a sec.
[17:44] <barry> mandel_: hmm.  well, another way to look at it is that if it's empty, you're pre-finished. :)  for me, an error wouldn't help.  i'll leave it to you though - if you go with the error, i'll have to keep my workaround
[17:45] <djeypy> hello everybody ubuntu just drive me crazy
[17:45] <djeypy> just won't work on my galaxy nexus
[17:45] <mandel_> barry, I see it as division by 0.. anyway, is easy to fix, so we can take alook of what looks better
[17:45] <barry> mandel_: sounds good, thanks
[17:45] <djeypy> SPAM
[17:45] <djeypy> SAPM
[17:46] <djeypy> SAPM
[17:46] <kalikiana> t1mp: hmm I see mention of /home/phablet there which I don't have, nothing about dbus
[17:46] <djeypy> SPAM
[17:46] <cwayne_> stgraber, heya, got the URL here: https://jenkins.qa.ubuntu.com/job/customization-generic/
[17:46] <t1mp> kalikiana: bash: cd: /home/phablet/autopilot: No such file or directory
[17:46] <t1mp> I get that too
[17:46] <kalikiana> yes
[17:47] <t1mp> kalikiana: I had it also with image #100, but the tests passed tehre
[17:47] <stgraber> cwayne_: I need the internal URL as I can't access the public server from that box
[17:48] <cwayne_> stgraber, PM'd
[17:51] <t1mp> kalikiana: how much time was a phablet-test-run ubuntuuitoolkit ?
[17:51] <elopio> t1mp, Mirv, I am able to reproduce the failures on mako. Debugging...
[17:51] <kalikiana> t1mp: do you think it's worth upgrading via apt-get upgrade and re-run the tests? I don't see ui toolkit changes, though
[17:51] <kalikiana> t1mp: hmm not sure exactly maybe 5min or 10
[17:52] <t1mp> kalikiana: upgrading the device or your computer?
[17:52] <kalikiana> device
[17:52] <t1mp> kalikiana: I did that already, following Mirv's recipy on https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1248264
[17:52] <kalikiana> just checking so we're on the same page here
[17:52] <t1mp> ah doesn't include upgrade
[17:52] <kalikiana> yes that's why I was asking
[17:52] <kalikiana> I followed the steps before
[17:53] <kalikiana> t1mp: what is "click ap tests"
[17:53] <t1mp> kalikiana: where do you see that?
[17:53] <t1mp> kalikiana: Mirv mentioned it but it is new for me
[17:53] <kalikiana> ah sorry I only read "Tim" above the comment :-P
[17:54] <kalikiana> ^^ Mirv
[17:54] <kalikiana> what is "removing the click autopilot tests got me passing AP:s again"
[17:55] <elopio> but they pass using trunk.
[17:56] <t1mp> elopio: with what did they fail?
[17:56] <Mirv> kalikiana: as I already told t1mp, just follow those steps in the bug report, which I didn't since I'm also testing apps.
[17:56] <elopio> t1mp: using phablet-test-run, it used the installed package.
[17:57] <t1mp> elopio: which version is that?
[17:57] <elopio> I then tried from the phone using autopilot run on trunk.
[17:57] <elopio> and it pass.
[17:57] <xnox> bfiller: mterry: hm... now I set a writable home path and it still does not work. I get "error: empty dic file", so where/how does ~/.presage/lm.db is suppose to be generated ?
[17:57] <elopio> t1mp: 0.1.46+14.04.20131105.1-0ubuntu1
[17:57] <sergiusens> elopio, didrocks latest calendar tests fail on my maguro btw; most likely due to the swipe in years -> 2014 != 2015
[17:57] <Mirv> and then if elopio finds problems on mako again, update the bug again :) my testing was really quick now since I'm trying to get towards sleeping, but it seemed the click intervened my testing.
[17:57] <mterry> xnox, odd, it worked for me with a writable fake home
[17:58] <t1mp> elopio: that's today :s I don't see the release listed here https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk
[17:58] <elopio> sergiusens: the tests on the calendar were using indexes. I reported a couple of bugs to improve that.
[17:58] <elopio> the bugs are in progress, so in the mean time, tests will be unstable.
[17:58] <t1mp> elopio: how do we find out which revision that actually is?
[17:59] <sergiusens> elopio, so this is a product of coincidences? http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/11:20131104:20131031.1/4888/calendar-app-autopilot/
[17:59] <stgraber> cwayne_: you should be good to go
[17:59] <elopio> t1mp: I don't know.
[18:00] <t1mp> kalikiana, elopio I commented on the MR. All 93 tests passed.
[18:00] <cwayne> stgraber: thanks! i'll test it out and let you know how it goes :)
[18:00] <t1mp> elopio, kalikiana so on maguro it seems fine.
[18:00] <kalikiana> t1mp: how did you achieve that exactly?
[18:00] <t1mp> kalikiana: you did the same and had failures?
[18:00] <elopio> sergiusens: it's like something changed the order of the QML tree, I'm not sure if it was autopilot, or something with qt.
[18:01] <kalikiana> t1mp: it would seem yes, I followed the instructions and got those failures
[18:01] <t1mp> kalikiana: I executed *exactly* the commands that are in the bug description
[18:01] <sergiusens> elopio, well I can't release a calendar ap with failing tests
[18:01] <elopio> but the tests anyway should never rely on the order of the tree.
[18:01] <sergiusens> and the old version works
[18:02] <kalikiana> t1mp: I'm running the tests once more just in case…
[18:02] <kalikiana> but I'm starting to thnik there's some kind of race or other changing factor
[18:02] <t1mp> kalikiana: one step that is not in the description is that I unlocked the screen (skipped the intro) on the device before executing the tests
[18:02] <elopio> sergiusens: these are the bugs:
[18:02] <elopio> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1247191
[18:02] <elopio> https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1247192
[18:02] <elopio> I'm fine with not releasing new calendar versions untils they are fixed.
[18:03] <t1mp> kalikiana: to be more clear, first I executed a test without unlocking, and it failed, then I remembered to unlock, and ran everything, and all passed
[18:03] <kalikiana> t1mp: indeed I unlocked also by Mirv's adivse and I'm doing that again now - it's running
[18:03] <t1mp> kalikiana: perhaps first we need it to run once locked and fail, and THEN it works )
[18:04] <t1mp> maybe its the magnetic field in germany. may be slightly different in spain
[18:04] <kalikiana> and perform a little dance with a lot of clapping in your hands
[18:04] <t1mp> *earth's magnetic field
[18:04] <kalikiana> I used to do that when I went to a lot of network parties as a teenager
[18:04] <kalikiana> network cables used to work only after some rites performed
[18:06] <t1mp> elopio: can you post your results on mako here https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1248264 to confirm the bug?
[18:06]  * t1mp only has maguro, no mako
[18:08] <elopio> t1mp: commented.
[18:08] <pacificfils> Question: When will sound work in the Clock app?
[18:09] <kalikiana> elopio: hmmm so you see different results when running tests from inside 'adb shell'?
[18:09] <t1mp> elopio: could you build a package from trunk and install that and run phablet-test-run?
[18:09] <t1mp> or that
[18:09] <sergiusens> elopio, not releasing directly blocks your move to autopilot 1.4 though
[18:09] <t1mp> to see if it is a different version of UITK or different test environment
[18:11] <elopio> t1mp: I was trying to do that for the rss app, but it failed to build on the phone, and I couldn't set up a trusty pbuilder on my desktop
[18:11] <elopio> let me try again.
[18:11] <davmor2> kenvandine: I wondered why my phone was a bit sluggish Friends-service 74.5 % of my cpu
[18:11] <kalikiana> t1mp: so for the record exact same 12 failures as last time running 'phablet-test-run ubuntuuitoolkit'
[18:11] <elopio> kalikiana: yes, I see different results.
[18:11] <kalikiana> elopio: so let me run the same packaged tests within adb shell now
[18:11] <kalikiana> I want to be sure there's no random difference here
[18:11] <t1mp> kalikiana: weird. we should have exactly the same environment
[18:12] <kalikiana> t1mp: indeed I don't see how it makes sense…
[18:12]  * t1mp starting another phablet-test-run ubuntuuitoolkit
[18:12] <elopio> and sergiusens, I think thomi has a plan for that, because there are some apps that are failing both with autopilot 1.3 and autopilot 1.4. I'm trying to solve some of them.
[18:12] <t1mp> kalikiana: do/did you have any other apps running? I only tested after rebooting, didn't manually launch any apps
[18:13] <elopio> it should be possible to take the calendar out of the jenkins runs, right?
[18:13] <xnox> mterry: i'm on trusty, building ubuntu-keyboard on amd64 and after debuild: HOME=/foo ./debian/rules override_dh_auto_test
[18:13] <xnox> mterry: reproduces the problem.
[18:13] <kalikiana> nope I explicitly rebooted for that reason
[18:13] <xnox> mterry: is there undeclared build-deps on e.g. presage stuff?
[18:14] <kenvandine> davmor2, woot... we are curious why
[18:14] <kenvandine> robru ^^
[18:14] <kenvandine> davmor2, the only change was polling less often
[18:14] <kalikiana> t1mp: is it possible the script on the desktop picks up some different versions from what's on the desktop?
[18:15] <kalikiana> that would easily explain why we don't see the same
[18:15] <robru> kenvandine, yeah, like *way* less often. we changed it from polling once every 15 minutes to once every hour... but then that got reverted.
[18:15] <kalikiana> but I don't have any idea what it realy does
[18:15] <kenvandine> robru, any debug info we could try to get from davmor2 while he's seeing it?
[18:16] <xnox> mterry: never mind, I had a typo.
[18:16] <davmor2> kenvandine: teatime now I can have a better look when I come back though, all I did was look at top
[18:16] <robru> davmor2, well, is it friends-service or friends-dispatcher that is causing load?
[18:17] <robru> davmor2, enable debugging output and reboot
[18:17] <robru> davmor2, 'gsettings set com.canonical.friends debug true'
[18:17] <robru> davmor2, then reproduce the issue and send us ~/.cache/friends/friends.log
[18:20] <t1mp> kalikiana: I thought the script only executes stuff on device, nothing to do with desktop
[18:20] <t1mp> kalikiana: again all 93 tests OK
[18:20] <kalikiana> t1mp: I'm sort of thinking out loud… still waiting on the "adb shell" run to see if it matches my results from before
[18:21] <kenvandine> robru, i've reproduced it
[18:21] <t1mp> kalikiana: on desktop I have qtdeclarative5-ubuntu-ui-toolkit-plugin: Installed: 0.1.46+13.10.20131011.2bzr813saucy0 Candidate: 0.1.46+13.10.20131011.2bzr819saucy0
[18:21] <kenvandine> according to the log, the service isn't busy
[18:21] <robru> kenvandine, what's going on? deadlock?
[18:21] <kenvandine> it's friends-service
[18:21] <mterry> xnox, right.  But I thought you were thinking of setting a writable HOME as a workaround?
[18:21] <robru> kenvandine, oh, shit, really?
[18:22] <robru> kenvandine, but friends-service doesn't do hardly anything at all!
[18:22] <xnox> mterry: yeap, which is what I now did, I had a typo and hence it was not working =) https://code.launchpad.net/~xnox/ubuntu-keyboard/clean-home/+merge/193979
[18:23] <xnox> mterry: all good now & ready to be reviewed for merging.
[18:24] <mterry> xnox, ok, will give it a spin
[18:28] <mterry> xnox, maybe add a comment on why?
[18:29] <xnox> mterry: as in, why bother fixing?
[18:29] <mterry> xnox, no, just to explain the HOME trickery.  Most packages don't have it, so someone looking at debian/rules might wonder
[18:31] <xnox> mterry: done.
[18:31] <mterry> xnox, approved
[18:32] <xnox> mterry: thanks!
[18:33] <cwayne> stgraber: hey, so i've been looking at our initrd script (that copies over /custom/home), i'm wondering how we can avoid hardcoding phablet there.. $HOME wouldn't be available there, right?
[18:37] <stgraber> cwayne: right, the script runs as root not as the individual user
[18:38] <cwayne> stgraber: could it be as simple as cp'ing to /home/*/?
[18:39] <stgraber> if you mean a for loop going through all the subdirs of /home/, yeah, that'd work
[18:39] <stgraber> still not very clean as there's nothing that guarantees that all users will be under there nor that all entries in /home are homedirs, but for ubuntu touch specifically, it's a fair assumption
[18:42] <cwayne> stgraber: i'd say at the very least, it's better than hardcoding /home/phablet
[18:43] <kalikiana> t1mp, elopio: exact same result so 'adb shell' versus phablet-test-run is the same
[18:44] <aquarius> tedg, ping about upstart starting apps on the phone
[18:44] <melvster> i just bought a vodafone micro sim or my nexus 4 .... anyone know if i can tell if it's been recognized?
[18:50] <nik90> melvster: go the networks indicator
[18:50] <nik90> and there choose the unlock sim option
[18:50] <nik90> melvster: this is if you have a pin
[18:50] <nik90> melvster: it should show the network coverage next to the wifi symbol at the top
[18:51] <elopio> kalikiana: you are in maguro right?
[18:52] <kalikiana> elopio: yep
[18:53] <melvster> worked thanks!
[19:00] <aquarius> jdstrand, ping about detecting whether one is under confinement
[19:01] <beuno> aquarius, there's an app he wrote called Permy
[19:01] <beuno> maybe you could use that, or that code?
[19:01] <beuno> also, hi!
[19:01] <beuno> aquarius, I'm stuck on level 2 of our stupid game
[19:01] <beuno> STUPID
[19:03] <aquarius> beuno, what I really want is the fat packages stuff to be done. Since it isn't quite done yet, I had the nasty thought that I can just have my app's Exec be a shell script which does: if (am_under_confinement) { ld_library_path = "lib/arm/"; } else { ld_library_path = "lib/x86"; }; LD_LIBRARY_PATH=ld_library_path qmlscene myapp.qml
[19:03] <aquarius> and thus have the app load arm binaries on the phone and intel binaries on the desktop.
[19:03] <aquarius> which is a horrific hack, but it oughta work
[19:04] <beuno> aquarius, cjwatson may be able to give you the best tips to work around it for now
[19:04] <aquarius> I figured that am_under_confinement would, say, try to "ls /etc" and then watch for an AppArmor Says No error :)
[19:04] <aquarius> beuno, also, you're stuck on level *two*??
[19:04] <beuno> aquarius, I don't want to talk about it
[19:04] <beuno> TWO
[19:05]  * aquarius grins
[19:05] <aquarius> so you've done the first level, so level 1's clue "one", gave the answer "two" to get you to level 2. So level 2's clue, "TWO", gives which answer to get to level 3?
[19:06] <aquarius> I didn't think I'd have to give hints for level 2 ;)
[19:06] <aquarius> level 4 is harder than it ought to be, if you are not English. This has been explained to me at great length :P
[19:06] <aquarius> beuno, how's things, anyway?
[19:06] <dkessel> hello... does anybody know if there will be official support for the new nexus 7 (codename "razor" i believe?)?
[19:08] <beuno> aquarius, pretty good, back from Oakland and a bit jetlagged. It was confusing to be there again, meetings started to get mixed up in my head from the previous sprint
[19:08] <beuno> dkessel, it's being analysed, no decision yet
[19:08] <aquarius> beuno, heh, yeah, I can imagine: always going back to the same place might be a bit confusing!
[19:08] <beuno> dkessel, Nexus 10 has been confirmed as our tablet target for sure
[19:08] <dkessel> beuno, ok thanks :) i'll better wait with my buying decision then ;)
[19:09] <Guest97390> Anyone have an average time to phablet-flash to finish on a nexus 4?
[19:10] <jdstrand> aquarius: check /proc/self/attr/current. if it says 'unconfined' you are, well, unconfined, otherwise you are under some confinement
[19:10] <beuno> Guest97390, after it's all been downloaded, it can take 5-10 minutes for sure
[19:10] <aquarius> jdstrand, I'm allowed to read that from a script in a click package?
[19:10] <davmor2> robru, kenvandine: right back from tea.  http://ubuntuone.com/08cd7XzyOFu3k9xHbsq3bR  this is the offender :)
[19:10] <jdstrand> well, you aren't allowed to run a script, so 'no'. but an exe could
[19:10] <jdstrand> s/exe/elf/
[19:11] <davmor2> sorry for the blurry image it's hard to keep your hand still :)
[19:11] <jdstrand> owner @{PROC}/[0-9]*/attr/current r,
[19:11] <aquarius> jdstrand, oh! I can't have my Exec= target be a shell script? It has to be a real executable? :(
[19:11] <jdstrand> (ubuntu-* templates)
[19:11] <robru> kenvandine, do you think that's related to what you just fixed? or is this something else?
[19:12] <davmor2> robru: I'll try the debug if you give me about 10 minutes
[19:12] <kenvandine> yes
[19:12] <robru> davmor2, sure
[19:12] <kenvandine> i just proposed a branch
[19:12] <robru> davmor2, does it stay pegged at 74% forever? or just when you first turn it on, and then it calms down after that?
[19:13] <davmor2> robru: mostly occasionally it drops to 12-13% but then its back up to 68.1-76%
[19:14] <aquarius> jdstrand, my master plan was to have the Exec target in my desktop file be a shell script. That's not allowed on the phone at all?
[19:14] <jdstrand> aquarius: no atm, no. the shell is not a target programming environment for the phone :)
[19:15] <aquarius> darnit. that knocks my excellent homemade-fat-packages idea into a cocked hat, then
[19:15] <aquarius> I shall just have to wait until they exist for real.
[19:15] <jdstrand> there are a number of accesses that a shell needs that would have to be investigated as safe for all apps to have
[19:16] <jdstrand> if its any consolation, I think it is a prety high priority
[19:16] <ogra_> heh, funny i tried the same on the weekend
[19:16] <ogra_> (shellscript to pre-process stuff before firing up my app)
[19:17] <aquarius> ogra_, yeah... in the absence of fat packages, I thought "I'll just have a shell script which detects if I'm under confinement, and if I am, assumes that the architecture must be arm" ;-)
[19:18] <aquarius> ogra_, but I can't run shell scripts. So, I lose :)
[19:18] <ogra_> lol
[19:18] <aquarius> gotta wait for actual fat package support.
[19:18] <ogra_> thats a funny way to find out your arch
[19:20] <aquarius> ogra_, I couldn't think of any better ways that are available on the phone while under confinement ;) you can't run dpkg-architecture on the phone because it isn't there, and even if it was you would be confined away from running it ;)
[19:20] <dobey> yeah that seems like a silly way to do it
[19:20] <ogra_> aquarius, hmm, i would guess you can read from /proc
[19:20] <aquarius> dobey, of course it's a silly way to do it. But the better way, which is that the app launcher is fat-package aware and does everything for me, doesn't exist yet.
[19:21] <dobey> doesn't the sdk expose the value from uname() in some way?
[19:21] <aquarius> ogra_, yeah, I can read from /proc, but it's irrelevant because I can't use a shell script as my executable
[19:21] <ogra_> right
[19:21] <dobey> aquarius: well, why do you care what the arch is, in the first place?
[19:21] <aquarius> and I can't use an actual binary as my executable because.... I don't know which architecture I'm on.
[19:21] <ogra_> dobey, because he hates all arm desjktop users
[19:21] <aquarius> dobey, so I can make one click package which can be installed on both the desktop and the phone. That's what fat packages are.
[19:22] <ogra_> arm must be phone :P
[19:22] <dobey> aquarius: yes, but what does that have to do with arch? i can install the existing click packages on my laptop right now if i want to :)
[19:22] <aquarius> ogra_, well, yeah, my stupid hack would screw people in that situation, I admit it ;) Proper fat package support will make everything be good; I was just being impatient
[19:22] <ogra_> heh
[19:23] <dobey> aquarius: you're shipping a binary?
[19:23] <dobey> aquarius: can you not do Exec=foo-arm || foo-x86_64 || foo-i386 ? :)
[19:23] <aquarius> dobey, my QML app requires a binary component to read QR codes. In order that the QML component can be imported by my app's QML, I have to put that component on the QML import path. Since it's binary, I would like to ship binaries for each arch in the one package, rather than shipping one package per arch -- that's what fat packages are.
[19:24] <dobey> aquarius: can't you read /proc from within the QML and adjust the import path inside QML code?
[19:24] <aquarius> dobey, I don't *know* that that doesn't work, but I'll bet a fiver right now that it doesn't ;)
[19:24] <aquarius> dobey, nope. Can't read any files from QML, /proc included.
[19:25] <ogra_> yeah, the jdstrand-lock-in :)
[19:25] <dobey> well, i suppose you probably can't get the PID for qmlscene in QML
[19:25] <aquarius> hell no :)
[19:25] <dobey> which would make reading /proc hard
[19:25]  * jdstrand prefers lockout
[19:25] <ogra_> hehe
[19:26] <dobey> but surely you can read/write files in qml
[19:26] <aquarius> dobey, nope.
[19:26] <aquarius> dobey, database only.
[19:26] <jdstrand> not easily
[19:26] <jdstrand> well, there is localstorage and u1db
[19:26] <ogra_> there are QML file plugins you could ship yourself i suppose
[19:27] <dobey> http://www.mobilephonedevelopment.com/qt-qml-tips/#File%20Access
[19:27] <jdstrand> but, you can also access local json and xml
[19:27] <ogra_> (which will indeed only work inside your confined fs area)
[19:27] <aquarius> ogra_, I can't ship plugins because... I don't know which one to load... because I don't know which arch I am ;)
[19:27] <jdstrand> ogra_: that gets back to elf :)
[19:27] <davmor2> aquarius: as click isn't available on the desktop till the unity8 is I guess the whole argument is a mute point :P
[19:27] <aquarius> the way everyone is getting around this right now is shipping one package per arch, which is precisely what I'm trying to avoid :
[19:27] <aquarius> :)
[19:27] <jdstrand> I was just going to say that
[19:27] <dobey> davmor2: apt-get install click. click install foo
[19:28] <jdstrand> just target armhf until fat is out. fat will be out before unity8 on desktop is :)
[19:28] <sergiusens> aquarius, dpkg --print-architecture could help you
[19:28] <aquarius> the way this should work, in the fullness of time, is that if I install a fat package, the app runner notices that I have done so and execs my package in such a way that its arch-dependent subfolders are on the appropriate paths, so the app runner sets QML2_IMPORT_PATH=$PACKAGEROOT/lib/qml/arm-armwhatever-whatever/ before running the app
[19:28] <jdstrand> can't run dpkg under confinement
[19:28] <jdstrand> yep
[19:29] <mardy> cwayne: pong
[19:29] <davmor2> dobey: and that gets the click package from where?  It's great if you are the dev
[19:29] <aquarius> sergiusens, yeah -- the problem is that I can't run that, becuse (a) I can't run dpkg under confinement, and (b) even if I could, I have nowhere to run it *from* -- I'm not allowed to have my main executable be a shell script, and if it's a binary then I must already know which arch I'm on because I'm running a binary for that arch ;)
[19:29] <sergiusens> jdstrand, is it possible to have exec be something like Exec=qmlscene app.qml -I ./plugins/$(dpkg --print-architecture)
[19:29] <dobey> davmor2: from aquarius's web site
[19:29] <cwayne> mardy: nm, was going to ask for a review on my account-plugin qml-plugin, but i got one :)
[19:29] <dobey> davmor2: or so he can test the click package he just built to check that it works :)
[19:30] <aquarius> er! jdstrand, my exec line is surely not passed to the shell??
[19:30] <aquarius> if it is that solves all my problems, at the expense of solving none of jdstrand's ;)
[19:30] <davmor2> dobey: true
[19:31] <sergiusens> aquarius, aa-exec is a shell script; might work; but not sure it could be a bug that it does
[19:31] <dobey> aquarius: /bin/sh -c MY_ARCH="`dpkg-architecture`" qmlscene foo.qml ?
[19:31] <aquarius> dobey, can't run /bin/sh under confinement. I thought of that :)
[19:31] <jdstrand> aquarius: the upstart job would need to be updated to pass that along I think. that would be upstart-app-launch
[19:31] <dobey> aquarius: is unity8 confined to not run /bin/sh?
[19:31] <aquarius> sergiusens, this feels like the sort of thing where if it does work and I take advantage of it, the security team all come around and punch me in the face
[19:32] <dobey> aquarius: because your app isn't running the Exec line
[19:32] <dobey> oh i guess maybe upstart-app-launch is confined
[19:32] <aquarius> dobey, no, but upstart-app-launch, which *is* running the Exec line, is launched under my app's confinement profile
[19:32]  * jdstrand notes XMLHttpRequest allows reading local files by giving it a Qt.resolvedUrl()
[19:32] <sergiusens> dobey, when you click install you get wrapped into aa-exec
[19:33] <jdstrand> not that XMLHttpRequest helps here-- just saying it is something people can use to read files
[19:33] <aquarius> jdstrand, it does, and it's important that it does; lots of phonegap-style apps use that to read files from their own package.
[19:33] <jdstrand> there is also something for json-- I forget otoh
[19:33] <dobey> jdstrand: well, it would help if one could get the PID of qmlscene
[19:33] <jdstrand> /proc/self?
[19:33] <aquarius> not really: if you can see /proc at all hen you can hit /proc/self, right?
[19:33] <aquarius> heh.
[19:33] <dobey> oh right
[19:34] <aquarius> so the conclusion to all this is that I am SOL and have to wait to deploy fat packages until the OS actually supports them, which was clearly obviously the right conclusion from the beginning. :P
[19:35] <dobey> or don't use binary qml plug-ins that you ship in your package :)
[19:35] <jdstrand> so, to be clear. on non-unity8, the .desktop file is modified to prepend aa-exec-click. on unity8, upstart-app-launch uses apparmor integration in upstart to change profile before starting the process
[19:35] <ogra_> or you could go on trying and find the flaws
[19:35]  * jdstrand welcomes people finding flaws so long as they report them as bugs :)
[19:36] <ogra_> yeah, that might be a bit frustrating if you found a way to make your app work and the way gets killed :)
[19:36] <aquarius> dobey, well, if the SDK starts including a fast QR code reader, I am *more* than happy to use it instead :P
[19:37] <aquarius> ogra_, that's the sort of thing that happens on other platforms. I would like to think that we're better than that :)
[19:37] <ogra_> yeah
[19:40] <cwayne> stgraber: do the boot.img's still live on cdimage?
[19:40] <cwayne> i cant find them on system-image
[19:41] <ogra_> cwayne, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
[19:43] <stgraber> cwayne: boot.img and recovery.img are part of the <device name>-*.tar.xz tarball
[19:43] <stgraber> cwayne: that's what phablet-flash downloads, unpacks and uses for initial flashing
[19:43] <cwayne> ogra_: stgraber thanks!
[19:44] <davmor2> robru, kenvandine: https://pastebin.canonical.com/99896/
[19:46] <davmor2> robru, kenvandine: Meh sorry just realised it was the wrong pastebin happy 2fa to you both :(
[19:46] <kenvandine> :)
[19:48] <robru> kenvandine, wow, that log is horrifying
[19:49] <davmor2> robru: Man that's bad when a dev says it's bad \o/
[19:51] <robru> davmor2, well you have like a dozen different tracebacks that i've never seen before, so...
[19:51] <robru> davmor2, so congrats on breaking it good!
[19:52] <davmor2> robru: it's what I do ask mhall119 ogra_ cjwatson kenvandine
[19:52] <robru> davmor2, aside from the high CPU usage, does friends actually *work* for you at all? do you get new messages in it regularly?
[19:52] <ogra_> ++
[19:52] <kenvandine> davmor2, you're awesome!
[19:52] <davmor2> robru: That is trusty proposed image 11 by the way :)
[19:53] <kenvandine> it's working for me on image 11, even with the pegged cpu
[19:53] <kenvandine> which i confirmed is fixed in that branch
[19:53] <davmor2> robru: there is a message from 2 minutes ago from lego
[19:54] <davmor2> robru: and updated and I see newer ones so yes
[19:54] <robru> davmor2, strange. but good ;-)
[19:56] <davmor2> robru: accounts wise I have facebook, normal google, canonical google, twitter and u1 I thought I'd test accounts :)
[19:57] <robru> davmor2, i see a facebook-related traceback, can you confirm that any messages from facebook are showing up?
[19:57] <davmor2> robru: the lego one was facebook some of the ones after were twitter so they both show, let me check if it is up-to-date though
[20:01] <davmor2> robru: I'm about 2-4 posts behind what is actually in facebook so I'm guessing that is current enough
[20:02] <robru> davmor2, yeah, that sounds good (friends doesn't update super often)
[20:04] <robru> kenvandine, in that pastebin I'm seeing a 'list index out of range', that can only happen if there's a problem with the model schema. *sigh*
[20:05] <robru> oh, wait... maybe not...
[20:05] <robru> i'm thinking of a different list index...
[20:06]  * tedg should just assume all pings are aquarius causing trouble
[20:06] <kenvandine> TypeError: argument msg: Expected Soup.Message, but got gi.repository.Soup.Message
[20:06] <kenvandine> ERROR  Thread-2    2013-11-05 10:32:12,961  friends.utils.base  argument 1: Must be Soup.Message, not Message
[20:06] <kenvandine> robru, ^^ that looks weird
[20:07] <kenvandine> gi changes?
[20:07] <robru> kenvandine, yeah, maybe.
[20:07] <robru> kenvandine, we should report that one to pitti ;-)
[20:09] <davmor2> tedg: that's not fair sometimes it's me breaking stuff too :)
[20:10] <tedg> davmor2, Sure, but aquarius just has more history of being a pain :-)
[20:10] <davmor2> tedg: that'll change muhahahahaha
[20:10] <aquarius> tedg, see above discussion :)
[20:11] <tedg> aquarius, I did.  It prompted the comment.  :-)
[20:12] <tedg> It seems like in the end it was "not my problem" which is always the best type of conversation to read on IRC.
[20:21] <cwayne> stgraber: hm, i tried to do a "for user in `ls /home`" loop and it doesn't appear to run..
[20:25] <aquarius> tedg, yeah; I planned to ask you how to run an app as the phone actually does, but it's not relevant because my plan hinged on my executable being a shell script :)
[20:25] <tedg> aquarius, It can be a shell script, as long as you include your own shell.
[20:25] <tedg> aquarius, dash is tiny
[20:26] <aquarius> tedg, doesn't help.
[20:26] <aquarius> tedg, which arch-specific dash binary does your exec line point to?
[20:27] <stgraber> cwayne: you'd want "for user in $(ls $rootmnt/userdata/user-data/*)" or something along those lines I think
[20:28] <cwayne> stgraber: ah, of course, oops
[20:28] <stgraber> cwayne: the code runs in the initrd, so before the pivot_root and before mountall sets up any of the bind-mounts
[20:31] <tedg> aquarius, Seems like you should be able to do it with QML scene... set the import paths based on architecture?
[20:31] <aquarius> tedg, QML can't read which arch you're on.
[20:32] <aquarius> also, I'm not sure if QML can set QML's own import paths, but that's a side issue :)
[20:32] <aquarius> I could work around the latter, but not the former.
[20:35] <tedg> aquarius, I bet it's one of these: http://doc-snapshot.qt-project.org/qt-mobility/qsystemdeviceinfo.html
[20:35] <tedg> aquarius, Seems you should at least be able to use them to have a good guess.
[20:37] <cwayne> stgraber: have a minute for a review? https://code.launchpad.net/~cwayne18/ubuntu/trusty/initramfs-tools-ubuntu-touch/no-hardcoding-user/+merge/194004
[20:38] <aquarius> tedg, I don't *think* so -- not very accurately -- but that's exactly what I'm trying at the moment ;)
[20:40] <aquarius> is not even clear whether we *have* qtmobility :(
[20:40] <aquarius> mhall119, do I have access to QtMobility DeviceInfo from QML in the Ubuntu SDK?
[20:44] <aquarius> hm. http://qt-project.org/wiki/QML1-vs-QML2 says that I should be using "import QtSystemInfo 5.0", which isn't installed.
[20:47] <aquarius> ah,  qtdeclarative5-systeminfo-plugin
[20:47] <aquarius> let's hope it's on the phone ;)
[20:48] <kenvandine> aquarius, it is
[20:48] <cwayne> doanac: ping
[20:50] <pmcgowan> aquarius, there is an example on how to use that in my junk
[20:50] <doanac> cwayne: hey
[20:50] <aquarius> kenvandine, ah, cool. Do you know if there is documentation on it anywhere at all? All the docs I can find are for qtmobility 1.2.
[20:50] <aquarius> pmcgowan, cool; will take a look
[20:50] <cwayne> doanac: hey, I had some quick questions on our automated smoke testing
[20:50] <pmcgowan> aquarius, zoltan has a version that may be more up to date
[20:51] <cwayne> doanac: 1) it seems to not really be daily?  the last one i saw run was 20131031
[20:51] <doanac> cwayne: looks like stuff ran today: http://reports.qa.ubuntu.com/smokeng/
[20:52] <cwayne> doanac: not for touch
[20:52] <doanac> there's testing for build 11
[20:52] <cwayne> doanac: so that's my question, is it kicked off for builds we're publishing rather than -proposed?
[20:52] <pmcgowan> aquarius, the trick will be getting apparmor to let you do things
[20:53] <doanac> cwayne: touch jobs are kicked off when they show up in -proposed: http://reports.qa.ubuntu.com/smokeng/trusty/touch/ and  http://reports.qa.ubuntu.com/smokeng/trusty/touch_custom/
[20:53] <cwayne> doanac: great, thanks
[20:53] <cwayne> doanac: my second question is, is the touch_custom suite gating?  as in, if it fails does that stop an image from being promoted?
[20:54] <doanac> cwayne: i don't believe so. you'd probably need to ask the landing-pipeline guys to be certain though
[20:54] <cwayne> asac: ^
[20:54] <doanac> cwayne: custom was 100% today though
[20:55] <cwayne> doanac: yep! i'm not worried about anything in specific right now, I'm just trying to get a grasp as to the extent of our testing
[20:55] <doanac> cool
[20:55] <cwayne> doanac: sorry if i freaked you out witht he random questions :)
[20:55] <doanac> cwayne: no worries. there's lots of layers to this process
[21:08] <mhall119> aquarius: if there are html docs for qtdeclarative5-systeminfo-plugin I can get them added to developer.u.c
[21:09] <aquarius> mhall119, well. There's http://doc-snapshot.qt-project.org/qt-mobility/qml-deviceinfo.html but I don't know if that's an older version (and I don't know where that's generated from, either)
[21:09] <mhall119> aquarius: probably older, IIRC there is no "QtMobility" in Qt5/QML2, it was broken up into multiple modules
[21:10] <aquarius> mhall119, that's what I think too. But "QtSystemInfo 5.0", which is the All New QML2 Version, appears to be wholly undocumented. It is hard to tell because of qt-project's constant breaking of URLs and poor google juice, though :)
[21:18] <mhall119> yeah, a lot of the old Qt Mobility APIs don't seem to have new docs published, or at least not where you'd expect them
[21:18] <mhall119> I remember having to hunt down Qt Organizer API docs
[21:20] <dobey> mhall119: are you suggesting that as a way to get the arch?
[21:20] <mhall119> dobey: I'm not suggesting anything other than the fact that we're missing docs
[21:21] <mhall119> aquarius is the one who's going to do something with it
[21:21] <dobey> ok, well, it and deviceinfo don't provide the information he needs. :)
[21:22] <dobey> at least, they didn't a couple months ago when i was looking at using mobility for getting uname() type stuff
[21:23] <dobey> and i looked at the source then too. it's mostly more generic stufff like "this is qt on top of win or symbian" or the imei and such as in those docs (which i'm not sure even works on ubuntu touch)
[21:24] <aquarius> ya. deviceinfo only provides "model" and "manufacturer", and I've just tested them on the phone and they return empty strings.
[21:24] <aquarius> On my laptop they return LENOVO and 1080, which is hardly any more helpful.
[21:24] <aquarius> My quest to emulate a fat package ends in failure, I feel :)
[21:50] <taiebot> Hi guys is ubuntu touch using /usr/share/mobile-broadband-provider-info/serviceproviders.xml ?
[21:51] <taiebot> My phone provider is not listed and i have never been able to connect to 3g.?
[21:51] <cwayne> mhall119: ping
[21:51] <mhall119> cwayne: pong
[21:52] <taiebot> was wondering if this was related?
[21:52] <cwayne> mhall119: hey, just here to volunteer to help re: docs
[21:59] <juken> Hi all, I'm looking over the links in the topic, and although I'm not seeing anything related to the nexus 7 2013 codename razor, I thought I'd ask here if there is any status on it one way or another.
[22:00] <beuno> juken, it's being analysed, no decision yet
[22:00] <beuno> Nexus 10 has been confirmed as our tablet target for sure
[22:01] <juken> beuno: sounds good, thanks :)
[23:06] <kirkland> I copied a couple of *mp4 and *avi files to my Videos folder;  only the mp4 files are showing up in my Videos view
[23:06] <kirkland> are avi's not supported on Ubuntu Touch?
[23:07] <kirkland> or do I need to add some codecs?
[23:12] <xperia> hi to all. i am trying to port ubuntu touch to a new mobile device. i recompiled the kernel successfull with the needed changes for ubuntu touch and need some help with building ubuntu-touch from sources if possible so i am able to test it out on my device. if i am not wrong with the new porting guide 2.0 android is not really needed anymore right?
[23:22] <xnox> xperia: you still need android system.img build.
[23:22] <xnox> xperia: and bootimg.
[23:23] <xnox> xperia: and it's the android portion that one builds from source, the rootfs is more-or-less device independant that one just downloads from cdimage.
[23:25] <user82> xperia, which device?
[23:27] <xperia> its a watch phone called z1
[23:27] <user82> ah
[23:28] <xperia> xnox so is there a step by step guide how to do it? the ones in the wiki is more confusing than helpfull
[23:29] <xnox> xperia: not sure how to make it more clear. Starting from this point in the guide: https://wiki.ubuntu.com/Touch/Porting#Building_the_Android_pieces
[23:30] <xnox> it's fairly step by step.
[23:30] <xnox> xperia: you say you have a kernel, which is a jump to step 6
[23:30] <xnox> xperia: feel free to edit the guide as you see fit.
[23:31] <xnox> xperia: but one does do the dev-setup and enable new device build from that phablet.ubuntu.com based android/repo manifest.
[23:31] <popey> kirkland: yeah, only a limited set of codecs
[23:32] <popey> kirkland: Jim Hodapp knows the details.
[23:34] <xperia> xnox if i am not wrong it say that i need to merge the android git sources with the ubuntu git sources? => "For any Android related project at our git server, you'll find a branch named phablet-trusty. This branch contains a static known git HEAD and the required changes needed for Ubuntu, including our custom Android manifest. " How do you do this ?
[23:34] <kirkland> popey: ah, okay :-/
[23:35] <kirkland> popey: I was thinking of installing on the tablet my daughter uses to watch pixar flicks, etc.
[23:35] <kirkland> popey: but a lot of those are avi
[23:36] <cwayne> anyone around to do an initramfs-tools MR?
[23:37] <xnox> xperia: not sure what you mean. We forked cyanogenmod to build ubuntu touch, and publish our repositories. "repo init -u git://phablet.ubuntu.com/CyanogenMod/android.git -b phablet-saucy" would set the manifest and fetch them with "repo sync".
[23:37] <xnox> xperia: see details about it here https://wiki.ubuntu.com/Touch/AndroidDevel
[23:37] <xnox> xperia: it is a minimalistic android sources (just the bare essentials for hw support) + a few ubuntu touch specific components.
[23:38] <xnox> xperia: if there is a cyanogenmod port for your device, $ breakfast command will fetch additional repositories from cyanogenmod repositories to build the parts that are different for your device.
[23:39] <xnox> xperia: there is nothing to merge....
[23:41] <xnox> xperia: architectually: you will boot your kernel, with ubuntu touch specific initramfs, which should boot device-independant ubuntu-rootfs unpacked in userdata partition, which once booted it boost device-specific android build in an LXC container.
[23:41] <xperia> xnox: ahh okay cool now i understand it. i thinked i need first to download the android sources from cyanogenmod and then merge it with the ones from ubuntu. good working now on it.
[23:41] <xnox> the contents that is launched in the lxc container is combinations is build from the "repo checkout" off phablet.
[23:42] <xnox> xperia: nah, no need to download full cyanogen, that's piles of unused code =)
[23:46] <xperia> :-) lets see if i can present very shortly a full running ubuntu on the computer watch phone Z1 then => http://www.youtube.com/watch?v=ZvlOi-lYMnc