| === xiinotulp is now known as plutoniix | ||
| AndroUser | anyone use ubuntu phone | 03:42 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| jr_ | Is there any news on ubuntu touch being able to be installed on tablets? I realize there are a few projects for select devices. but I mean to be installed on tablets in general | 04:30 |
| Lurrdock | Hello | 06:00 |
| lesamourai | Hello , ubuntu aquarius 5 phone entered boot loop , any possible solution? | 06:04 |
| Stanley00 | lesamourai: well, did you try reflash with the rom from bq? | 06:07 |
| lesamourai | reset to factory settings is only thing I tried and it didn't solve it | 06:08 |
| lesamourai | and now its constantly rebooting .. | 06:10 |
| Stanley00 | lesamourai: ok, you can try reflash then, here's the tools http://www.bq.com/gb/support/aquaris-e5-ubuntu-edition | 06:10 |
| lesamourai | thanks , will go through them | 06:12 |
| * guest42315 they see me rollin' la la la | 08:39 | |
| JamesTait | Good morning all; happy Thursday, and happy Punctuation Day! 😃 | 09:36 |
| Inoki | JamesTait: woot woot! Happy Thursday to you too! | 10:02 |
| tathhu | Ayyy | 10:12 |
| === chihchun is now known as chihchun_afk | ||
| === psivaa is now known as psivaa-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === psivaa-lunch is now known as psivaa | ||
| kenvandine | jdstrand, i'm working on surfacing some apps installed inside libertine containers in the peer picker, how would you feel about adding a rule like this to the content_exchange policy to allow read access to the icons? | 14:33 |
| kenvandine | @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/* | 14:33 |
| === dandrader_ is now known as dandrader | ||
| jdstrand | kenvandine: that would all untrusted apps to enumerate installed apps on the system | 14:37 |
| kenvandine | well, the themed icons | 14:38 |
| kenvandine | they might not be provided by the apps... but i see your point :/ | 14:38 |
| kenvandine | jdstrand, they already have access to the themed icons... in /usr/share/icons/ | 14:38 |
| jdstrand | kenvandine: yes, that's true. perhaps I don't understand what is in @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/* | 14:41 |
| jdstrand | I don't care at all about access to themed icon sets | 14:42 |
| jdstrand | in general | 14:42 |
| kenvandine | that's the directory for themed icons inside the containers | 14:42 |
| jdstrand | however, iiuc, anything that is installed via apt-get might get themed icons | 14:42 |
| kenvandine | yes | 14:43 |
| jdstrand | which means an untrusted app could enumerate what the user installed in the container | 14:43 |
| kenvandine | just by finding the icons, but quite a few of those are there without matching apps | 14:43 |
| kenvandine | they could potentially compare what's inside the default sets of icon themes and look for extras | 14:43 |
| kenvandine | to deduce the delta | 14:44 |
| jdstrand | yes. like I said, any system supplied ones are fine because that doesn't leak anything about the user | 14:44 |
| jdstrand | right | 14:44 |
| kenvandine | jdstrand, so since they could try to compare what icons are there, i need to find another way to show the icons in the peer picker, right? | 14:46 |
| kenvandine | getting the image data from a themed icon requites a qguiapplication :/ | 14:47 |
| kenvandine | and i really don't want to turn content-hub-service into that | 14:47 |
| jdstrand | kenvandine: that is what I'm thinking yes. I might suggest that the out of process picker either displays it, or opens it and passes the fd | 14:47 |
| kenvandine | it isn't an out of process picker right now | 14:48 |
| kenvandine | that's the issue, the picker is a qml component in process | 14:48 |
| jdstrand | oh | 14:48 |
| kenvandine | we use the service side to marshal the icons for click apps | 14:48 |
| jdstrand | hmm | 14:48 |
| kenvandine | the ones we get full paths to the icons for | 14:48 |
| kenvandine | but we can't get that for themed icons | 14:48 |
| kenvandine | it's a hard problem :/ | 14:49 |
| kenvandine | i could get a pixmap if the service was a qguiapplication | 14:49 |
| kenvandine | and marshal it over dbus as well | 14:49 |
| kenvandine | but i really don't want to do that | 14:49 |
| jdstrand | kenvandine: I'm not clear on what makes qguiapplication different. in that case it will talk to some out of process other service? | 14:52 |
| jdstrand | is that the thumbnailer? | 14:53 |
| kenvandine | it would essentially be a gui app without a window | 14:53 |
| jdstrand | right, but why does that work? | 14:54 |
| kenvandine | QIcon::fromTheme will load a pixmap for the icon | 14:55 |
| kenvandine | nothing out of process | 14:55 |
| kenvandine | but maybe something like the thumbnailer could help us | 14:55 |
| kenvandine | i hadn't considered that | 14:55 |
| kenvandine | maybe we can generate thumpnails for icons in the container | 14:55 |
| jdstrand | why does QIcon::fromTheme not also need access to those icons? because it is guaranteed to be FromTheme? | 14:56 |
| jdstrand | if thumbnailing is fine, we can stop talking. I just am trying to understand why clicks get dbus marshalled data container apps don't. perhaps it all works for click because /usr/share/icons is guaranteed to not have user installed data but the container's /usr/share/icons does? | 14:58 |
| kenvandine | the clicks have paths to the files for the icon | 15:00 |
| kenvandine | so i can read those in as iconData and marshal it | 15:00 |
| kenvandine | so i don't use QIcon for that | 15:01 |
| kenvandine | jdstrand, but to get a themed icon i have to use QIcon which doesn't work as a non-gui service | 15:01 |
| kenvandine | i'll look into thumbnailer | 15:02 |
| jdstrand | oh I see. installed apps in the container don't have any sort of hooks so that you know what to marshal | 15:02 |
| kenvandine | right | 15:02 |
| kenvandine | just .desktop files with icon names | 15:02 |
| jdstrand | gotcha | 15:02 |
| jdstrand | kenvandine: keep in mind (and you probably realize this already), generating the thumbnails and giving access to all thumbnails in the directory is just pushing the problem. but seems creative use of the thumbnail service might be able to get you there | 15:03 |
| kenvandine | i was hoping we could provide access to that path since /usr/share/icons is accessible on the device | 15:03 |
| jdstrand | yeah | 15:04 |
| jdstrand | but those directories are managed differently unfortunately | 15:04 |
| kenvandine | but that just exposes the icons for what's installed on the device by default, users can't change that | 15:04 |
| jdstrand | oh right | 15:04 |
| jdstrand | you only waant the themed ones | 15:04 |
| kenvandine | yeah | 15:04 |
| jdstrand | yes, that's totally fine | 15:04 |
| kenvandine | same as in the container | 15:05 |
| jdstrand | kenvandine: perhaps add a comment somewhere strategic in the code so we don't forget why that's fine :) | 15:05 |
| kenvandine | so you're ok with @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons/* | 15:05 |
| kenvandine | right? | 15:05 |
| kenvandine | since it's just the themed icons? | 15:05 |
| jdstrand | ok, now I'm confused again | 15:06 |
| kenvandine | ok... nevermind | 15:06 |
| kenvandine | i think i was briefly confused by what you said :) | 15:06 |
| kenvandine | so it's fine to allow access on the default system | 15:06 |
| kenvandine | but not in the container | 15:06 |
| kenvandine | because they could deduce the delta | 15:06 |
| jdstrand | when I install via apt-get an application in the container, do icons get put in /usr/share/icons? my understanding is 'yes', so that is not an ok path | 15:06 |
| kenvandine | they get installed in /usr/share/icons of the container | 15:07 |
| kenvandine | which is something like @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons | 15:07 |
| jdstrand | 10:06 < kenvandine> so it's fine to allow access on the default system | 15:07 |
| jdstrand | yes | 15:07 |
| jdstrand | 10:06 < kenvandine> but not in the container | 15:07 |
| jdstrand | 10:06 < kenvandine> because they could deduce the delta | 15:07 |
| jdstrand | correct | 15:07 |
| kenvandine | ok, so i do need to look into the thumbnailer :) | 15:07 |
| kenvandine | for the themed icons | 15:07 |
| jdstrand | so, if you can tease out the system themed icons in @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons in some manner (eg, generate thumbnails of those and put them somewhere), that is fine | 15:08 |
| kenvandine | and i can add a rule to allow access to where those get cached | 15:09 |
| jdstrand | exactly | 15:09 |
| kenvandine | like ~/.cache/content-hub/icons/* | 15:09 |
| jdstrand | or use an existing path. whatever makes most sense | 15:09 |
| jdstrand | sure | 15:09 |
| jdstrand | perhaps it would make sense to use ~/.cache/content-hub/themed-icons/* | 15:10 |
| jdstrand | or something so that people understand that app icons won't go in there | 15:10 |
| kenvandine | jdstrand, noted | 15:12 |
| kenvandine | i hope the thumbnailer can do theme lookups | 15:12 |
| kenvandine | i bet it has the same problem... not a gui app | 15:13 |
| kenvandine | i'd hate to have to make the thumbnailer cache all the installed icons | 15:14 |
| jdstrand | I bet the thumbnailer will work fine | 15:19 |
| jdstrand | but, the trick will be can the app ask the thumbnailer for an icon that is an app icon and get a result | 15:19 |
| jdstrand | ie, it can enumerate apt-get installed apps by trial and error | 15:20 |
| jdstrand | kenvandine: ^ | 15:20 |
| kenvandine | no... | 15:20 |
| kenvandine | this would be done from the service side | 15:20 |
| kenvandine | which already has a list of installed apps in the container | 15:20 |
| kenvandine | in the peer list | 15:20 |
| kenvandine | for the peer picker | 15:20 |
| kenvandine | so the service side will need to hand a icon name for a themed icon to the thumbnailer to have it cache it | 15:21 |
| kenvandine | then our image provider in the qml (app) side could use that cached icon | 15:21 |
| kenvandine | if the thumbnailer can cache an icon with just a theme path and icon name | 15:21 |
| === vrruiz_ is now known as rvr | ||
| kenvandine | jdstrand, thumbnailer requires a path to the file, and if i could get that for the themed icon i could marshal the iconData like i do for the clicks :/ | 15:28 |
| kenvandine | jdstrand, back to exposing what's installed inside the container... any app with content_exchange will be able to see what apps are installed by requesting a peer list | 15:29 |
| kenvandine | so i don't think allowing access to @{HOME}/.cache/libertine-container/*/rootfs/usr/share/icons increases that exposure | 15:30 |
| jdstrand | kenvandine: I'm surprised by the peer list comment. that seems like maybe something that needs revisiting? either way, there is a difference though. with clicks apps opt into using content_exchange, ie, they want to be known to other apps. with apt-get in the container, there is no differentiation | 15:37 |
| jdstrand | that said, I thought one of the points of the content-hub was so that apps didn't know the other side | 15:38 |
| kenvandine | true... but it's a way to provide access to get content to those apps | 15:38 |
| kenvandine | they know the other side exists | 15:38 |
| kenvandine | but not direct access to their content | 15:38 |
| kenvandine | what we're doing is letting you do something like opening an image from the gallery in gimp | 15:38 |
| jdstrand | hrm, I thought that worked differently | 15:39 |
| kenvandine | so gallery shows a list of possible apps to send the content too | 15:39 |
| kenvandine | using the ContentPeerPicker component | 15:39 |
| jdstrand | like, user click share in the app, out of process helper whows user a list of choices, the user picks the choice, the out of process helper launches the choice, give the out of process helper the data which gives it to the app | 15:40 |
| kenvandine | the helper provides the list, but the component that shows the list is in the app's process | 15:40 |
| jdstrand | (so that is the reverse direction of what you are talking about, but rephrasing it for the other direction would be the same) | 15:40 |
| kenvandine | we've recently started talking about an out of process app for the picker that does an overlay | 15:40 |
| jdstrand | I think that is a problem | 15:41 |
| jdstrand | (not the overlay, the current display) | 15:41 |
| jdstrand | I thought the content picker used a tps like thing | 15:41 |
| kenvandine | there was plans for tps, but just to embed the other app inside the requesting app | 15:41 |
| kenvandine | not the peer picker itself | 15:42 |
| jdstrand | because, you are right-- there is no point in blocking access to /usr/share/icons in the container today if all of that is exposed in another way. but that shouldn't be exposed in any way | 15:42 |
| kenvandine | but we discussed that being tps too | 15:42 |
| kenvandine | bfiller, maybe we need to get the work for the out of process picker scheduled | 15:42 |
| * jdstrand doesn't care if it is tps or something else, but we are trying hard not to enumerate apps wherever possible | 15:42 | |
| kenvandine | bfiller, that we talked about back in austin | 15:43 |
| kenvandine | getting that out of process solves a bunch of these issues | 15:43 |
| kenvandine | jdstrand, so until we get that work done, can we add access to that icons dir for container apps? | 15:43 |
| kenvandine | that'll be a big task, and we need the container apps for pd | 15:44 |
| jdstrand | kenvandine: yes, but we need to file an appropriately prioritized bug for getting the other bits fixed | 15:44 |
| bfiller | kenvandine: out of process as in trust session right? | 15:47 |
| kenvandine | yeah, the overlay thing | 15:48 |
| kenvandine | we had talked about something that runs and fills the same space as the keyboard rectangle | 15:48 |
| kenvandine | bfiller, the tough thing is going to be deprecating the existing ContentPeerPicker that apps are using | 15:54 |
| kenvandine | actually, maybe we can just make ContentPeerModel private... so apps can only show peers inside our UI, not programatically list them | 15:55 |
| bfiller | kenvandine: yup, going to have to think about planning for this in upcoming sprint | 15:55 |
| kenvandine | i don't know of any apps using the model directly | 15:56 |
| kenvandine | it'll be tricky to do that... anyway, we need to start planning it | 15:57 |
| kenvandine | getting that out of process solves all of these themed icons problems i have :) | 15:57 |
| kenvandine | but it isn't a short term fix :) | 15:57 |
| === not_phunyguy is now known as phunyguy | ||
| === alan_g|lunch is now known as alan_g|EOD | ||
| shd_ | how do i find out what kills my "powerd-cli active" ? | 17:20 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| pdanek | Does Ubuntu phone have SElinux or apparmor running by default please? | 22:36 |
| jjohansen | pdanek: apparmor by default, and you can configure selinux and use that if you prefer | 22:36 |
| pdanek | jjohansen: thx | 22:37 |
| jjohansen | oh hrmm, actually you can't use selinux on the phone, that is for the desktop. Eventually you might be able to use it on the phone, but that would require work that has not been done | 22:37 |
| jjohansen | pdanek: ubuntu phone apps are very locked down | 22:38 |
| pdanek | makes sense | 22:39 |
| jjohansen | pdanek: https://developer.ubuntu.com/en/start/platform/guides/app-confinement/ | 22:41 |
| popey | i doubt we'll implement selinux | 22:42 |
| popey | we use apparmor | 22:42 |
| jjohansen | popey: right, at first I missed the phone bit, you can install selinux for the desktop, its more work and community supported | 22:44 |
| jjohansen | for the phone however, someone would have to do a lot of work | 22:44 |
| pdanek | Can Ubuntu Touch run Android apps already? | 22:50 |
| JanC | pdanek2: no (not yet, at least) | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!