[11:06] <sergiusens> Elleo: hey there, any workaround to cancel downloads for LP: #1654153 ?
[11:49] <Elleo> sergiusens: hadn't seen that before, will look into it when I've got a bit of time
[14:17] <yang> Any ETA on the next Ubuntu touch tablet after Aquaris M10 ?
[14:48] <thrasos> hello
[14:49] <thrasos> does anyone run touch on Sony Xperia?
[15:06] <OerHeks> thrasos, Z1 ? http://www.omgubuntu.co.uk/2016/02/ubuntu-phone-sony-xperia-oneplus-one
[15:08] <thrasos> OerHeks, m4 aqua
[15:09] <OerHeks> not in the list > https://wiki.ubuntu.com/Touch/Devices#Working_ports.2C_but_w.2Fo_system-image_server
[15:12] <thrasos> i see
[16:20] <mterry> tedg_: OK, jdstrand doesn't like the existing snap appid format -- wants UAL to use what snappy does (snap.NAME_COMMAND) rather than NAME_COMMAND_REVISION -- any objection to me whipping up a branch to do that? Are there issues in such a migration?
[16:24] <tedg_> mterry: Uhm, where is he concerned about it?
[16:24] <tedg_> We also really need the revision in there.
[16:25] <mterry> tedg_: https://github.com/snapcore/snapd/pull/2787#discussion_r101558251
[16:26] <tedg_> jdstrand: It's *everywhere* and very few people use the helper classes, so we couldn't change it in one place.
[16:27] <tedg_> jdstrand: Also, how does snapd guarantee that there aren't two revisions of a snap being run? There are three versions installed...
[16:27] <tedg_> jdstrand: There's only one if I say "right now what is the revision" but the app could be running while it is upgraded and would continue to run.
[16:30] <jdstrand> tedg_: snapd does manager that. please note, you and I won't solve this here unless you conform to snapd's snap name as I advised. anything short of that will need niemeyer and tvoss
[16:30] <jdstrand> manage*
[16:31] <tedg_> jdstrand: Okay, how does snapd manage that? Open files?
[16:31] <jdstrand> tedg_: it would continue to run, but that is a problem area that UAL could actually help with. you may have the revision all pretty, but the policy changed out from under it and it failed
[16:31] <jdstrand> fails
[16:31] <tedg_> jdstrand: Uhm, that would really suck?
[16:32] <jdstrand> there are open bugs on that. I don't think UAL should be trying to work around this because the snap won't run right anyway
[16:32] <jdstrand> tedg_: it does suck. ual could perhaps notice this and guide the user to restart (or restart automatically
[16:33] <jdstrand> iirc, android restarts apps. I'm not sure how well we could manage that. simple is tearing down all state and starting anew, but that isn't great for open files
[16:34] <jdstrand> so perhaps guiding the user to restart is the way to go (that said, depending on the file, it may not be saveable in the old location)
[16:35] <tedg_> Well it depends on if the application has lifecycle support, which things like X11 apps don't have.
[16:35] <tedg_> So we could handle it in *some* situations, but we can't kill apps.
[16:35] <tedg_> I mean, seriously, we lose someone's life's work in an editor because of an upgrade...
[16:36] <jdstrand> yes. let me get the bug
[16:36] <tedg_> There was no bug fix worth that.
[16:36] <tedg_> And, to be more clear, this is why we have revision in the appid :-)
[16:37] <jdstrand> tedg_: https://bugs.launchpad.net/snappy/+bug/1616650
[16:38] <tedg_> So to be clear, I think that changing from "_" to "." would be a PITA and cause bugs, but I don't really *care* as much as I'd like to avoid it. But I think dropping revision would cause real problems.
[16:38] <jdstrand> tedg_: some people use SNAP_USER_COMMON for everything to help
[16:38] <jdstrand> I don't think that is great
[16:39] <tedg_> I think that USER_COMMON would be used for user data.
[16:39] <tedg_> And then USER_DATA should be anything like caches and such.
[16:39] <jdstrand> there are other solutions-- we could make all revisions writable instead of only the current revision. that was NAKd in the past, but perhaps a new argument could revisit that
[16:40] <tedg_> Well, it seems like the lazy unmounting fixes part of the problem, as the files will still be there.
[16:40] <tedg_> It seems like we just need the apparmor policy to have the revision in it.
[16:40] <tedg_> And to make sure we have apparmor policy for every revision mounted.
[16:41] <jdstrand> tedg_: yeah, that is what people are doing I think, though, even with caches that is problematic cause you might have the dir location saved in memory and you just got there (as opposed to reevaluating SNAP_USER_DATA on every open)
[16:42] <jdstrand> tedg_: adding apparmor policy files for each revision could also work. that was NAKd and would have to be revisited
[16:42] <tedg_> jdstrand: Was it NAKd just for cleanliness?
[16:42] <jdstrand> tedg_: adjust the policy to not be revision specific is easy
[16:43] <jdstrand> tedg_: well, it is cleaner, sure, but it reduces a lot of complexity in nearly every way
[16:43] <tedg_> jdstrand: Well, it'll always be revision specific just because each revision could have different interfaces.
[16:44] <jdstrand> tedg_: you misunderatnd. I mean the default template could use .../@{SNAP_NAME}/** w, instead of .../@{SNAP_NAME}/@{SNAP_REVISION}/** w,
[16:44] <jdstrand> that way you can still write to your open files. it breaks if you had 'home' (or something) in one and then don't in the new revision
[16:44] <tedg_> jdstrand: Sure, I'm just saying that all the other stuff like networking might be in one revision but not the other.
[16:44] <tedg_> jdstrand: So if the wrong policy gets used the app would break.
[16:45] <jdstrand> it's a tricky prospect and needs design
[16:45] <tedg_> There is the case of files in the home directory as well, but lots of other stuff too.
[16:45] <jdstrand> it is also more than apparmor. seccomp is only done on app launch and not reloaded and applied at runtime
[16:46] <tedg_> Well, if we're worried about running apps, that works :-)
[16:46] <jdstrand> again, I'd love to see this fixed, but need to have the right people involved. everything said so far has been discussed and decided already
[16:46] <tedg_> jdstrand: So if my app, foo is running and a new version gets install that doesn't have the home interface. Does the running instance still have access?
[16:51] <jdstrand> tedg_: no
[16:51] <jdstrand> there is one profile. period
[16:51] <jdstrand> it gets reloaded
[16:51] <jdstrand> and the app has to deal
[16:51] <jdstrand> it would be possible to move the reload to snap-confine
[16:52] <jdstrand> ie, refresh updates the file on disk, and even generate the cache, but doesn't load it into the kernel
[16:52] <jdstrand> snap-confine could then be made to apparmor_parser -r it to load it into the kernel
[16:52] <jdstrand> this is something else that would need to be discussed and ACKd by an architect
[16:53] <jdstrand> this is probably only cli and not 'daemon' behavior. daemons are restarted so they don't suffer the same issues
[16:54] <jdstrand> so this adds complexity and the possibility of never loading the right profile
[16:56] <studio_> hi again ...
[17:01] <studio_> dobey, the bq e4.5 kernel 3.10.54 is public (https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5_2.x) . why isn't it used for the ubuntu-touch? Why it never was patched for UT?
[17:02] <jdstrand> tedg_: on the one hand, having apparmor_parser called be snap-confine for non-daemon commands fixes a number of issues, but we would want to be smart to not add another exec needlessly so as not to impact performance (eg, imagine a command that is called over and over again). that is where the complexity comes in
[17:02] <jdstrand> called by*
[17:02] <jdstrand> anyway, need to get the right people involved
[17:06] <tedg_> jdstrand: Sorry, my dad stopped by. Reading now.
[17:07] <studio_> what is the latest kernel for the latest "official" ubuntu-touch device?
[17:08] <tedg_> jdstrand: So I think we should file a bug about it, I don't think that bug 1616650 is the right place because that's more about file access. Thinking something about apparmor profiles makes more sense.
[17:09] <jdstrand> tedg_: well, the title is vague enough for really anything :P
[17:09] <jdstrand> 'may cause issues', hehe
[17:10] <tedg_> Don't use refresh on nuclear submarines ;-)
[17:12] <studio_> is there any info about latest kernels and "official" ubuntu-touch devices? If yes, where?
[17:14] <tedg_> jdstrand: So, in the meantime, can we stick with the appid format we have for starting to land the unity8 interface stuff?
[17:15] <tedg_> jdstrand: It seems like snapd shouldn't *really* care what things built on top of it do.
[17:15] <tedg_> jdstrand: It'd be nice to make it consistent, but shouldn't really matter. Other desktops are likely to invent their own identifiers as well.
[17:18] <jdstrand> tedg_: snapd shouldn't care, no, but you're contorting snapd mechanisms that will lead to confusion and that is impacting snapd code and security policy
[17:18] <jdstrand> tedg_: so it is a bit different
[17:18] <jdstrand> tedg_: if you want to change it, you need niemeyer and tvoss involved
[17:18] <studio_> brunch875, are you still there?
[17:18] <brunch875> studio_, always available for you!
[17:19] <tedg_> jdstrand: I guess I don't understand how we're impacting snapd code or policy in this case. I consider the unity8 interface a "unity8 thing" not a "snapd thing".
[17:20] <studio_> do you have any idea (before i get kicked again from this channel)?
[17:20] <jdstrand> tedg_: I'm talking from snapd's perspective, sorry. if you want snapd to have some notion of old-world AppIDs, that needs niemeyer and tvoss' involvement. I see problems there
[17:20] <tedg_> jdstrand: I do *want* that, but I'm willing to move forward without it and realize that is a bigger change. But my immediate concern is getting a working unity8 interface.
[17:21] <jdstrand> tedg_: please read my comment in the PR and feel free to coordinate a discussion on it. I'm sorry, I'm trying to honor the snappy way
[17:21] <brunch875> studio_, you mean, you wish to buy a new ubuntu phone with a recent kernel?
[17:21] <brunch875> studio_, I have my eye put on the fairphone 2, I believe it will be released soon
[17:22] <brunch875> it's not something canonical is pulling out officially, but it looks promising from a kernel perspective
[17:22] <studio_> brunch875, no, i do not understand why the new kernel was not patched for UT.
[17:22] <jdstrand> tedg_: I would accept a patch that stripped all of the old-wold AppID and had a DBus path glog rule with a TODO to unblock the interface. the interface is restricted in who can use it now, so that's fine
[17:22] <jdstrand> glob*
[17:22] <brunch875> studio_, that is the work of the phone manufacturer, there's little ubuntu can do
[17:23] <studio_> brunch875, the kernel was allways patched by Canonical, wasn't it?
[17:24] <tedg_> jdstrand: Okay, I think that makes sense to move forward until we can have the bigger conversation.
[17:24] <tedg_> mterry: ^
[17:25] <brunch875> studio_, Allow me to explain: phones are a bit different from computers. When you buy an android phone, it comes bundled with a specific kernel to control things such as the camera. When installing ubuntu, you put it on top of that.
[17:25] <studio_> https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5-ubuntu-master committed with john-mcaleely
[17:26] <brunch875> studio_, this more or less explains why you won't be seeing ubuntu touch installed on an iphone
[17:26] <studio_>  john-mcaleely is a member from Canonical, right?
[17:26] <OerHeks> studio_, again? dobey / popey answered that already, what answer satisfies you?
[17:27] <studio_> no, on no way. why was the first kernel modyfied by john-mcaleely and the second not?
[17:30] <brunch875> studio_, the short, simple question is stuff like the camera would stop working if the newest kernel was used
[17:31] <brunch875> or that's what I know with my little knowledge :p
[17:32] <studio_> brunch875, where did you get this info from?
[17:32] <studio_> info
[17:34] <brunch875> just a moment
[17:34] <tedg_> jdstrand: mterry: Okay, commented on the PR.
[17:35] <mterry> tedg_, jdstrand: I can do a glob rule to unblock, sure
[17:35] <brunch875> studio_, have a look at this picture: https://developer.ubuntu.com/static/devportal_uploaded/136981fa-6287-49d3-9874-06f40b2e4eb7-cms_page_media/380/ubuntu_touch_architecture.png
[17:35] <jdstrand> ok, cool
[17:36] <brunch875> studio_, the blue stuff is what the phone manufacturer has created, and it is "secret". Ubuntu cannot change that part
[17:36] <brunch875> studio_, the blue stuff was build for a specific kernel version. If you change the kernel version, the blue stuff stops working
[17:37] <brunch875> How would you do this then? Well, the manufacturer of the phone (which isn't ubuntu) has to change the blue pieces to work for a newer kernel
[17:38] <brunch875> That is why I mentioned the fairphone before; the fairphone manufacturers are a lot less secretive about the blue parts and so anyone can work on those :)
[17:38] <brunch875> and so upgrading the kernel is possible
[17:38] <studio_> brunch875, but that's for 14.04, wasn't it?
[17:38] <brunch875> that is for any ubuntu version, sadly :(
[17:39] <brunch875> ubuntu 15.10 is still just the orange part
[17:39] <brunch875> you need to change the blue part for a linux kernel upgrade
[17:39] <brunch875> and the manufacturer keeps that fixed, ubuntu can only change the orange things
[17:40] <studio_> so, "to port a new device" will never work for a new kernel, exp. krillin?
[17:41] <brunch875> yes, unless you find a manufacturer which helps with the blue parts
[17:41] <brunch875> if you change the blue section, you can use a newer kernel
[17:42] <studio_> so how can it be possible to port a new device?
[17:42] <brunch875> when you port a new device, you write the orange things
[17:42] <brunch875> but you cannot change the blue parts
[17:43] <brunch875> and this isn't just with ubuntu, it also happens if you try to write a new android
[17:43] <brunch875> or cyanogenmod
[17:43] <mterry> tedg_: did you file a bug?
[17:44] <brunch875> to change the blue parts, you need colaboration with the phone manufacturer.
[17:44] <tedg_> mterry: Trying to figure out how to phrase it...
[17:45] <mterry> tedg_: understood  :)   ping me when you have one so I can add to source comment
[17:55] <studio_> brunch875, what kernel is the fairphone 2 using?
[17:57] <brunch875> studio_, it hasn't been released yet, I do not know. But fairphone 2 has a lot more control over the drivers of the device which means upgrading the kernel should be no troubles
[17:57] <brunch875> In other words, probably the latest, all the time
[17:58] <brunch875> or at least that is what I hope!
[17:59] <brunch875> I also heard it is possible to install ubuntu touch on the fairphone 2
[17:59] <studio_> hmm, my Rasperry PI's are using 4.9.9+
[18:00] <popey> 17:26 < studio_>  john-mcaleely is a member from Canonical, right?
[18:00] <popey> was, isn't anymore
[18:00] <studio_> would be nice if there is same support for phone manufacors
[18:01] <brunch875> studio_, yes, we would all love if the phone manufacturers were more open
[18:02] <popey> studio_: the fairphone 2 port is a community maintained one. You're better off asking the UBPorts people as they did it.
[18:02] <studio_> in the moment i and some more feel "pranked" from the phone industry
[18:02] <brunch875> studio_, yes, the phone industry is :[
[18:03] <dobey> jfc
[18:05] <dobey> stop asking the same thing over and over and over
[18:06] <dobey> but yes, it would be nice if phone and chip manufacturers would open source the drivers and specs for their hardware
[18:06] <studio_> but, is there a different to canonical? Because, they tell they are open source, but where to find the sources?
[18:06] <brunch875> studio_, canonical would have to create the blue part
[18:06] <dobey> all of the drivers are not open source
[18:07] <brunch875> which means canonical would have to manufacture the phone
[18:07] <brunch875> there was a project called edge, but it failed
[18:08] <ogra_> well ... even if it had not failed ... it isntactually the *phone* manufaturers, but the *chip* manufacturers
[18:08] <studio_> brunch875, where can i find the latest kernel patches for the bq e4.5?
[18:08] <brunch875> studio_, they do not exist :)
[18:08] <popey> studio_: for what kernel version?
[18:08] <ogra_> so even the edge would likely have had to use closed bits because you wont find open drivers anywhere for certain sensors and chips a phone needs
[18:08] <studio_> hmm, i can see the kernel config on my phone
[18:09] <brunch875> ogra_, does this mean not even the fairphone can pull this stunt?
[18:09] <ogra_> brunch875, right
[18:09] <dobey> the tree for the kernel for the e4.5 was published on github
[18:09]  * brunch875 crawls to a corner to cry
[18:09] <ogra_> there is no open modem chop
[18:09] <ogra_> *chip
[18:09] <ogra_> for example
[18:10] <ogra_> so if you want your phone to be able to make calls ... you have to use a closed driver
[18:10] <ogra_> and the modem chip manufacturers have no reason to change that
[18:10] <studio_> dobey, but it was never patched for 3.10.54
[18:10] <ogra_> same goes for most GPS chips ... sensors ... etc
[18:11] <popey> studio_: correct, it's 3.4 isnt it?
[18:11] <dobey> well, it takes a concerted effort, and involving companies with enough market capitalization, to change that
[18:11] <dobey> studio_: no e4.5 ever shipped with ubuntu and the 3.10 kernel
[18:12] <studio_> popey, 3.4. xx, yes but also never patched to the latest kernel
[18:12]  * k1l_ thinks we already had the solution, that studio_ will pay the chip makers to hand out the  driver sources
[18:12] <ogra_> +1
[18:12] <popey> studio_: right, you know the answer, so stop asking
[18:13] <ogra_> k1l_, i like your pragmatism :)
[18:13] <brunch875> studio_, you need to convince the chip makers to give us drivers
[18:13] <brunch875> you're our only hope
[18:13] <brunch875> if ubuntu gets open drivers, we can patch the kernel!
[18:14] <dobey> brunch875: i think you're only making things more confusing
[18:14] <dobey> drivers being opened or closed is irrelevant to "patching the kernel"
[18:14] <studio_> brunch875, the conversation with you was constructive, as you can see, some people here are not so constructive ... :(
[18:15] <brunch875> dobey, that's true. I'm just painting really bold strokes :p
[18:16] <k1l_> mediatek doesnt have the best reputation for helping with drivers.
[18:16] <brunch875> studio_, I'm glad you see it can't be done until the chip manufacturers stop cheating us :[
[18:17] <dobey> studio_: true. you are very non-constructive
[18:17] <studio_> dobey, you are the best :)
[18:18] <dobey> if you want a newer kernel on your phone, then have at it. nobody stopping you from doing all the work. go hack at it to your hearts content
[18:20] <studio_> dobey, the problem is the phone-update-software from canonical, it do not understand, that the phone is using a newer kernel.
[18:20] <dobey> it doesn't care
[18:20] <ogra_> why would it
[18:20] <studio_> that's the problem
[18:20] <dobey> no it isn't
[18:20] <ogra_> it just unpacks tarballs
[18:20] <ogra_> no matter what is inside
[18:21] <dobey> set up your own system-image server and build your own device tarballs
[18:21] <dobey> nobody stopping you
[18:21] <ogra_> and put in whatever kernel you like
[18:22] <ogra_> or talk to the guys in #ubports on how to sideload your own kernel without a system-image server
[18:22] <studio_> you are ignorants, sorry
[18:22] <ogra_> they do that all the time when porting
[18:22] <dobey> studio_: goodbye then
[18:23] <studio_> dobey, feel free to leave
[18:23] <ogra_> studio_, you are claiming nonsense ... and we are ignorants ? the upgrade mechanism has absolutely nothing to do with the kernel version ..
[18:23] <ogra_> just roll your own and be happy with it
[18:23] <dobey> k1l_: ^^ i guess he isn't learning :(
[18:23] <k1l_> studio_: the point is: you are still demanding things that cant be done officially from canonical.
[18:23] <ogra_> as i said above, the guys in #ubports can tell you how to install it
[18:24] <studio_> ogra_, do you have any static how my users, with official UT-Devices, are happy with their devices?
[18:25] <k1l_> studio_: that has been told to you very very very often. you are free to change kernels and stuff as you want. but demanding it from ubuntu to do the work for you doesnt work. this will never change, so better forget about that "solution" and start thinking of doing that work yourself or create a team who does that.
[18:25] <studio_> many
[18:26] <studio_> k1l_, could you please constructive? before you kick somebody?
[18:28] <k1l_> studio_: its constructive. this has been answered several times to you. and the answer will not change, no matter how often you keep asking it or how much pressure you try to make with insulting others.
[18:28] <dobey> studio_: as has been said a thousand times over, it is your attitude that it is the problem here. you keep asking the same things repeatedly, because you don't like the answers, you resort to insults, and you are demanding people build things how you want them.
[18:30] <studio_> again, do you have a current statistic about users who are satisfied with their UT-Device?
[18:31]  * ogra_ is pretty happy with his device
[18:31] <studio_> and i do not mean the developers only
[18:31] <k1l_> studio_: in a perfect world everyone would be happy to ship the latest kernel on open source ubuntu smartphones, that are dead cheap or even for free. but this is not the perfect world we live in. the technical issue have been explained in detail to you. there is no news on that and there wont be any. so there is no need on demanding things, either be happy as it is, or argue with the chipmakers to give you the driver sources or try to port another
[18:31] <ogra_> it makes calls, plays music, is usable as desktop ... etc etc
[18:31] <brunch875> I am also very happy with the e4.5!
[18:31] <k1l_> kernel on your own.
[18:31] <dobey> studio_: such a statistic is irrelevant. it's purely something you want to use as some sort of evidence to claim you are somehow right, and continue to insult ubuntu
[18:31] <ogra_> studio_, ?? its a developer device ...
[18:32] <dobey> studio_: if you don't like ubuntu, don't use it, and leave us alone
[18:32] <brunch875> studio_, you could try to flash android, but you'd still have the same kernel version problem
[18:33] <brunch875> this isn't an ubuntu thing, it can't be done
[18:33] <studio_> ogra_, what i am missing on your "etc", it can't handle video-calls nor sip-calls
[18:34] <ogra_> my hangouts definitely work ... i dont use SIP though
[18:34] <ogra_> my phone 100% fulfills my needs
[18:35] <studio_> ogra_, you are an developer, not a user
[18:35] <ogra_> using a device for developers
[18:35] <ogra_> nt for endusers
[18:35] <ogra_> so yeah ... 100% match i'd say
[18:35] <studio_> nt=nice try?
[18:36] <ogra_> *not
[18:38] <dobey> brunch875: well, you can get 3.10 with android apparently, but it's still only 3.10, and there's no specific noted advantage to having the newer kernel on that device
[18:38] <studio_> brunch875, sorry, i missed you answer, for the bq E4.5 you can try Lineage OS: http://www.htcmania.com/showthread.php?t=1162844
[18:38] <ogra_> happy trying then
[18:38] <ogra_> switch over any be happy
[18:39] <studio_> or the beta: http://www.htcmania.com/showthread.php?t=1279437
[18:40] <studio_> ogra_, the problem is, they can't handle sip calls as the 5.0 can do
[18:40] <dobey> now you're just spamming
[18:41] <ogra_> they ?
[18:41] <studio_> 6.x an 7.x
[18:41] <ogra_> who do you talk about ?
[18:41] <dobey> he's talking about android
[18:41] <dobey> this is not #android dear studio_
[18:41] <dobey> nor is it #lineageos
[18:41] <ogra_> ah
[18:42] <dobey> i'm pretty sure sip calls work fine there though
[18:42] <ogra_> i thought he meant people using ubuntu ...
[18:42] <dobey> well, at least, it worked fine on cyanogenmod 13 which is android 6
[18:42] <dobey> well, of course sip calls don't work in ubuntu. our dialer doesn't have sip support yet
[18:43] <studio_> yet ?
[18:43] <studio_> it never had
[18:43] <dobey> nobody said it ever did have
[18:44] <ogra_> nobody claimed it ever had
[18:44] <dobey> that is not what "yet" means
[18:44] <dobey>  it means it's certainly plausible/possible that a future version could have it
[18:44] <popey> mcphail: nice timing
[18:45] <dobey> especially if people were submitting patches to help get it enabled
[18:45] <mcphail> popey: ?
[18:45] <dobey> mcphail: your favorite cheek pinching puppet is here
[18:45] <studio_> so why the UT-Phone can't server basics like video- or sip-calls?
[18:45] <popey> studio_: because nobody has written that code yet
[18:45] <ogra_> basics ?
[18:45] <dobey> it can
[18:46] <mcphail> :) hi studio_ ! how's things?
[18:46] <dobey> google hangouts works
[18:46] <dobey> you can install other video/voice chat things and they will work
[18:46] <dobey> or should work
[18:46] <studio_> popey, don't you thing it's time for that?
[18:46] <ogra_> send patches
[18:46] <k1l_> studio_: its not basics to everyone. just because you demand it doesnt make it basics for erveryone. that is one of your misconceptions
[18:47] <ogra_> sourcs is on launchpad
[18:47] <ogra_> *source
[18:47] <dobey> migh have to crack open this tequila aged beer sooner than i thought
[18:47] <popey> studio_: no, i don't. I think the investment isn't worth it for the number of devices out there
[18:47] <ogra_> dobey, cheers
[18:47] <popey> studio_: if we had more devices in the pipeline, then maybe, yes.
[18:47]  * ogra_ looks for the glenvilet 
[18:47] <dobey> mmmm
[18:48] <ogra_> ah, only glenmorangie
[18:48] <dobey> also mmmm
[18:48] <studio_> k1l_, video and sip calls are basics since a long time, do you remember NOKIA?
[18:48]  * popey is not allowed any, doctors orders
[18:48]  * dobey goes to make a sip video call on his 3310
[18:48] <k1l_> studio_: you mean that company that went bust?
[18:49] <dobey> i don't think any of my nokia phones support sip/video calls natively
[18:49] <dobey> nor do my samsung phones
[18:50] <dobey> not sure that my htc does either
[18:50] <studio_> dobey, maybe a problem from your telcom
[18:50] <popey> last nokia i had was 10 years ago and it didn't do vidoe calling or sip out of the box
[18:50] <dobey> studio_: no, it's nothing to do with the provider
[18:51] <studio_> popey, never ied an e-series or n-series?
[18:51] <dobey> first phone i had that did sip was probably my pre
[18:51] <dobey> anyway
[18:51] <dobey> again, has nothing to do with ubuntu
[18:51] <popey> actually maybe it did, I never used it though
[18:51] <popey> n82
[18:52] <studio_> dobey, "ubuntu" can do sip calls
[18:52] <dobey> studio_: if you think a specific feature needs to be implemented in ubuntu, i'm sure you can contact canonical sales and offer to contract them to implement the feature you desire
[18:53] <studio_> as i said, "ubuntu" can do calls via sip
[18:53] <brunch875> that sounds like a fantastic idea
[18:53] <dobey> build a phone and contract canonical to provide ubuntu for it
[18:53] <dobey> studio_: then you don't have a problem. so stop whining
[18:56] <popey> ogra_: saw this and thought of you https://plus.google.com/u/0/+TerryMcNeil/posts/SgDQdUUbyPn
[18:56] <OerHeks> One option that i miss, is Cell-broadcast. ( message in case of local emergency)
[18:56] <studio_> dobey, sorry, please let me whining, i am the only person who is whining since you have no statistic about users who satisfied with th UT-Device ;)
[18:57] <brunch875> studio_, :(
[18:57] <studio_> brunch875, come on, let me joke a little bit ;)
[18:58] <brunch875> popey, right now I have a conflict of hunger, laughter and facepalm
[18:58] <OerHeks> shoot the troll, i am hungry too!
[19:00] <brunch875> this calls for returning home to fill my abdomen
[19:01] <dobey> studio_: i think you missed the memo, but jokes are humorous, not slanderous.
[19:07] <studio_> dobey, as i wrote, you and other missed something. you wasn't able since 2013 to make a statistic what do the users want an think about mobile devices
[19:08] <dobey> no, nothing was missed
[19:08] <dobey> you are trolling
[19:09] <dobey> you are making the assumption that the majority of purchasers are somehow grossly dissatisfied, and you wish to use such a statistic to make further derisive commentary
[19:09] <dobey> that much is clear
[19:09] <studio_> no i am not trolling
[19:09] <k1l_> studio_: the point is: you think that your demands are not only your demands but are for all users. this is a misconception.
[19:10] <dobey> and frankly, either way, the number is mostly irrelevant
[19:10] <k1l_> studio_: so try not to make it look like the ubuntu phones are rubbish and dont have any features just because its missing one you would like to have.
[19:11] <studio_> but maybe canonical was trolling with the name ubuntu for mobile devices, as many user thought it the same as their "ubuntu-device"
[19:11] <k1l_> because this will not motivate people to help you
[19:11] <dobey> if you think it is important because you personally are unhappy, then you are saying you wish we would just kill the project, and you want to use something else anyway; so really, you should just go use that something else and stop trolling in here
[19:11] <k1l_> studio_: again: dont say "users" when it means "studio_"
[19:12] <studio_> k1l_, are you blind?
[19:12] <dobey> there have indeed been other people who were expecting their phone to be a PC
[19:13] <dobey> however, we explained to them the differences, and guess what. they don't keep coming in here asking the same thing over and over again and demanding we make something specific differently to satisfy them personally, as you do
[19:17] <studio_> dobey, do a big favour for all users an declare in the UT-Sites, that UT is not Ubuntu because it is depending from Android and has nothing to do with Ubuntu!
[19:18] <dobey> no
[19:18] <dobey> it is ubuntu
[19:18] <dobey> your idea of what ubuntu is, does not make it not ubuntu
[19:18] <studio_> so you want kidding users?
[19:18] <dobey> no
[19:18] <dobey> only you
[19:19] <k1l_> i declare the buffett to be open
[19:19] <OerHeks> 🍴
[19:20] <studio_> dobey, you are kidding yourself! change your password with passwd
[19:20] <dobey> why would i do that
[19:21] <studio_> to show you, that you are kidding yourself
[19:22] <dobey> so some bug that you are obviously referring to, is me kidding myself, because ubuntu is "working toward a fully converged system" and it's not quite there yet?
[19:22] <dobey> i would rather suggest perhaps you might want to go read about logical fallacies
[19:22] <dobey> you're full of them :)
[19:23] <studio_> as i said, why are you trying to kidding customers if you do not try kidding youself?
[19:24] <OerHeks> look in the mirror, studio_ :-D
[19:24] <studio_> :)
[19:24] <dobey> you keep using that word
[19:24] <dobey> i do not think it means, what you think it means
[19:25] <dobey> repeating your rhetoric isn't going to change the facts
[19:25] <OerHeks> But i had a question before this: One option that i miss, is Cell-broadcast. ( message in case of local emergency) Is there any sign that this will be implented?
[19:26] <OerHeks> c/implemented
[19:26] <dobey> OerHeks: i have absolutely no idea how that actually works, so i wouldn't have the slightest of clue
[19:27] <dobey> OerHeks: i presume if it doesn't need extra binary blobs, it probably wouldn't be too terribly hard to implement though, for someone who knows what they're doing
[19:30] <OerHeks> dobey, in short: any gsm in an area can recieve a text message in case of an emergency, like the acid disaster in Oberhausen today > https://en.wikipedia.org/wiki/Cell_Broadcast
[19:31] <dobey> OerHeks: right. i meant on the technical level with reespect to the android layer and getting those bits over into the ubuntu side
[19:31] <dobey> OerHeks: the name itself is pretty self-descriptive :)
[19:31] <studio__> dobey, again, "fooling" clients is a bad commercial strategy. you have to figure out if they are happy with the product.
[19:31] <dobey> attente: again, your rhetoric doesn't change facts. nobody is fooling anyone
[19:31] <dobey> err
[19:31] <OerHeks> dobey, for android one needs to install an app > https://play.google.com/store/apps/details?id=com.digitata.cellbroadcast&hl=en
[19:31] <dobey> not attente
[19:32] <dobey> studio__: again, your rhetoric doesn't change facts. nobody is fooling anyone

[19:32] <dobey> OerHeks: didn't cyanogenmod support it natively?
[19:32] <k1l_> studio__: its not fooling customers.
[19:32] <studio__> so do you have a statisic about UT?
[19:33] <dobey> studio__: again, stop repeating questions you have already received answers to
[19:33] <dobey> i have one statistic; every ubuntu phone/tablet has sold out of stock repeatedly
[19:33] <studio__> dobey, stop trolling!
[19:33] <dobey> k1l_: can you just ban him again? this is not going anywhere, yet again
[19:34] <OerHeks> dobey, not sure, on this page it looks like it is standard http://harwinder.in/blog/2014/08/04/disabling-cell-broadcasts-cm-11-m8/
[19:34] <k1l_> studio__: and to be honest, this is a very aggressive claim. if you make such claims you should have evidence that is more than "i want that feature".
[19:34] <dobey> OerHeks: i know on my phone there are some options for getting amber alerts and stuff, and i have cm13 on it

[19:35] <studio__> no feature, jus an statistic
[19:35] <studio__> just
[19:35] <dobey> and you were told the figure you asked for, does not exist
[19:35] <k1l_> studio__: do you realize what you are doing now?
[19:35] <dobey> so drop it
[19:35] <OerHeks> settings > wireless network > cellbroadcast ?
[19:36] <k1l_> studio__: you insult others and make claims, that ubuntu and canonical is betraying customers, just because you want a statistic?
[19:36] <studio__> k1l_, i asked a simple question
[19:36] <dobey> OerHeks: settings -> more -> emergency broadcasts
[19:37] <dobey> OerHeks: and extrem, sever, and AMBER alerts
[19:37] <k1l_> studio__: this is the reason why your behaviour is not acceptable.
[19:37] <k1l_> studio__: no, dont make it look like "you are just asking a question"
[19:38] <dobey> a simple question, asked repeatedly and aggressively
[19:38] <k1l_> studio__: your behaviour is again very out of the line. and you are doing this on purpose.
[19:38] <studio__> k1l_, as i said/asked are you blind?
[19:38] <dobey> ...
[19:38] <OerHeks> dobey, ah nice. How would i ask for this serious app , on https://forums.ubports.com/category/2/general or https://forum.xda-developers.com/ubuntu-touch ??
[19:39] <OerHeks> might as well point to amber alert too.
[19:39] <dobey> OerHeks: i don't think it would be an app; but like i said, i don't know enough details on how to get the necessary bits from the modem on the android side, over into ubuntu, to pop notifications
[19:39] <OerHeks> dobey me too :-(
[19:39] <dobey> OerHeks: i would say file a bug against canonical-devices-system-image about there being no cell broadcast support in ubuntu
[19:39] <dobey> OerHeks: and then we can go from there
[19:40] <dobey> and countdown to a new thread on ubuntuusers.de (or whatever the domain is)
[19:41] <k1l_> well, he deleted his account there (or got it deleted, i dont know anymore :) )
[19:41] <OerHeks> dobey, thank you. I will take the time to write a complete clear bugreport against 'canonical-devices-system-image'
[19:42] <OerHeks> .. after diner that is :-D
[19:42] <dobey> k1l_: hah, nice
[19:42] <dobey> OerHeks: great
[19:44] <ogra_> popey, LOL !
[19:44] <ogra_> thats hilarious
[20:02] <popey> :)
[20:24] <mterry> jdstrand: why don't I just include both appId schemes in the interface for now?  Rather than a glob
[20:25] <mterry> I guess your intent is to avoid snapd having any code that refers to existing appids...
[21:16] <jdstrand> mterry: the two rules I am suggesting won't work with UAL, but (arguably) should. So I'd like to have those intended rules. The glob rules are fine for now, just want to make sure we document the issue with them
[21:17] <jdstrand> we document the problems with rules in the policy for auditors, researchers and ourselves
[21:31] <mterry> jdstrand: right, I was just saying that rather than using an insecure glob, we can just allow {touchAppID,snapAppID}
[21:32] <mterry> But I was guessing that you preferred a glob rather than encoding anything Touch in snapd  :P
[21:39] <jdstrand> mterry: actually, how about leave the suggest rules, then do @{SNAP_NAME}_* for the Touch glob
[21:39] <mterry> jdstrand: well has to be a dbus version of the name so we still need the ugly replacement
[21:40] <jdstrand> mterry: that would not be a security issue since the snaps are still isolated (even if it is less precise from UAL's point of view
[21:40] <jdstrand> there's a helper for that
[21:41] <jdstrand> mterry: interfaces/dbus/dbus.go SafePath. give it the snap name + '_'
[21:42] <mterry> jdstrand: sure -- yeah I use that now.  NAME_COMMAND_* is my preference (just glob the revision, which doesn't have a concept yet in snap profiles)
[21:42] <jdstrand> let me reread what you have. I thought you had *name*
[21:43] <mterry> jdstrand: sorry I meant I use SafePath now
[21:44] <jdstrand> mterry: right, ok. do the go version of fmt.Sprintf("%s*", dbus.SafePath(plug.Snap.Name() + '_'))
[21:45] <jdstrand> mterry: then you can remove the foobarbaz stuff
[21:45] <mterry> jdstrand: right but is there a reason not to do Name_Command?
[21:45] <mterry> or rather name_command_*
[21:45] <jdstrand> mterry: no, you could do that if you prefer
[21:46] <mterry> jdstrand: alright will change tomorrow
[21:46] <jdstrand> mterry: so, fix that, then drop the foobarbaz isolation comment, but leave the FIXME and 'does not provide isolation' comments
[21:46] <jdstrand> sorry
[21:47] <mterry> jdstrand: does this not provide isolation?
[21:47] <jdstrand> leave the FIXME but drop the 'does not provide isolation' comments
[21:47] <mterry> k
[21:47]  * jdstrand is multitasking poorly :)