User1: User3 hey there, any workaround to cancel downloads for LP: #1654153 ?
User2: Launchpad bug 1654153 in podbird "Download in the background does not stop" [Undecided,New] https://launchpad.net/bugs/1654153
User3: User1 hadn't seen that before, will look into it when I've got a bit of time
User4: Any ETA on the next Ubuntu touch tablet after Aquaris M10 ?
User5: hello
User5: does anyone run touch on Sony Xperia?
User6: thrasos, Z1 ? http://www.omgubuntu.co.uk/2016/02/ubuntu-phone-sony-xperia-oneplus-one
User5: OerHeks, m4 aqua
User6: not in the list > https://wiki.ubuntu.com/Touch/Devices#Working_ports.2C_but_w.2Fo_system-image_server
User5: i see
User7: User8 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?
User8: User7 Uhm, where is he concerned about it?
User8: We also really need the revision in there.
User7: User8 https://github.com/snapcore/snapd/pull/2787#discussion_r101558251
User8: User9 It's *everywhere* and very few people use the helper classes, so we couldn't change it in one place.
User8: User9 Also, how does snapd guarantee that there aren't two revisions of a snap being run? There are three versions installed...
User8: User9 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.
User9: User8 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
User9: manage*
User8: User9 Okay, how does snapd manage that? Open files?
User9: User8 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
User9: fails
User8: User9 Uhm, that would really suck?
User9: 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
User9: User8 it does suck. ual could perhaps notice this and guide the user to restart (or restart automatically
User9: 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
User9: 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)
User8: Well it depends on if the application has lifecycle support, which things like X11 apps don't have.
User8: So we could handle it in *some* situations, but we can't kill apps.
User8: I mean, seriously, we lose someone's life's work in an editor because of an upgrade...
User9: yes. let me get the bug
User8: There was no bug fix worth that.
User8: And, to be more clear, this is why we have revision in the appid :-)
User9: User8 https://bugs.launchpad.net/snappy/+bug/1616650
User2: Ubuntu bug 1616650 in Snappy "snap refresh while command is running may cause issues" [Undecided,Expired]
User8: 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.
User9: User8 some people use SNAP_USER_COMMON for everything to help
User9: I don't think that is great
User8: I think that USER_COMMON would be used for user data.
User8: And then USER_DATA should be anything like caches and such.
User9: 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
User8: Well, it seems like the lazy unmounting fixes part of the problem, as the files will still be there.
User8: It seems like we just need the apparmor policy to have the revision in it.
User8: And to make sure we have apparmor policy for every revision mounted.
User9: User8 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)
User9: User8 adding apparmor policy files for each revision could also work. that was NAKd and would have to be revisited
User8: User9 Was it NAKd just for cleanliness?
User9: User8 adjust the policy to not be revision specific is easy
User9: User8 well, it is cleaner, sure, but it reduces a lot of complexity in nearly every way
User8: User9 Well, it'll always be revision specific just because each revision could have different interfaces.
User9: User8 you misunderatnd. I mean the default template could use .../@{SNAP_NAME}/** w, instead of .../@{SNAP_NAME}/@{SNAP_REVISION}/** w,
User9: 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
User8: User9 Sure, I'm just saying that all the other stuff like networking might be in one revision but not the other.
User8: User9 So if the wrong policy gets used the app would break.
User9: it's a tricky prospect and needs design
User8: There is the case of files in the home directory as well, but lots of other stuff too.
User9: it is also more than apparmor. seccomp is only done on app launch and not reloaded and applied at runtime
User8: Well, if we're worried about running apps, that works :-)
User9: 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
User8: User9 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?
User9: User8 no
User9: there is one profile. period
User9: it gets reloaded
User9: and the app has to deal
User9: it would be possible to move the reload to snap-confine
User9: ie, refresh updates the file on disk, and even generate the cache, but doesn't load it into the kernel
User9: snap-confine could then be made to apparmor_parser -r it to load it into the kernel
User9: this is something else that would need to be discussed and ACKd by an architect
User9: this is probably only cli and not 'daemon' behavior. daemons are restarted so they don't suffer the same issues
User9: so this adds complexity and the possibility of never loading the right profile
User10: hi again ...
User10: 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?
User9: User8 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
User9: called by*
User9: anyway, need to get the right people involved
User8: User9 Sorry, my dad stopped by. Reading now.
User10: what is the latest kernel for the latest "official" ubuntu-touch device?
User8: User9 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.
User2: bug 1616650 in Snappy "snap refresh while command is running may cause issues" [Undecided,Expired] https://launchpad.net/bugs/1616650
User9: User8 well, the title is vague enough for really anything :P
User9: 'may cause issues', hehe
User8: Don't use refresh on nuclear submarines ;-)
User10: is there any info about latest kernels and "official" ubuntu-touch devices? If yes, where?
User8: User9 So, in the meantime, can we stick with the appid format we have for starting to land the unity8 interface stuff?
User8: User9 It seems like snapd shouldn't *really* care what things built on top of it do.
User8: User9 It'd be nice to make it consistent, but shouldn't really matter. Other desktops are likely to invent their own identifiers as well.
User9: User8 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
User9: User8 so it is a bit different
User9: User8 if you want to change it, you need niemeyer and tvoss involved
User10: brunch875, are you still there?
User11: studio_, always available for you!
User8: User9 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".
User10: do you have any idea (before i get kicked again from this channel)?
User9: User8 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
User8: User9 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.
User9: User8 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
User11: studio_, you mean, you wish to buy a new ubuntu phone with a recent kernel?
User11: studio_, I have my eye put on the fairphone 2, I believe it will be released soon
User11: it's not something canonical is pulling out officially, but it looks promising from a kernel perspective
User10: brunch875, no, i do not understand why the new kernel was not patched for UT.
User9: User8 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
User9: glob*
User11: studio_, that is the work of the phone manufacturer, there's little ubuntu can do
User10: brunch875, the kernel was allways patched by Canonical, wasn't it?
User8: User9 Okay, I think that makes sense to move forward until we can have the bigger conversation.
User8: User7 ^
User11: 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.
User10: https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5-ubuntu-master committed with john-mcaleely
User11: studio_, this more or less explains why you won't be seeing ubuntu touch installed on an iphone
User10: john-mcaleely is a member from Canonical, right?
User6: studio_, again? dobey / popey answered that already, what answer satisfies you?
User10: no, on no way. why was the first kernel modyfied by john-mcaleely and the second not?
User11: studio_, the short, simple question is stuff like the camera would stop working if the newest kernel was used
User11: or that's what I know with my little knowledge :p
User10: brunch875, where did you get this info from?
User10: info
User11: just a moment
User8: User9 User7 Okay, commented on the PR.
User7: tedg_, User9 I can do a glob rule to unblock, sure
User11: 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
User9: ok, cool
User11: studio_, the blue stuff is what the phone manufacturer has created, and it is "secret". Ubuntu cannot change that part
User11: studio_, the blue stuff was build for a specific kernel version. If you change the kernel version, the blue stuff stops working
User11: 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
User11: 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 :)
User11: and so upgrading the kernel is possible
User10: brunch875, but that's for 14.04, wasn't it?
User11: that is for any ubuntu version, sadly :(
User11: ubuntu 15.10 is still just the orange part
User11: you need to change the blue part for a linux kernel upgrade
User11: and the manufacturer keeps that fixed, ubuntu can only change the orange things
User10: so, "to port a new device" will never work for a new kernel, exp. krillin?
User11: yes, unless you find a manufacturer which helps with the blue parts
User11: if you change the blue section, you can use a newer kernel
User10: so how can it be possible to port a new device?
User11: when you port a new device, you write the orange things
User11: but you cannot change the blue parts
User11: and this isn't just with ubuntu, it also happens if you try to write a new android
User11: or cyanogenmod
User7: User8 did you file a bug?
User11: to change the blue parts, you need colaboration with the phone manufacturer.
User8: User7 Trying to figure out how to phrase it...
User7: User8 understood  :)   ping me when you have one so I can add to source comment
User10: brunch875, what kernel is the fairphone 2 using?
User11: 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
User11: In other words, probably the latest, all the time
User11: or at least that is what I hope!
User11: I also heard it is possible to install ubuntu touch on the fairphone 2
User10: hmm, my Rasperry PI's are using 4.9.9+
User12: 17:26 < studio_>  john-mcaleely is a member from Canonical, right?
User12: was, isn't anymore
User10: would be nice if there is same support for phone manufacors
User11: studio_, yes, we would all love if the phone manufacturers were more open
User12: User10 the fairphone 2 port is a community maintained one. You're better off asking the UBPorts people as they did it.
User10: in the moment i and some more feel "pranked" from the phone industry
User11: studio_, yes, the phone industry is :[
User13: jfc
User13: stop asking the same thing over and over and over
User13: but yes, it would be nice if phone and chip manufacturers would open source the drivers and specs for their hardware
User10: but, is there a different to canonical? Because, they tell they are open source, but where to find the sources?
User11: studio_, canonical would have to create the blue part
User13: all of the drivers are not open source
User11: which means canonical would have to manufacture the phone
User11: there was a project called edge, but it failed
User14: well ... even if it had not failed ... it isntactually the *phone* manufaturers, but the *chip* manufacturers
User10: brunch875, where can i find the latest kernel patches for the bq e4.5?
User11: studio_, they do not exist :)
User12: User10 for what kernel version?
User14: 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
User10: hmm, i can see the kernel config on my phone
User11: ogra_, does this mean not even the fairphone can pull this stunt?
User14: brunch875, right
User13: the tree for the kernel for the e4.5 was published on github
 * brunch875 crawls to a corner to cry
User14: there is no open modem chop
User14: *chip
User14: for example
User14: so if you want your phone to be able to make calls ... you have to use a closed driver
User14: and the modem chip manufacturers have no reason to change that
User10: dobey, but it was never patched for 3.10.54
User14: same goes for most GPS chips ... sensors ... etc
User12: User10 correct, it's 3.4 isnt it?
User13: well, it takes a concerted effort, and involving companies with enough market capitalization, to change that
User13: User10 no e4.5 ever shipped with ubuntu and the 3.10 kernel
User10: popey, 3.4. xx, yes but also never patched to the latest kernel
 * k1l_ thinks we already had the solution, that studio_ will pay the chip makers to hand out the  driver sources
User14: +1
User12: User10 right, you know the answer, so stop asking
User14: k1l_, i like your pragmatism :)
User11: studio_, you need to convince the chip makers to give us drivers
User11: you're our only hope
User11: if ubuntu gets open drivers, we can patch the kernel!
User13: User11 i think you're only making things more confusing
User13: drivers being opened or closed is irrelevant to "patching the kernel"
User10: brunch875, the conversation with you was constructive, as you can see, some people here are not so constructive ... :(
User11: dobey, that's true. I'm just painting really bold strokes :p
User15: mediatek doesnt have the best reputation for helping with drivers.
User11: studio_, I'm glad you see it can't be done until the chip manufacturers stop cheating us :[
User13: User10 true. you are very non-constructive
User10: dobey, you are the best :)
User13: if you want a newer kernel on your phone, then tina40@example.net. nobody stopping you from doing all the work. go hack at it to your hearts content
User10: dobey, the problem is the phone-update-software from canonical, it do not understand, that the phone is using a newer kernel.
User13: it doesn't care
User14: why would it
User10: that's the problem
User13: no it isn't
User14: it just unpacks tarballs
User14: no matter what is inside
User13: set up your own system-image server and build your own device tarballs
User13: nobody stopping you
User14: and put in whatever kernel you like
User14: or talk to the guys in #ubports on how to sideload your own kernel without a system-image server
User10: you are ignorants, sorry
User14: they do that all the time when porting
User13: User10 goodbye then
User10: dobey, feel free to leave
User14: studio_, you are claiming nonsense ... and we are ignorants ? the upgrade mechanism has absolutely nothing to do with the kernel version ..
User14: just roll your own and be happy with it
User13: User15 ^^ i guess he isn't learning :(
User15: User10 the point is: you are still demanding things that cant be done officially from canonical.
User14: as i said above, the guys in #ubports can tell you how to install it
User10: ogra_, do you have any static how my users, with official UT-Devices, are happy with their devices?
User15: User10 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.
User10: many
User10: k1l_, could you please constructive? before you kick somebody?
User15: User10 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.
User13: User10 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.
User10: again, do you have a current statistic about users who are satisfied with their UT-Device?
 * ogra_ is pretty happy with his device
User10: and i do not mean the developers only
User15: User10 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
User14: it makes calls, plays music, is usable as desktop ... etc etc
User11: I am also very happy with the e4.5!
User15: kernel on your own.
User13: User10 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
User14: studio_, ?? its a developer device ...
User13: User10 if you don't like ubuntu, don't use it, and leave us alone
User11: studio_, you could try to flash android, but you'd still have the same kernel version problem
User11: this isn't an ubuntu thing, it can't be done
User10: ogra_, what i am missing on your "etc", it can't handle video-calls nor sip-calls
User14: my hangouts definitely work ... i dont use SIP though
User14: my phone 100% fulfills my needs
User10: ogra_, you are an developer, not a user
User14: using a device for developers
User14: nt for endusers
User14: so yeah ... 100% match i'd say
User10: nt=nice try?
User14: *not
User13: User11 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
User10: brunch875, sorry, i missed you answer, for the bq E4.5 you can try Lineage OS: http://www.htcmania.com/showthread.php?t=1162844
User14: happy trying then
User14: switch over any be happy
User10: or the beta: http://www.htcmania.com/showthread.php?t=1279437
User10: ogra_, the problem is, they can't handle sip calls as the 5.0 can do
User13: now you're just spamming
User14: they ?
User10: 6.x an 7.x
User14: who do you talk about ?
User13: he's talking about android
User13: this is not #android dear studio_
User13: nor is it #lineageos
User14: ah
User13: i'm pretty sure sip calls work fine there though
User14: i thought he meant people using ubuntu ...
User13: well, at least, it worked fine on cyanogenmod 13 which is android 6
User13: well, of course sip calls don't work in ubuntu. our dialer doesn't have sip support yet
User10: yet ?
User10: it never had
User13: nobody said it ever did have
User14: nobody claimed it ever had
User13: that is not what "yet" means
User13: it means it's certainly plausible/possible that a future version could have it
User12: User16 nice timing
User13: especially if people were submitting patches to help get it enabled
User16: User12 ?
User13: User16 your favorite cheek pinching puppet is here
User10: so why the UT-Phone can't server basics like video- or sip-calls?
User12: User10 because nobody has written that code yet
User14: basics ?
User13: it can
User16: :) hi studio_ ! how's things?
User13: google hangouts works
User13: you can install other video/voice chat things and they will work
User13: or should work
User10: popey, don't you thing it's time for that?
User14: send patches
User15: User10 its not basics to everyone. just because you demand it doesnt make it basics for erveryone. that is one of your misconceptions
User14: sourcs is on launchpad
User14: *source
User13: migh have to crack open this tequila aged beer sooner than i thought
User12: User10 no, i don't. I think the investment isn't worth it for the number of devices out there
User14: dobey, cheers
User12: User10 if we had more devices in the pipeline, then maybe, yes.
 * ogra_ looks for the glenvilet
User13: mmmm
User14: ah, only glenmorangie
User13: also mmmm
User10: k1l_, video and sip calls are basics since a long time, do you remember NOKIA?
 * popey is not allowed any, doctors orders
 * dobey goes to make a sip video call on his 3310
User15: User10 you mean that company that went bust?
User13: i don't think any of my nokia phones support sip/video calls natively
User13: nor do my samsung phones
User13: not sure that my htc does either
User10: dobey, maybe a problem from your telcom
User12: last nokia i had was 10 years ago and it didn't do vidoe calling or sip out of the box
User13: User10 no, it's nothing to do with the provider
User10: popey, never ied an e-series or n-series?
User13: first phone i had that did sip was probably my pre
User13: anyway
User13: again, has nothing to do with ubuntu
User12: actually maybe it did, I never used it though
User12: n82
User10: dobey, "ubuntu" can do sip calls
User13: User10 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
User10: as i said, "ubuntu" can do calls via sip
User11: that sounds like a fantastic idea
User13: build a phone and contract canonical to provide ubuntu for it
User13: User10 then you don't have a problem. so stop whining
User12: User14 saw this and thought of you https://plus.google.com/u/0/+TerryMcNeil/posts/SgDQdUUbyPn
User6: One option that i miss, is Cell-broadcast. ( message in case of local emergency)
User10: 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 ;)
User11: studio_, :(
User10: brunch875, come on, let me joke a little bit ;)
User11: popey, right now I have a conflict of hunger, laughter and facepalm
User6: shoot the troll, i am hungry too!
User11: this calls for returning home to fill my abdomen
User13: User10 i think you missed the memo, but jokes are humorous, not slanderous.
User10: 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
User13: no, nothing was missed
User13: you are trolling
User13: 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
User13: that much is clear
User10: no i am not trolling
User15: User10 the point is: you think that your demands are not only your demands but are for all users. this is a misconception.
User13: and frankly, either way, the number is mostly irrelevant
User15: User10 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.
User10: but maybe canonical was trolling with the name ubuntu for mobile devices, as many user thought it the same as their "ubuntu-device"
User15: because this will not motivate people to help you
User13: 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
User15: User10 again: dont say "users" when it means "studio_"
User10: k1l_, are you blind?
User13: there have indeed been other people who were expecting their phone to be a PC
User13: 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
User10: 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!
User13: no
User13: it is ubuntu
User13: your idea of what ubuntu is, does not make it not ubuntu
User10: so you want kidding users?
User13: no
User13: only you
User15: i declare the buffett to be open
User6: ð´
User10: dobey, you are kidding yourself! change your password with passwd
User13: why would i do that
User10: to show you, that you are kidding yourself
User13: 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?
User13: i would rather suggest perhaps you might want to go read about logical fallacies
User13: you're full of them :)
User10: as i said, why are you trying to kidding customers if you do not try kidding youself?
User6: look in the mirror, studio_ :-D
User10: :)
User13: you keep using that word
User13: i do not think it means, what you think it means
User13: repeating your rhetoric isn't going to change the facts
User6: 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?
User6: c/implemented
User13: User6 i have absolutely no idea how that actually works, so i wouldn't have the slightest of clue
User13: User6 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
User6: 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
User13: User6 right. i meant on the technical level with reespect to the android layer and getting those bits over into the ubuntu side
User13: User6 the name itself is pretty self-descriptive :)
User17: dobey, again, "fooling" clients is a bad commercial strategy. you have to figure out if they are happy with the product.
User13: attente: again, your rhetoric doesn't change facts. nobody is fooling anyone
User13: err
User6: dobey, for android one needs to install an app > https://play.google.com/store/apps/details?id=com.digitata.cellbroadcast&hl=en
User13: not attente
User13: User17 again, your rhetoric doesn't change facts. nobody is fooling anyone
User17: <dobey>
User13: User6 didn't cyanogenmod support it natively?
User15: User17 its not fooling customers.
User17: so do you have a statisic about UT?
User13: User17 again, stop repeating questions you have already received answers to
User13: i have one statistic; every ubuntu phone/tablet has sold out of stock repeatedly
User17: dobey, stop trolling!
User13: User15 can you just ban him again? this is not going anywhere, yet again
User6: 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/
User15: User17 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".
User13: User6 i know on my phone there are some options for getting amber alerts and stuff, and i have cm13 on it
User17: <k1l_>
User17: no feature, jus an statistic
User17: just
User13: and you were told the figure you asked for, does not exist
User15: User17 do you realize what you are doing now?
User13: so drop it
User6: settings > wireless network > cellbroadcast ?
User15: User17 you insult others and make claims, that ubuntu and canonical is betraying customers, just because you want a statistic?
User17: k1l_, i asked a simple question
User13: User6 settings -> more -> emergency broadcasts
User13: User6 and extrem, sever, and AMBER alerts
User15: User17 this is the reason why your behaviour is not acceptable.
User15: User17 no, dont make it look like "you are just asking a question"
User13: a simple question, asked repeatedly and aggressively
User15: User17 your behaviour is again very out of the line. and you are doing this on purpose.
User17: k1l_, as i said/asked are you blind?
User13: ...
User6: 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 ??
User6: might as well point to amber alert too.
User13: User6 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
User6: dobey me too :-(
User13: User6 i would say file a bug against canonical-devices-system-image about there being no cell broadcast support in ubuntu
User13: User6 and then we can go from there
User13: and countdown to a new thread on ubuntuusers.de (or whatever the domain is)
User15: well, he deleted his account there (or got it deleted, i dont know anymore :) )
User6: dobey, thank you. I will take the time to write a complete clear bugreport against 'canonical-devices-system-image'
User6: .. after diner that is :-D
User13: User15 hah, nice
User13: User6 great
User14: popey, LOL !
User14: thats hilarious
User12: :)
User7: User9 why don't I just include both appId schemes in the interface for now?  Rather than a glob
User7: I guess your intent is to avoid snapd having any code that refers to existing appids...
User9: User7 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
User9: we document the problems with rules in the policy for auditors, researchers and ourselves
User7: User9 right, I was just saying that rather than using an insecure glob, we can just allow {touchAppID,snapAppID}
User7: But I was guessing that you preferred a glob rather than encoding anything Touch in snapd  :P
User9: User7 actually, how about leave the suggest rules, then do @{SNAP_NAME}_* for the Touch glob
User7: User9 well has to be a dbus version of the name so we still need the ugly replacement
User9: User7 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
User9: there's a helper for that
User9: User7 interfaces/dbus/dbus.go SafePath. give it the snap name + '_'
User7: User9 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)
User9: let me reread what you have. I thought you had *name*
User7: User9 sorry I meant I use SafePath now
User9: User7 right, ok. do the go version of fmt.Sprintf("%s*", dbus.SafePath(plug.Snap.Name() + '_'))
User9: User7 then you can remove the foobarbaz stuff
User7: User9 right but is there a reason not to do Name_Command?
User7: or rather name_command_*
User9: User7 no, you could do that if you prefer
User7: User9 alright will change tomorrow
User9: User7 so, fix that, then drop the foobarbaz isolation comment, but leave the FIXME and 'does not provide isolation' comments
User9: sorry
User7: User9 does this not provide isolation?
User9: leave the FIXME but drop the 'does not provide isolation' comments
User7: k
 * jdstrand is multitasking poorly :)
ubuntu-touch
Ubuntu IRC