[03:19] <dobey> alex______: not sure what you mean, but you don't "port" x11 apps to xmir. xmir is a translation layer to run x11 apps on top of mir.
[03:20] <dobey> (and i'm not really here, just leaving)
[06:29] <pragomer_1> hi. using ubuntu 15.10. do I have to use "phablet-team" ppa to play a little bit with ubuntu-emulator or is the version in 15.10 working right?
[08:04] <orsonmmz> btw. has anyone managed to successfully use xmir?
[08:09] <Smurphy> xmir ? nope.
[09:57] <oSoMoN> Mirv, hey, with the latest Qt5 update on xenial, I’m seeing QUrl::topLevelDomain() always return an empty string, is that a known issue?
[09:57] <oSoMoN> Mirv, https://launchpad.net/bugs/1551145
[09:59] <Mirv> oSoMoN: I believe it's unrelated to Qt, since I was seeing the same in Qt's own unit tests, and I was forced to skip the failing tests bug #1548686 - the bug should not be closed, but assigned to the problem that apparently appeared between 2016-02-17 09:55:10 and 2016-02-19 08:50:12
[10:00] <Mirv> oSoMoN: I tried to go through all listed changes in xenial that could affect it, and build older versions of gcc5, glibc, gcc-go6 but I couldn't find anything that would fix the unit tests for (unmodified) Qt
[10:02] <Mirv> oSoMoN: I didn't get reactions from people at #ubuntu-devel
[10:02] <oSoMoN> Mirv, wow, skipping the unit tests seems like a bad idea, we should block on this failure until we find the root cause and fix it
[10:02] <oSoMoN> Mirv, it’s gonna break applications in bad ways (webbrowser-app among them)
[10:03] <Mirv> oSoMoN: yes, but block how?
[10:03] <oSoMoN> Mirv, well, not skipping the unit tests, and put priority on investigating the issue
[10:03] <oSoMoN> Mirv, I can help
[10:03] <Mirv> oSoMoN: yeah, agreed it's a priority and the skipping needs to be removed.
[10:05] <Mirv> and I'm happy to get helping hands in understanding it.
[10:06] <Mirv> I just didn't want to not be able to land multi-monitor fixes as 16.04 LTS is approaching and the changes need testing
[10:13] <oSoMoN> Mirv, understood. I’ll be downgrading packages to see if I can nail down the culprit
[10:18] <seb128> oSoMoN, Mirv, gnutls28 changed which could potentially create issues...
[10:19] <seb128> just looking at the -changes list
[11:13] <Mirv> I counted that one as being outside of the time scope since there was failing unit test already in the morning of that day
[11:14] <Mirv> but probably worth checking
[11:15] <fofo314> Has anybody in here recently install ubuntu-touch on a nexus 7 deb?
[11:17] <popey> deb isn't supported
[11:17] <popey> only flo
[11:18] <fofo314> I know, but there is an unofficial port that is mentioned in the wiki.
[11:20] <fofo314> The wiki (https://wiki.ubuntu.com/Touch/Devices) currently says: Nexus 7 2013 (WiFi+LTE) deb Works as well as official flo builds, but supports mobile data on LTE version of N7
[11:21] <fofo314> I was wondering if this is still correct.
[11:21] <fofo314> And if anybody has experience with that device.
[11:22] <fofo314> If this is not the correct forum for asking these questions, please let me knoq.
[11:22] <fofo314> *know
[11:24] <ogra_> this is surely the right place to ask ... but i think the tasemince server hasnt been updated in a while and also points to the rather useless devel/devel-proposed channels
[11:24] <fofo314> ok
[11:25] <ogra_> not sure if there are plans to pull it over to the ubports.com server
[11:27] <fofo314> I have just mailed tassadar to ask if he is still working on the project.
[11:29] <fofo314> What is the worst that can happen if I just put a flo version on the deb Nexus 7?
[11:30] <ogra_> it might not boot
[11:30] <fofo314> ok, but I can always flash back to stock android?
[11:31] <ogra_> ubuntu doesnt touch the bootloader, so yeah, fastboot should always work
[11:32] <fofo314> it's not booting on tassadar deb version either. Ubuntu symbol appears for a few seconds and then the dead "this phone needs restoring from PC..." message appears.
[11:43] <tracinya> Hi^^
[11:44] <tracinya> I got a question concerning the ubuntu touch app store:
[11:45] <tracinya> what I see, there are some available, but is there a full list somewhere? Didn't find anything
[12:31] <raj`> is this the appropriate place to discuss Ubuntu mobile?
[12:31] <k1l_> raj`: yep
[12:31] <raj> cool
[12:31] <raj> why's it so slow?
[12:32] <raj> I was watching a video on it and it's very sluggish
[12:32] <k1l_> because you didnt make it faster
[12:32] <ogra_> what is slow for you and did you file bugs ?
[12:33] <ogra_> (and also, on what device is it slow for you)
[12:36] <raj> I love the unified idea of my computer on my phone, which would just require accessories. And I understand that it would require a lot of processing power. But are current phones practical to run a full-fledged OS like Ubuntu?
[12:38] <raj> like is gutting Ubuntu further to run on current hardware specs practical, or is further optimization diminishing returns and we really just need more powerful hardware?
[12:38] <raj> ogra_, I was seeing this: https://www.youtube.com/watch?v=Je7G5OJ0Y0E
[12:39] <raj> haven't installed it as yet
[12:46] <raj> or it seems I'm mistaken, it doesn't use Debian
[12:47] <k1l_> raj: that is a year old video
[12:48] <raj> This is true.
[12:49] <k1l_> and that is not a samsung s3. that is a nexus4 in that video
[12:49] <raj> Ya, the video was clickbait
[12:49] <raj> I mean, the title
[12:54] <raj> Anyway, I really like the idea of actual open source on phone and wanted to support Ubuntu by adding an app or two to its "appstore" or whatever.
[12:55] <raj> I have an old mobile phone but after seeing the video, I don't know that it can handle ubuntu without driving me insane with lag
[12:56] <raj> (the phone is older than the one in the video)
[12:58] <k1l_> what is it?
[13:00] <raj> Also, I know a guy that knows a guy that has a Galaxy S3, but if it's still laggy then I'd rather not ask the favor, and instead wait till I replace my S6 so I can use it for this endeavor
[13:00] <raj> k1l_, Samsung Galaxy S Relay 4G
[13:00] <ogra_> well, you would need to port to these devices first
[13:01] <ogra_> there are only very few functioning ports beyond the four fully supported phones yet
[13:01]  * ogra_ points at ubports.com
[13:02] <raj> I've never done something so low level
[13:03] <raj> How difficult is this?
[13:03] <raj> this = porting
[13:05] <ogra_> raj, we use the android drivers and some daemons/services that are needed to make them work (a few MB of android running in an lxc container after ubuntu booted) ... to get that to work you need to understand both system rather well (while you thorw away 95% of the android tree you need to know which 5% to keep for example)
[13:31] <raj> ok, so assuredly beyond my pay grade
[13:32] <raj> though, I would think that the same daemons would be needed for most phones
[13:33] <ogra_> well, due to the nature of android they all slightly differ per device
[13:34] <ogra_> the most significant one is rild ... which is the thing talking to your modem and allows you to make calls ... while there is a standard, most manufacturers ignore that and cook their own soup ....
[13:35] <raj> oh, interesting
[13:35] <raj> so rild would still be used, but options would be different?
[13:35] <ogra_> options, API ... functions
[13:35] <raj> ohh
[13:35] <raj> do manufacturers at least stick to their own internal standard then?
[13:36] <raj> between their own devices
[13:36] <ogra_> they seem to ... but its still fiddly and a lot of work regardless
[13:36] <raj> I can imagine
[13:36] <raj> Well, no, I can't even imagine
[13:36] <raj> no no, right the first time, I can imagine
[13:36] <ogra_> haha
[13:41] <raj> anyway, I'm really a fan of what's being done here, it's pioneering in so many ways. The way it will empower and liberate users from a few big corporations that run the market right now
[13:41] <raj> is a gamechanger
[13:41] <raj> it would force them to innovate even further, as well
[13:42] <ogra_> it already did :)
[13:43] <raj> Really? In what ways?
[13:43] <ogra_> UI concepts showing up in android and IOS ...
[13:44] <ogra_> microsoft doing continuum ...
[13:45] <raj> cool
[13:46] <raj> the way linux packages can be run on any distro, is that how ubuntu touch packages are?
[13:47] <ogra_> not in ubuntu touch (or ubuntu snappy which will take over the phone base system eventually)
[13:47] <ogra_> i.e. we use deb packages to assemble the system, but apps are delivered in click packages
[13:48] <ogra_> for convergence there is a way that you can wrap stuff from the archive that exists as deb packages into a click package though
[14:00] <oSoMoN> Mirv, see https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1551145/comments/6 , I have a feeling that a full rebuild of qtbase-opensource-src might make the issue go away, doing one right now on my laptop, will let you know the results
[14:00] <jgdx> pete-woods, those bindings in the Advanced page of the PPTP editor, why do they exist?
[14:01] <jgdx> pete-woods, reason I'm asking is I'm unable to change the mppeStateful prop, but there's no clear reason as to why
[14:02] <pete-woods> jgdx: you have to use a Binding object to stop QML from breaking the connection from API -> widget
[14:02] <pete-woods> although admittedly that's only an issue if another editor changes the values while you already have the VPN editor open
[14:02] <pete-woods> I discovered this when operating both NM applet and VPN editor at the same time
[14:03] <pete-woods> jgdx: the MPPE stateful setting is dependent on the encryption type
[14:03] <pete-woods> jgdx: IIRC in the editor I have bound the enabled state of the various encryption type checkboxes to reflect this
[14:03] <jgdx> pete-woods, not for mppeStateful afaics
[14:04] <jgdx> pete-woods, http://pastebin.ubuntu.com/15243665/
[14:05] <jgdx> what's the nature of the dep? What encryption type does it depend on? requireMppe?
[14:05] <jgdx> i guess
[14:05] <pete-woods> jgdx: it needs one of the MS encryption types
[14:05] <jgdx> okay, great, thanks
[14:06] <jgdx> pete-woods, you got a typo in i18n.tr("All Availale (Default)"), :)
[14:06] <pete-woods> whoopsie!
[14:07] <jgdx> avail thyself!
[14:08] <pete-woods> jgdx: FYI, I have done that binding thing with every boolean property in the VPN editor now
[14:09] <pete-woods> jgdx: and in-case you want a link to the latest build (http://people.canonical.com/~pete/vpn-editor/com.ubuntu.developer.pete-woods.vpn-editor_0.3.0_all.click)
[14:09] <jgdx> thx
[14:09] <pete-woods> which has all the PPTP stuff in
[14:10] <pete-woods> (I also cleaned up the file dialogue stuff into its own dir, instead of being splatted around)
[14:13] <jgdx> pete-woods, built off of  i-n trunk though, right?
[14:13] <pete-woods> yep
[14:13] <pete-woods> jgdx: ^
[14:21] <fofo314> So flashing ubuntu touch flo onto deb worked. Current Problems: no sound, of course no LTE
[14:23] <Mirv> oSoMoN: well there's another rebuidl just finished at silo 051 ( 5.5.1+dfsg-14ubuntu3~xenial1~test1 ). you could try that in case you think it's something that would be fixed by (yet another) rebuild.
[14:23] <oSoMoN> Mirv, great, I’ll try that
[14:29] <oSoMoN> Mirv, nope, the packages in silo 51 don’t solve the issue
[15:08] <jgdx> pmcgowan, hey, even with -pd on mako I'm getting ~40 sec reboot after a language change. So normal
[15:08] <ogra_> shutdown really sucks
[15:08] <ogra_> takes way longer than it should
[15:09] <pmcgowan> jgdx, before there is ay feedback to the UI?
[15:09] <pmcgowan> any
[15:09] <jgdx> takes 30 sec to see the google logo
[15:09] <pmcgowan> I dont recall it being like that
[15:09] <pmcgowan> but the UI stays up the entire time?
[15:09] <ogra_> it takesd more than 30sec to shut down
[15:10] <ogra_> and you see a black screen
[15:10] <pmcgowan> yeah but unity should go away immediately
[15:10] <jgdx> no, pressing “restart” makes the screen go black immediatel
[15:10] <pmcgowan> I see the UI stay there for a min
[15:10] <ogra_> (depending on the device it flashes the backlight too)
[15:10] <pmcgowan> thats what happened on the show floor, it took forver with no feedback
[15:10] <ogra_> pmcgowan, that sounds broken ... on all my devices it goes immediatle black here
[15:10] <pmcgowan> I will try to repro here
[15:10] <jgdx> pmcgowan, hey, I think we make a simple dbus call, maybe you can execute that and see if you get the lag still.
[15:10] <pmcgowan> right
[15:10] <pmcgowan> this was on the tablet with the full app set
[15:10] <ogra_> the 30-60 sec you sit in front of a black screen are broken though
[15:11] <pmcgowan> agreed
[15:11] <ogra_> it should show a splash and also not take longer than 10sec
[15:14] <jgdx> pmcgowan, $ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Reboot false
[15:16] <pmcgowan> jgdx, did you get an m10 yet?
[15:17] <popey> is pmcgowan doing an Oprah Winfrey and giving away tablets? :)
[15:17]  * ogra_ would love to be asked the same :P
[15:17] <jgdx> pmcgowan, nah, the customs guy called me and said he had started a search for it. I think they dropped the ball
[15:17] <jgdx> he's gonna call me back
[15:17] <pmcgowan> bah
[15:18] <pmcgowan> popey, yeah you need one :)
[15:18] <popey> I do!
[15:50] <pmcgowan> jgdx, I can't reproduce it
[15:51] <jgdx> pmcgowan, but you can from the ui?
[15:51] <pmcgowan> jgdx, no
[15:51] <pmcgowan> jgdx, so not sure what state that tablet got into
[15:57] <dobey> mariogrip: hey; for hammerhead, can you copy v2 image to v4 perhaps?
[16:06] <jgdx> pmcgowan, could be dbus was being hammered by something.. or uss could have frozen
[16:06] <pmcgowan> jgdx, the UI was responsive at the time, but could be dbus
[17:04]  * ogra_ sees Mir 0.20.1 land in the archive and hugs kdub 
[17:05] <ogra_> looking forward to less transparent indicators and splash screens :)
[17:06] <ogra_> (though a bit of transparnecy might actually not be bad ... just not to a point making everything unreadable)
[17:09] <kdub> ogra_, yeah, was kinda a weird driver bug... some extensions broke z depth testing
[17:09]  * kdub is glad its in archive too now
[17:21] <pixel__> ping ogra_
[17:24] <pixel__> i need some help, when i install https://uappexplorer.com/app/balls.briketa it doesn't  create ~/.local/share/balls.briketa/
[17:25] <pixel__> that should be XDG_DATA_HOME / applicationName
[17:25] <pixel__> i need that dir to save a file in it
[17:26] <ogra_> pixel__, iirc only the first run creates that
[17:26] <ogra_> (though i'm not 100% sure ... its been i while i touched click stuff last)
[17:27] <pixel__> ogra_, i get a lot of messages in reviews that the game can't save (and of course the don't have the XDG_DATA_HOME / applicationName dir
[17:27] <slvn_> hello pixel__
[17:27] <pixel__> hello slvn_  and ogra
[17:27] <slvn_> you sent me a message a few days ago about that but I was away
[17:27] <pixel__> and so i've rm -r the dir and removed/reinstalled the game (it did not create the dir)
[17:27] <ogra_> did you run it once ?
[17:27] <pixel__> slvn_, ah it was about this :D
[17:28] <pixel__> ogra_, yep
[17:28] <ogra_> hmm
[17:28] <ogra_> tedg, ^^^ any hint from the XDG master ?
[17:28] <slvn_> pixel__, you wanted a directory to save you file, as a SDL2 app I guess
[17:28] <dobey> pixel__: it's not created automatically; you need to create the directory you're saving into
[17:28] <pixel__> slvn_, you have some SDL games that saves the settings, right?
[17:29] <tedg> Yeah, I think the app needs to create that directory.
[17:29] <ogra_> ah
[17:29] <pixel__> oh...
[17:29] <ogra_> i thought the launcher does that
[17:29] <tedg> We had discussed making it by default, but no action has been taken.
[17:29] <dobey> no, the launcher doesn't do that
[17:29]  * ogra_ remembers that discussion :)
[17:29] <tedg> There was worry about making unneeded directories.
[17:29] <pixel__> the sdk does that
[17:29] <dobey> yeah, there's no reason to make it if the app isn't going to use it
[17:29] <dobey> then i guess the sdk has a bug :)
[17:29] <pixel__> when i launch the game from qt on the phone it does make the dir
[17:29] <ogra_> pfft ... inodes are cheap
[17:30] <tedg> Yeah, the problem is that developers forget and get bugs.
[17:30] <pixel__> so this is why i was so confused
[17:30] <tedg> It would be nice if we could remove bugs from the system :-)
[17:30] <slvn_> pixel__,  you need (in c) :        getenv("XDG_CONFIG_HOME")  and getenv("APP_ID");
[17:30] <dobey> ogra_: i think we should avoid unnecessary disk writes though
[17:30] <pixel__> but anyway, please make the os make that dir on first launch
[17:30] <pixel__> i don't want to make it myself
[17:30] <ogra_> dobey, did pmcgowan bribe you ?
[17:30] <ogra_> :P
[17:30] <mcphail> tedg: can you update the Runtime Environment section of https://developer.ubuntu.com/en/start/platform/guides/app-confinement/ to say we have to make those directories ourselves? The implication is they exist already
[17:30] <dobey> ogra_: no; i know how flash works :)
[17:31] <ogra_> dobey, (indeed i agree though) :)
[17:31] <dobey> pixel__: no, fix your app to create the directory it is saving into
[17:31] <dobey> pixel__: if your app doesn't check a directory exists, and create it, before writing into it, then your app is broken.
[17:31] <tedg> mcphail: I don't have access to that, but I think that mhall119 probably can
[17:31] <pixel__> dobey, no, i will open a bug report
[17:32] <mcphail> tedg: thanks. mhall119 - can you help with the documentation in my link above ^^^?
[17:32] <pixel__> dobey, the sdk does make the dir
[17:32] <dobey> pixel__: if the system does it, it creates directories for every app, even if they aren't needed, and it wastes disk writes, which reduces the life of the flash storage
[17:32] <dobey> pixel__: the sdk is broken
[17:32] <dobey> the sdk should not create the directory
[17:33] <pixel__> slvn_, thanks :D that's how i do it but the problem is that there is no appname dir
[17:33] <ogra_> pixel__, dobey is right ... if every app would create that dir on launch you would drown in useless dirs under ~/.local/share/
[17:33] <pixel__> slvn_, you have to create that dir yourself, right?
[17:33] <slvn_> pixel__,   mkdir(buffer, 0755);
[17:33] <slvn_> yes
[17:34] <slvn_> also strip the "_" and whatever is after  from the directory name
[17:34] <pixel__> slvn_, right :d got it! 10x much :D you're the man
[17:34] <ogra_> i guess 90% of apps in the store dont need it at all
[17:34] <slvn_> :) ... I think I got the same directory issue  ..
[17:35]  * mcphail pokes slvn_ to fix the saving on his solitaire app ;)
[17:35] <pixel__> slvn_, it's not the sanest OS :>>
[17:35] <pixel__> but yeah.. it sort of works
[17:36] <ogra_> pixel__, !
[17:36] <dobey> eh? you have to create directories on any OS, before you write into them
[17:36] <slvn_> mcphail,  this is a bug ? the saving should be fine !!
[17:36] <mcphail> slvn_: yes - settings don't get saved beyond reboots. Think you might still be saving them to /tmp
[17:37] <slvn_> this should have been fixed for 1 month ! I used to save in RUNTIME_DIR, now I save in XDG_CONFIG_HOME
[17:38] <pixel__> ogra_, ls  ~/.local/share/
[17:38] <mcphail> slvn_: don't think I got an update for the solitaire app. I know some of your other apps were updated
[17:38] <pixel__> ogra_, http://paste.ubuntu.com/15245329/
[17:39] <slvn_> mcphail, did you update the app ? it should be version 1.01
[17:39] <dobey> …
[17:39] <mcphail> slvn_: yep - this is version 1.01
[17:40] <pixel__> ogra_, looks like every installed app has the dir
[17:40] <ogra_> phablet@ubuntu-phablet:~$ ls .local/share/ |wc -l
[17:40] <ogra_> 166
[17:40] <ogra_> phablet@ubuntu-phablet:~$ click list |wc -l
[17:40] <ogra_> 141
[17:40] <ogra_> some dont here ...
[17:41] <pixel__> some but most do :D
[17:41] <pixel__> anyway
[17:41] <slvn_> yep solitaire is updated ! so it should be fixed... When I fixed it, I remember I even asked someone to double check :/
[17:41] <pixel__> please make a dir it will make my life easier :))
[17:41] <ogra_> pixel__, might be that some QML component actually creates it
[17:41] <popey> pretty sure thats the case
[17:41] <ogra_> but we should really fidx that
[17:41] <popey> we had this discussion recently
[17:41] <pixel__> ogra_, most probably
[17:42] <popey> someone elese had an app which wasn't qml and didnt have the dir
[17:42] <ogra_> apps not needing that dir should definitely not create it
[17:42] <popey> an sdl app
[17:42] <popey> "app"
[17:42] <pixel__> me?
[17:42] <pixel__> ))
[17:42] <ogra_> it should be an easy flag you can set or some such
[17:42] <mcphail> slvn_: I'll reboot and test again
[17:42] <ogra_> which is off by default
[17:42] <slvn_> pixel__, better, you should complain in #SDL channel to implement SDL_GetPrefPath ! (and to do the mkdir inside !)
[17:43] <ogra_> and if you need storage for your app you can simply flick that switch
[17:43] <ogra_> i assume these dirs get not deleted if you remove the package
[17:43] <ogra_> which is pretty bad
[17:44] <mcphail> slvn_: yep - not saving...
[17:44] <pixel__> ogra_, yep the dir remains
[17:44] <dobey> ogra_: no, not deleting data is correct
[17:44] <popey> ogra_: long standing bug
[17:44] <ogra_> dobey, not sure
[17:45] <dobey> data should be retained. not deleting also avoids disk excessive writes
[17:45] <pixel__> slvn_, right :> :D i did try SDL_GetPrefPath and it didn't worked
[17:45] <ogra_> dobey, on space contraiend devices it also just wastes spacee
[17:46] <dobey> though app dirs in ~/.cache/ should probably get deleted
[17:46] <ogra_> *constrained
[17:46] <mcphail> ogra_: not deleting data under ~/.local is the Debian way
[17:46] <dobey> ogra_: it needs to be up to the user to decide when to delete actual data though
[17:46] <ogra_> dobey, lol
[17:46] <slvn_> pixel__, yes SDL_GetPrefPath *should* be implement for ubuntu (touch)
[17:46] <pixel__> slvn_, maybe in a couple of years ...
[17:46] <ogra_> dobey, because we indeed give the user a proper interface to do that :P
[17:46] <pixel__> :(
[17:46] <dobey> ogra_: if i delete instagram, it shouldn't delete all the photos i took with it
[17:46] <popey> we do
[17:46] <popey> there is an app which can manage user data
[17:47] <slvn_> mcphail, ... strange :/ are you sure it saved first ?  can you make sure the apps was exited ?
[17:47] <popey> it's just a) not in the default image, b) not in the store
[17:47] <ogra_> popey, usable enough for my mom without knowing file structure etc ?
[17:47] <mhall119> mcphail: which directories do you have to create?
[17:47] <popey> yes
[17:47] <dobey> popey: the system-settings UI should have it; but it's a bit buggy at the moment
[17:47] <popey> yeah, i agree
[17:47] <ogra_> s/file/filesystem/
[17:47] <popey> ogra_: it's very simple
[17:47] <mcphail> slvn_: yep - saved and exited by the exit option in menu, rather than swiping away. Settings for auto-collecting cards etc don't persist over reboots
[17:47] <ogra_> not the filemanager then ?
[17:47] <popey> no
[17:48] <ogra_> ah, k ... i thought that was what you were getting to
[17:48] <popey> and there's a thousand other things your mum would have trouble with
[17:48] <popey> so this is just one
[17:48] <ogra_> yeah
[17:48] <mcphail> mhall119: certainly XDG_DATA_HOME/<APP_PKGNAME> seems to need to be created manually
[17:48] <ogra_> that is why she still doesnt have an ubuntu phone
[17:48] <dobey> mcphail: yes of course it does
[17:48] <popey> yes
[17:48] <mhall119> mcphail: and which part of that page needs to be updated?
[17:48] <popey> people have been assuming it's created
[17:49] <mariogrip> dobey: Yeah, I could. maybe revert back to r2 and stop updating until the issue is fixed
[17:49] <dobey> popey: becqause the SDK creates it during deployment
[17:49] <dobey> which is evil
[17:49] <pixel__> dobey, yep
[17:49] <mcphail> mhall119: the Runtime Environment part would be better if it mentioned that directory needs to be created. Just now, it says that you can write _in_ the directory, but doesn't say you must create it first.
[17:49] <pixel__> very!
[17:50] <mhall119> mcphail: ok, I'll put it on my list of things to do today
[17:50] <mhall119> thanks for pointing it out
[17:50] <mcphail> mhall119: ta!
[17:50] <mariogrip> dobey: I ment "on server side" not that you should stop updating and rever
[17:50] <mariogrip> revert*
[17:50] <pixel__> or at least please modify the doc  https://developer.ubuntu.com/en/start/platform/guides/app-confinement/
[17:51] <mariogrip> dobey: Could you grab some logs next time? syslogs is ok
[17:52] <ogra_> pixel__, that doesnt talk about creation of the dir
[17:52] <ogra_> just tells you that you are not denied access to that location
[17:53] <dobey> mariogrip: sure
[17:53] <ogra_> unless i'm missing it
[17:54] <slvn_> mcphail,  could you copy paste the log (I think it's in .cache/upstart/ application-click-com.ubuntu.developer.1bsyl.solitaire_  ) ?
[17:54] <dobey> no, why would the confinement guide describe what directories your app needs to create
[17:55] <popey> Non touch apps have to create their own directories.
[17:55] <popey> (I mean, standard desktop X apps)
[17:55] <popey> or indeed command line tools. This is not new.
[17:55] <dobey> all apps have to
[17:55] <mcphail> ogra_: it doesn't specify you _can_ write to XDG_DATA_HOME to create the directory in the first place. The implication is that XDG_DATA_HOME/<APP_PKGNAME> is created by default
[17:55] <dobey> since forever :)
[17:55] <dobey> mcphail: i don't think that's implied
[17:55] <dobey> mcphail: i think some might be inferring that though perhaps
[17:56] <ogra_> mcphail, yeah, thats not how i read that page
[17:56] <mcphail> slvn_: will do. I'll be home in about an hour and can do it then
[17:56] <dobey> likewise, google maps doesn't tell me that i need a visa and 5000 different innoculations to visit india
[17:56] <mcphail> dobey: It says you can only write to certain directories, and does _not_ include the directory you have to write to to create that dir
[17:56] <dobey> it just shows me where india is
[17:57] <mcphail> dobey: the whole point of the page is to explain where you can and cannot write
[17:57] <dobey> mcphail: and it does that
[17:57] <mcphail> dobey: no, it doesn't. It doesn't tell you you can mkdir in XDG_DATA_HOME
[17:58] <dobey> mcphail: you can't
[17:58] <mcphail> dobey: then you can't create XDG_DATA_HOME/<APP_PKGNAME> ...
[17:58] <dobey> yes you can
[17:58] <dobey> mcphail: it's not a document detailing unix permissions
[17:58] <dobey> it's about apparmor restrictions
[17:59] <dobey> you can create any directory in $XDG_DATA_HOME as long as the directory name is the same as your package name
[17:59] <mcphail> I'm not disputing that. But it is supposed to be a clear guide to what you can and can't do. To an outsider, that is not clear, hence all the confusion above
[18:00] <mcphail> and I still don't know if the cache and config dirs need to be created manually
[18:00] <dobey> yes they do
[18:01] <dobey> well, it depends on what APIs you use
[18:01] <mcphail> So an extra sentenc in the Runtime Environment section would clarify that for everyone
[18:01] <dobey> if you are embedding the Ubuntu.Web component, it will create some directories, for cache/localstorage/etc
[18:03] <mcphail> I've routinely "mkdir -p"'d those directories in my apps, but only because old habits die hard ;) But there have been several queries on here about this over the past few months
[18:03] <dobey> this is the first one i've seen
[18:03] <dobey> but maybe all the others were in oz time or something :)
[18:04] <mcphail> :)
[18:05] <mcphail> If the SDk is creating those directories, it would certainly explain how hard we've found it to track down why some phones were "creating" them during development but others weren't on deployment
[18:05] <dobey> anyway, i was simply making the point that being allowed to write somewhere does not mitigate extra requirements for somewhere to exist first
[18:09] <pixel__> bug reported https://bugs.launchpad.net/canonical-devices-system-image/+bug/1551365
[18:09]  * pixel__ aw for milk, mm
[18:29] <mcphail> slvn_: there isn't anything exiting in the logs. But is see XDG_CONFIG_HOME/<APP_PKGNAME> doesn't exist on my device, so I suspect this is the same problem as above. You'll need to create that dir manually before config can be saved
[18:34] <dobey> sigh
[18:46] <pix_aw> phew... phablet@ubuntu-phablet:~/.local/share$ ls | grep balls.briketa
[18:46] <pix_aw> balls.briketa
[18:47] <pixel___> should work now, if you want to try/play the game https://uappexplorer.com/app/balls.briketa
[18:47] <pixel___> have fun
[18:47] <popey> \o/
[18:47] <popey> pixel___: BALLS!
[18:48] <pixel___> yay :D
[18:48] <slvn_> mcphail, I do create the dir with "mkdir(buffer, 0755);" ...   There should be the usual logs of the app ~/.cache/upstart/app-name.log :/
[18:49] <slvn_> I am not sure again where logs are ...
[18:49] <slvn_> pixel___,  can you check that your config files are persistent upon reboot
[18:49] <pixel___> slvn_, sure :D rebooting now
[18:52] <pixel___> slvn_, phablet@ubuntu-phablet:~/.local/share/balls.briketa$ ls
[18:52] <pixel___> lvl.ini
[18:52] <pixel___> yep still there
[18:54] <slvn_> pixel___,  and  you build the dir with  $env(XDG_CONFIG_HOME) /  $env(APP_ID)    (without whatever come after "_" ) ?  and mkdir(buffer, 0755); ?
[18:55] <pixel___> slv i just hardcoded the path  mkdir("/home/phablet/.local/share/balls.briketa", 0755);
[18:55] <pixel___> slvn_, ^^
[18:56] <slvn_> mcphail,  there is a possibility : I remember I (stupidly) screwed up the mode (O755 vs 0755) when I tried that first ... And you probably were helping me, I might have left a wrong directory created on your device ... could you check the perms of this dir ?
[18:58] <slvn_> pixel___,   ok thanks ! if you want the version with "env" var : http://paste.ubuntu.com/15245990/
[18:58] <mcphail> slvn_: which dir?
[18:59] <slvn_> mcphail,  in $XDG_CONFIG_HOME, the one like "...solitaire..."
[19:00] <mcphail> slvn_: I don't have anything under .config related to your app, unfortunately
[19:00] <pixel___> slvn_, thanks :D
[19:00] <mcphail> slvn_: my log, if you want it, is at http://termbin.com/l747
[19:02] <mcphail> slvn_: contents of my config dir at http://termbin.com/lxlg
[19:03] <slvn_> ... strange :/
[19:03] <slvn_> so I will go for diner :)
[19:04] <mcphail> slvn_: bon appetit :)
[19:04] <slvn_> merci )
[19:04] <slvn_> :)
[19:04] <slvn_> I will look at the issue afterward. ... I will try again some test on marvin bot
[19:05] <slvn_> I swear I tested this correction, so I am very disappointed
[19:05] <mcphail> slvn_: I'll unistall and reinstall, just in case I have a development version instead of the real thing
[19:06] <slvn_> ok thanks !
[19:10] <mcphail> slvn_: success! I must have had an old version you gave me to test
[19:49] <slvn_> mcphail, ok great ! so I'm not crazy :)
[19:57] <mcphail> slvn_: je suis désolé ;)
[20:06] <mimecar> labsin, do you need i Test the scope?
[20:06] <mimecar> I've found an update
[20:14] <labsin> mimecar: If you have an account, yes. Otherwise it should already be fine. Thanks.
[20:15] <mimecar> no, I have not an account on Deeze
[20:15] <mimecar> scope info works ok now
[20:20] <mhall119> mariogrip: it looks like Google didn't choose us for Summer of Code, but hopefully we can find some porters to help you anyway
[20:21] <mariogrip> mhall119: awww :( Yeah, I think if we make it easier it will bring more porters
[20:24] <mhall119> mariogrip: I still have to mount /cache and /data in adb before I run ubuntu-device-flash, is that something that can be fixed in the recovery image?
[20:24] <mariogrip> mhall119: but, was there a reason why?
[20:24] <mariogrip> mhall119: Yeah
[20:25] <mariogrip> mhall119: I have that on my todo list
[20:30] <mhall119> mariogrip: no reason given yet, we're going to try and get some feedback from them we can use to make our application better next time
[20:33] <labsin> mimecar: thanks