[01:54] <nhaines> k1l_: the kernels used on the retail phones don't support systemd.
[01:55] <k1l_> cool, they are hating systemd too :)
[04:34] <scientes> k1l_, no
[04:35] <scientes> android is old kernel because of non-free drivers make it less flexible
[04:36] <scientes> k1l_, and most the systemd-hate comes from those that never learned the limits of the old ways, and yet feel that their workflows are forced to change
[04:36] <scientes> systemd still solves a huge number of technical problems
[06:05] <lotuspsychje> http://linux.softpedia.com/blog/libreoffice-document-viewer-2-0-app-officially-released-for-ubuntu-phones-497146.shtml
[06:05] <lotuspsychje> nice
[07:55] <dholbach> good morning
[09:25] <abeato> Laney, hi, I took a look at the gtk-3 dependency for plugins-bad, blame shows that the dependency changed from gtk-2 to gtk-3, so my guess is that forcing gtk-3 >= 3.15 was because that was the version the debian maintainer saw in his system... compiling with gtk-3.14 does not produce any issues
[09:25] <Laney> hi abeato
[09:25] <Laney> please file upstream then
[09:26] <abeato> Laney, sure, but meanwhile we could try to get the package built for the overlay
[09:28] <Laney> I said I would do it on Monday, that is today, so I will
[09:29] <Laney> Give me the bug link and I will reference it in the patch
[09:30] <abeato> Laney, ack, I'll create the bug
[09:44] <abeato> Laney, https://bugzilla.gnome.org/show_bug.cgi?id=759113
[09:44] <Laney> thx
[09:44] <abeato> thank you
[09:45] <Laney> abeato: wait, you mean in the package?
[09:45] <Laney> that should be @ debian then
[09:45] <abeato> hm, reporting it following this https://www.debian.org/doc/manuals/debian-bugs/ch2.en.html ?
[09:46] <Laney> abeato: I can probably just fix that directly
[09:46] <Laney> I have commit to the package
[09:46] <Laney> thought you meant a dependency in configure.ac
[09:47] <abeato> ah, cool
[09:47] <abeato> no, just in control
[09:50]  * abeato cancelling bug in gstreamer
[09:51] <Laney> cool
[13:30] <KidFuryV> hey im having problems
[13:31] <KidFuryV> someone help
[15:05] <sturmflut> Has anybody in here worked on bug 1471913 ("battery status is inaccurate") lately? Because I took some time to look at the code and I think that either the kernel is at fault and it's just a software bug, or there is a workaround for a possible hardware failure, but in total it should be solvable somehow
[15:20] <Sleep_Walker> is 15.10 supported for ubuntu-sdk?
[15:22] <dobey> to run ubuntu-sdk on, or to target for your phone app?
[15:22] <Sleep_Walker> to run ubuntu-sdk
[15:22] <dobey> afaik it is, yes
[15:23] <dobey> it's built for 15.10 in the PPA
[15:23] <Sleep_Walker> I have this error http://sprunge.us/EjVE
[15:24] <Sleep_Walker> sorry, I'm not much experienced with Ubuntu (and I'd love to create ubuntu-sdk for my distribution during this week)
[15:24] <Sleep_Walker> it may be something trivial
[15:25] <Sleep_Walker> in that case someone should update PPA description in https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa
[15:26] <dobey> #ubuntu-app-devel is probably a better place to ask about the sdk. but looks like you need to try to install the additional packages it's complaining about with apt-get, to find out what the complaints are really about
[15:28] <Sleep_Walker> I see
[15:28] <Sleep_Walker> thanks for both tips
[15:45] <mcphail> Sleep_Walker: that error is not normal
[15:58] <seb128> kenvandine, hey, just wondering, but the fact you can't share several images at the same time ... I guess it's a known issue/limitation? is that due to content-hub or bugs in the clients?
[16:04] <kenvandine> seb128, which clients?
[16:04] <kenvandine> the hub supports multiples
[16:05] <seb128> kenvandine, trying to send several images from gallery or camera to dekko or facebook
[16:06] <seb128> the share option is disabled in those when more than 1 image is selected
[16:06] <kenvandine> that would be the client side
[16:07] <kenvandine> they can request SingleSelection or MultiSelection in the transfer
[16:07] <kenvandine> MultiSelection is default
[16:07] <seb128> thanks
[16:08] <kenvandine> np
[16:17] <Laney> abeato: ok to disable the gstglsink right?
[16:17] <Laney> that's where the dependency comes from
[16:17] <abeato> Laney, indeed ;)
[16:17]  * Laney grepped configure.ac
[16:17] <Laney> cool
[16:17] <Laney> also, remind me which silo?
[16:17] <abeato> Laney, 41
[16:17] <Laney> merci
[16:18] <abeato> tha
[16:33] <seb128> kenvandine, opened bug #1523573, indeed it works fine, they just have an " enabled: model.selectedFiles.length <= 1" for some reason, if I remove it sharing multiple image works
[16:35] <kenvandine> seb128, ah, thx
[16:35] <seb128> kenvandine, yw!
[16:38] <Sleep_Walker> mcphail: I can see that ubuntu-sdk really requires those packages so if you say that the error is not normal, can I take it that those packages are generally available either in official repositories or ubuntu-sdk ppa?
[16:43] <mcphail> Sleep_Walker: I'm not sure why you are having that problem. Did you "apt-get update" after adding the PPA? I have installed the standard repo SDK and the PPA SDK in 15.10 without problems
[16:44] <Sleep_Walker> mcphail: I have installed Ubuntu using debootstrap, installed some software like emacs, less etc, software-properties-common (to get apt-add-repository) and added PPA
[16:45] <Sleep_Walker> I can see ubuntu-sdk (so metadata were obtained), but I can't install required dependencies
[16:46] <mcphail> Sleep_Walker: I think I may have 2 PPAs added to my machine. I can check when I get home
[16:46] <Sleep_Walker> mcphail: you'd be very kind!
[16:47] <Sleep_Walker> root@ubuntu:/# bzgrep autopilot-desktop Packages.bz2
[16:47] <Sleep_Walker> Depends: autopilot-desktop, intltool, libcontent-hub-doc, phablet-tools, ubuntu-device-flash, ubuntu-sdk-ide
[16:47] <mcphail> Sleep_Walker: in the meantime, you could ask bzoltan_ in #ubuntu-app-devel. He pointed me in the right direction for the PPAs
[16:47] <Sleep_Walker> will do
[16:49] <mcphail> Sleep_Walker: and may be worth running "sudo apt-get install -f" to fix anything broken before trying another "sudo apt-get update && sudo apt-get install ubuntu-sdk"
[16:50] <mcphail> Sleep_Walker: oh - actually, you may need to run "sudo apt-get dist-upgrade" before installing the PPA SDK
[16:50] <Sleep_Walker> I don't think it is relevant for my case
[16:51] <Sleep_Walker> metadata shown that autopilot-desktop string is present only in 'Depends'
[16:51] <Sleep_Walker> (I tried anyway and didn't help)
[16:51] <Sleep_Walker> bbl
[17:52] <mterry> tedg, thanks for the ubuntu-app-launch review -- did it build OK for you?
[17:53] <mterry> tedg, specifically, the tests...  in a silo PPA, the handshake test never returned (false or true)
[17:53] <mterry> tedg, but I can't reproduce in sbuild or pbuilder
[17:53] <mterry> tedg, since you manage to make deja-dup tests break all the time, I wondered if you did the same here
[17:53] <mterry> (not that you are *causing* the breaks, you just reproduce them  ;))
[17:55] <tedg> mterry: Heh, I didn't try. I just read the diff, which seemed rather obvious now :-)
[17:55] <tedg> mterry: Let me see.
[17:56] <mterry> tedg, oh wait
[17:56] <mterry> tedg, I got my branches confused
[17:56] <mterry> tedg, there's no problem with that MP
[17:56] <mterry> tedg, I thought you had reviewed the warn-on-xapp one
[17:56] <tedg> mterry: Cool, FWIW they passed here too
[17:56] <mterry> tedg, yeah, the fix-ftbfs is diff-only-worthy  :)
[17:57] <tedg> mterry: So with the other one I haven't looked through all of it yet.
[17:57] <tedg> mterry: I really want to switch UAL to have a constant object though.... kinda curious if this is the breaking point.
[17:57] <mterry> tedg, yeah no rush, I wasn't trying to circuitously poke you about that one  :)
[17:58] <tedg> mterry: That whole signal has evolved to teh point where it looks like "blow up" might be the solution.
[17:58] <tedg> mterry: We didn't have any Unity side, but that caused a race, so then hacked on the unity side.
[17:59] <tedg> mterry: But, now we need it to do more...
[17:59] <mterry> tedg, yeah  :-/
[18:00] <mterry> tedg, my MP tried to be as undisruptive as possible, so I stuck with the current paradigm
[18:00] <mterry> But it does make it even more unwieldy
[18:01] <tedg> mterry: Yeah, and I appreciate your try to be less disruptive, but thinking reworking might be better.
[18:02] <tedg> mterry: So I've started a brain dump on that. And I'm gonna see if I can make it reasonable. I'll ping you for thoughts once I have something to show.
[18:02] <mterry> tedg, cool
[18:10] <mcphail> Sleep_Walker: my PPAs - http://paste.ubuntu.com/13795040/
[18:21] <mwenning> Hey guys, any advice on putting touch on a Nexus 5x?
[18:22] <dobey> mwenning: not possible yet
[18:23] <dobey> mwenning: anything that didn't ship with android 4.x originally is likely to be problematic for porting, for the time being
[18:24] <dobey> the existing nexus5 port isn't even complete, and has several unresolved issues (and it's not an officially supported port)
[18:25] <mwenning> dobey, thx, that helps with my xmas purchase decisions ;-)
[18:26] <dobey> the new nexus devices are all 64-bit too. we don't have a complete set of packages for the phone building on arm64 yet, either
[18:48] <mhall119> pmcgowan: bfiller: after a recent rc-proposed update, my Nexus 4 camera takes awful pictures and doesn't fill the screen with the live preview, what happened?
[18:48] <mhall119> I'm on rc-proposed/bq-aquaris.en r181
[18:49] <pmcgowan> we fixed the bq and mx?
[18:49] <mhall119> forgot the N4?
[18:49] <pmcgowan> there were several fixes so its possible
[18:49] <pmcgowan> though seems unlikely
[18:51] <pmcgowan> mhall119, actually those fixes not landed I am thinking of
[18:51] <pmcgowan> some changes landed thurs seem unlreated
[18:51] <mhall119> I think it started on the update before r181
[18:52] <pmcgowan> mhall119, friday update?
[18:53] <mhall119> I think so, I first noticed this yesterday
[18:53] <mhall119> but I didn't take any pictures between 11/26 and 12/06, so it could have been anytime in there
[18:55] <pmcgowan> actually let me check mine
[18:57] <pmcgowan> mhall119, there are changes to change the preview window to reflect the native resolution, there is a choice now in the bottom panel
[18:58] <pmcgowan> but quality should be good
[19:00] <pmcgowan> image quality does seem kinda poort but havent used this for a while
[19:01] <mhall119> pmcgowan: image quality on the N4 has always been poor, but it's so bad now you can't even read text on a close-up picture because it's so pixelated
[19:02] <mhall119> the saved image quality is actually *worse* than the preview quality
[19:03] <pmcgowan> yeah we need florian to explain, I'd suggest file it
[19:04] <davmor2> mhall119: look we understand that you are not happy unless you are complaining about something on the phone and pmcgowan just wanted to make you happy ;)
[19:04] <mhall119> heh, yeah, picture resolution is terrible now
[19:04] <mhall119> image20151206_124359627.jpg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=8], baseline, precision 8, 176x144, frames 3
[19:04] <pmcgowan> maybe when the device tarball lands it gets better again
[19:05] <mhall119> davmor2: but I haven't *stopped* complaining about lack of HUD yet
[19:05] <pmcgowan> davmor2, you see what  I was doin there :)
[19:06] <davmor2> pmcgowan: I know you, your all heart, I can't not see you wanting to make mhall119 happy, tis the season and all that
[19:07] <davmor2> pmcgowan: mhall119: I think this is the train issue where only part of the new system got uploaded right
[19:07] <mhall119> pmcgowan can make me happy by upgrading me to a Meizu
[19:09] <pmcgowan> or hold out for "whats next" ;)
[19:09] <davmor2> mhall119: just hold off for a US based phone, come on you know that would make you happy ;)
[19:10] <mhall119> a US based phone would indeed make me happy, holding off not so much
[19:11] <dobey> working bluetooth, location, and reasonable battery usage on nexus5 would be nice too :)
[19:13] <bfiller> mhall119: you have a partial update, the app hasn't beenreleased yet but the backend has
[19:13] <bfiller> will be fixed today
[19:14] <pmcgowan> ah good
[19:16] <mhall119> thanks bfiller
[19:16] <mhall119> bfiller: pmcgowan: is this something we can catch with our test suite going forward?
[19:17] <pmcgowan> mhall119, I would say it was caught, it was infra issue
[19:17] <bfiller> mhall119: it's a build system issue actually
[19:17] <mhall119> ah, ok
[19:17] <bfiller> mhall119: problems with xenial silos prevented us from releasing a new click for camera-app as changes weren't yet mreged into trunk
[19:18] <bfiller> pushing a new version right now in fact
[19:21] <bfiller> pmcgowan, sil2100: seems I can't upload the new camera to the store as 15.04.3 framework is not defined in the store yet
[19:21] <sil2100> bfiller: I'll define it, I usually do that when the stable image is being released
[19:21] <pmcgowan> hmm chicken egg
[19:21] <sil2100> I can do it now if it's useful
[19:21] <bfiller> pmcgowan, sil2100 : not sure how to get it into the nightly build without putting it into the store
[19:21] <pmcgowan> this is where we need the beta store thing
[19:21] <bfiller> sil2100: unless there is another way to get it into the rc-proposed image
[19:22] <sil2100> hmmm... hm hm hmmmmm
[19:22] <sil2100> Not without hacking
[19:22] <bfiller> sil2100: lets add the new fw to the store then
[19:22] <sil2100> bfiller: let me do it once after the meeting
[19:22] <dobey> hmm
[19:22] <bfiller> sil2100: sounds good, ty
[19:23] <sil2100> pmcgowan: it should be fine to add it without the stable image being released, no stable image will be able to update to it until we do OTA-9
[19:23] <sil2100> Although it does seem a bit evil
[19:23] <dobey> pmcgowan: a "beta store" wouldn't help here
[19:24] <bfiller> sil2100: I think that's fine, it at least allows developers to upload stuff targeted at the next release
[19:24] <bfiller> and shouldn't affect users on stable
[19:24] <dobey> sil2100: well, ota8.5 will be the next stable image right? and it will thus need to have the .3 framework and camera app, because it has the back-end?
[19:25] <bfiller> dobey: no, ota8.5 does not have the .3 fw
[19:25] <sil2100> dobey: no, it won't
[19:25] <bfiller> only ota9 will
[19:25] <sil2100> dobey: ota-8.5 won't have a meta update
[19:27] <dobey> sil2100: but does it have the new camera back-end code, which causes the issues mhall119 is seeing?
[19:27] <sil2100> dobey: probably not, since I didn't copy any camera backend packages
[19:28] <dobey> oh ok
[20:04] <mattias_> Hi, I am trying to build my first cordova app for Ubuntu Touch running 15.10 and using the 15.04 or 15.10 SDK. But I am running in some issues. First, should I use the cordova command from the ppa (/usr/bin/cordova) or npm (/usr/local/bin)? Second, should I use the cordova platform code from github (cordova platform add https://github.com/apache/cordova-ubuntu) or use the default ubuntu? Both scenario's give me errors
[20:11] <dobey> you should use the sdk
[20:11] <dobey> also #ubuntu-app-devel for app devel questions please :)
[20:30] <sturmflut> tvoss: Ping
[20:30] <tvoss> sturmflut, o/
[20:32] <sturmflut> Hey! So, I played with the FM radio some more and I can actually initialize and tune it, and according to the signal strength indicator it receives something. TX is not implemented in our krillin kernels, neither is automatic station seek, and I still can't get pulseaudio to capture the FM signal.
[20:32] <tvoss> sturmflut, that's great, so when you say signal strength indicator, do you refer to the network indicator or to the driver's interface?
[20:33] <sturmflut> tvoss: The driver, it has a FM_IOCTL_GETRSSI ioctl
[20:34] <sturmflut> If I tune it to a known station the value is around -34 (probably dB), noise is at around -87
[20:34] <tvoss> sturmflut, hah, the joys of numbers :) okay, so we likely have to tinker around with the pulse audio routing
[20:35] <tvoss> sturmflut, what did you try thus far for pulse?
[20:36] <tvoss> sturmflut, for -34db, is that with the headphone plugged in?
[20:36] <sturmflut> "pactl set-source-port source.primary input-fm", "pactl set-sink-port sink.primary output-speaker" and then "pacat -r -d source.primary | pacat -p -d sink.primary". This works fine if I switch the input port to one of the microphones, but with "input-fm" it is always silent.
[20:37] <sturmflut> tvoss: -34 is with the headphones plugged in
[20:37] <tvoss> sturmflut, let me check something real quick
[20:41] <tvoss> sturmflut, did you try setting sink.primary to output-wired_head.whatever?
[20:42] <sturmflut> I think I did at some point, let me try again
[20:43] <tvoss> sturmflut, you also might have to adjust the volume of the source port
[20:50] <sturmflut> tvoss: according to "pactl list" the ports are set correctly, the volumes are at 100%, nothing is muted and if I just switch the source input over to a microphone it immediately works. I suspect the FM chip is still muted or the input switching is not correct. The FM chip has no connection to the audio part except its NF output, so I don't think it even "knows" if the sink port is set to headset or not.
[20:50] <sturmflut> I'll look at the kernel driver code about the muting, absolutely not sure about it
[20:54] <tvoss_> sturmflut, do you have your code available somewhere?
[20:54] <tvoss_> sturmflut, also: did you issue a SETVOL ioctl on the fm device manually?
[20:58] <tvoss_> sturmflut, if possible, it would be great if you could pastebin output from /system/bin/logcat
[21:02] <sturmflut> tvoss_: Yeah, I even do a GETVOL to check that it actually gets set. Just pushed the code to https://github.com/Sturmflut/mtkfmcli.git , naturally it's quite hacky and ugly. Let me add a short README
[21:02] <tvoss_> sturmflut, no need to :)
[21:03] <sturmflut> You need to make the image writeable and move firmware files around
[21:03] <tvoss_> sturmflut, yup, got that far :)
[21:04] <tvoss_> sturmflut, https://github.com/Sturmflut/mtkfmcli/blob/master/include/mtk_ioctl.h#L50 seems a typo
[21:05] <sturmflut> Don't think so, that's from the kernel code and works
[21:10] <sturmflut> tvoss_: I think the FM radio driver just writes log messages to the kernel ringbuffer
[21:15] <tvoss_> sturmflut, ack, that makes sense. I'm looking into the pulseaudio droid module and see what else I can dig up from the android user space sources on controlling the fm chipset
[21:15] <tvoss_> sturmflut, mind pinging me the link to the fm driver source you are lookint at?
[21:16] <sturmflut> tvoss_: https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5/mediatek/kernel/drivers/fmradio
[21:18] <sturmflut> tvoss_: There's an "aquaris-E4.5-ubuntu-master" branch, but I don't think it changes anything
[21:18] <tvoss_> sturmflut, nope, unlikely
[21:21] <tvoss_> sturmflut, the logs actually go to androids logging facilities, see https://github.com/bq/aquaris-E4.5/blob/34cf494bca625acad06274c3cba10aca148813c0/mediatek/kernel/drivers/fmradio/inc/fm_dbg.h
[21:40] <pdanek> Hey guys, is anyone in Ubuntu Touch team working on Android app runtime? Or the plan is to use Shashlik once it's done?
[21:44] <mcphail> pdanek: no idea what is on the roadmap, but I would guess it will be inevitable that some kind of emulation or shim layer will be developed. I'd rather we had X working on Mir before any android/surfaceflinger stuff, personally
[21:47] <dobey> there are no plans to provide running of android apps on ubuntu as part of the phone experience
[21:47] <pdanek> hmm
[21:48] <dobey> if you want to repackage an android app by using the android runtime, you are welcome to build an app doing so, but you need to package it all into your own app (and it require proprietary chrome afaik, which is not redistributable, so good luck) :)
[21:48] <mcphail> Someone is likely to come up with android-in-a-click (or -in-a-snap)
[21:49] <pdanek> dobey: well shashlik is KDE project which can run android apps natively on Linux
[21:49] <pdanek> perhaps similar as it is on Sailfish OS, except fully open source (Sailfish emulation is proprietary)
[21:50] <dobey> well, then maybe you can use that if it's open source, but it won't be a core part of the ubuntu phone system
[21:50] <dobey> i guess it's a project to do it on the plasma phone
[21:51] <dobey> the kde phone images
[21:52] <pdanek> dobey: that's fine, thanks for info!
[21:52] <mcphail> pdanek: to be honest, it would be a shame to regress to android apps. The dev experience on native Ubuntu touch is much better. No need to rely on horrible NDK layers etc
[21:52] <pdanek> I just wasn't sure if shashlik integration or other solution is in the roadmap
[21:52] <dobey> no, there is no intention to provide support for running android apps on ubuntu phone
[21:53] <pdanek> mcphail: well, everyone would regress, but sometimes people just want phone which they wanna use every day, as main device.... and without android apps, that will take long time to get all apps you need
[21:53] <pdanek> especially apps like internet banking will probably never get ported
[21:53] <dobey> i use my ubuntu phone every day
[21:54] <dobey> and heck, i don't even have bluetooth or location
[21:54] <pdanek> dobey: everyone has different expectations from phone
[21:54] <mcphail> pdanek: I don't disagree with you. That is a very pragmatic view. I still cling to the purist view ;)
[21:54] <dobey> pdanek: and expecting android apps to work well on non-android will only lead to disappointment :)
[21:55] <dobey> better to bug whatsapp to create a real ubuntu port :)
[21:56] <pdanek> dobey: if you need Uber taxi, or need app for public transport, or Hailo, or eBanking, or some chatting app which isn't ported to Ubuntu (Whatsapp, Line, WeeChat, Viber, I don't know honestly what's ported and what not)
[21:56] <pdanek> purist view is honorable, but sometimes people just want to get things done as easily and quickly as possible
[21:57] <pdanek> dobey: not necessarily, android apps work on Sailfish OS just fine...
[21:57] <pdanek> dobey: even games
[21:57] <pdanek> no disappointments
[21:58] <dobey> android apps on android were even disappointing to me. *shrug*
[21:58] <pdanek> dobey: of course I choose native app once it's available, or even a lot of apps are ported from Ubuntu Touch :) but if there is need, I just patch it with android app
[21:59] <dobey> really, if android apps are a requirement, then android is a requirement
[21:59] <pdanek> dobey: well, ya, everyone hates android apps, but better than nothing, if you know what I mean
[21:59] <dobey> well, you're allowed to have an opinion which differs from others :)
[21:59] <pdanek> yep
[22:00] <dobey> android's security model is fundamentally opposed to the security model of ubuntu though. they don't mix, so even if you could run android apps, it wouldn't be a feasible option in general
[22:01] <pdanek> dobey: I agree
[22:01] <pdanek> same as on Sailfish, it's an option
[22:02] <pdanek> you can install the runtime layer if you want, as an option
[22:02] <dobey> no, not the same as sailfish. sailfish doesn't have ubuntu's security model
[22:02] <pdanek> but by default it's not installed
[22:02] <pdanek> oh, I know what you mean now
[22:02] <pdanek> Ubuntu is trying to containerize the apps, isn't it?
[22:02] <mcphail> dobey: android apps would work, within their own "container" (be that click, snap or whatever) though
[22:02] <dobey> yes, apps are contained
[22:03] <pdanek> right
[22:03] <dobey> mcphail: some might work, others might "work", but it will be a poor experience for the apps that people are actually asking to be run on ubuntu
[22:04] <dobey> mcphail: they won't be able to run their background services, so they won't have working push notifications, incoming calls, etc… when contained on ubuntu
[22:04] <mcphail> dobey: if the android app provided a full launcher experience, they would work until a call came in or the screen went off
[22:05] <dobey> mcphail: exactly. they wouldn't be able to receive any messages in whatsapp unless whatsapp was actually running in the foreground
[22:06] <mcphail> dobey: yes. I'm not claiming it isn't very very broken. But it would allow android apps to share data/servicesw within their own container
[22:06] <dobey> mcphail: so it would not be particularly useful for the people who rely on communications through such services
[22:07] <dobey> mcphail: nobody is stopping anyone from building an app package that provides a runtime and just runs the android app, outside of the legal teams of the services in question of course :)
[22:07] <pdanek> understood
[22:07] <pdanek> so not really feasible experience
[22:07] <mcphail> dobey: there is just the tiny matter of a surfaceflinger-to-mir shim :)
[22:08] <pdanek> as on Sailfish, it's integrated including push notifications, runs perfectly fine in background  etc.
[22:08] <dobey> mcphail: emacs beckons you :)
[22:08] <mcphail> dobey: I've tried to write a mir client and it made my head explode :)
[22:22] <tvoss_> pdanek, so what's the incentive for developers to port their app, then?
[22:23] <tvoss_> mcphail, and it would actually be somewhat "easy" to implement the surface flinger (binder) itf on top of mir
[22:23] <mcphail> tvoss_: maybe, but certainly beyond my talents
[22:23] <tvoss_> mcphail, practice makes perfect :)
[22:23] <dobey> i don't know about perfect
[22:24] <mcphail> tvoss_: you haven't seen my code, it take it ;)
[22:24] <dobey> but baqnging one's head on the keyboard enough eventually results in code that compiles and appears to function ;)
[22:24] <dobey> something on rc-proposed is causing dash scrolling to be incredibly painful
[22:25] <pdanek> tvoss_: the incentive is to get the native app experience
[22:25] <pdanek> it's just better with Sailfish SDK than running Android app
[22:25] <dobey> there isn't an incentive
[22:25] <tvoss_> pdanek, well, you just claimed that the integration is good enough
[22:26] <tvoss_> dobey, true ;)
[22:26] <dobey> whatsapp isn't porting to sailfish
[22:26] <pdanek> tvoss_: well... true
[22:26] <pdanek> WhatsApp is being ported to Ubuntu Touch?
[22:26] <tvoss_> pdanek, define "better" from an app developer's perspective :)
[22:26] <dobey> there's only an incentive if the developer has to do the work directly to get the android version running on that platform
[22:26] <mcphail> A native whatsapp app wouldn't run in the background, either
[22:26] <dobey> pdanek: not yet
[22:26] <pdanek> dobey: I mean official port
[22:27] <pdanek> there is pretty good native WhatsApp app on Sailfish
[22:27] <dobey> pdanek: unofficial ports can't exist because it's not open source
[22:27] <dobey> no, there is no native whatsapp on sailfish
[22:27] <pdanek> dobey: they can, reverse engineer the protocol and use just the protocol
[22:27] <pdanek> dobey: yes, there is
[22:27] <dobey> there is an app that purports to enable you to use whatsapp, but whastapp actively block such apps and also actively ban anyone using them
[22:28] <tvoss_> pdanek, that's not production level quality, though :) and people are pretty picky about the stability of their messaging apps
[22:28] <pdanek> true
[22:28] <pdanek> and true about ban to use it too
[22:28] <dobey> you can't talk about native oficial whatsapp on ubuntu, and then go on claiming there is a native whatsapp on sailfish, when it's not official
[22:28] <pdanek> but people made whatsapp native app effort...
[22:28] <pdanek> and once it was banned... another people made another native port
[22:29] <dobey> you can use the same app on ubuntu too, if you want to get banned :)
[22:29] <pdanek> so there is definitely push towards native apps, even with android integration
[22:29] <pdanek> just an example
[22:29] <dobey> yes, the problem is that you just keep chasing the dragon you can never catch
[22:29] <pdanek> yes
[22:29] <dobey> some random developers pushing for native app because they keep writing software that whatsapp keeps banning, doesn't mean whatsapp is being pushed to create a native client
[22:29]  * mcphail thinks Ubuntu needs to sort out background apps and notifications rather than spending time porting android runtimes
[22:30] <dobey> people will use the official android client, and not ask whatsapp for a native client
[22:30] <pdanek> right
[22:30] <pdanek> but then
[22:30] <dobey> mcphail: notifications are pretty sorted. but yeah there needs to be background processing solved
[22:30] <pdanek> why Windows 10 Mobile is developing Android support?
[22:31] <tvoss_> mcphail, we will *not* figure out background apps in the general case, and notifications are working perfectly fine
[22:31] <dobey> pdanek: because microsoft has given up too
[22:31] <pdanek> so if Windows Phone tried and gave up
[22:31] <pdanek> why will Ubuntu succeed?
[22:31] <tvoss_> mcphail, we will enable selected background processing under controlled conditions, which is a different thing
[22:32] <mcphail> tvoss_: background apps will become an inevitablity, if convergence is ever going to work
[22:32] <tvoss_> mcphail, I suggest that you read the last mail thread, the lifecylce policy is different for desktop use-cases
[22:32] <tvoss_> mcphail, and it was always meant to be different :)
[22:33] <tvoss_> mcphail, also: s/background apps/occluded-apps/
[22:34] <mcphail> tvoss_: I'm not sure the frameworks are keeping up with the needs of users on the phone, though. Things like background sync are missing with no obvious roadmap
[22:35] <mcphail> tvoss_: and notifications are buggy (at least with dekko, which is the only one I use)
[22:35] <dobey> notifications in dekko are superfluous
[22:36] <tvoss_> mcphail, right, they are not real push notifications ;)
[22:37] <tvoss_> mcphail, also: I'm not sure battery power can keep up with a system that does not exercise lifecycle control ;)
[22:37] <mcphail> tvoss_: I'd accept android-level battery performance for more functionality...
[22:37] <dobey> it works fine
[22:38] <dobey> and it's not no lifecycle control
[22:38] <tvoss_> mcphail, sure, you personlly can also achieve that quite easily tbh
[22:38] <tvoss_> mcphail, sure, there are so many ways to escape the lifecycle trap on android :)
[22:39] <pdanek> thanks guys for answers earlier
[22:39] <tvoss_> mcphail, on purpose or not, due to bugs, see last uproar about facebook messenger
[22:39] <dobey> the whole "android sucks so lets be totalitarian about it" concept is tiring
[22:40] <tvoss_> dobey, no one said that actually, and we adopted quite a lot of the system :)
[22:40] <mcphail> tvoss_: The biggest thing I miss on Ubuntu is finding my photos magically appearing on my desktop when I log in. I can't see there is ever going to be a solution to that
[22:40] <dobey> of what system?
[22:40] <tvoss_> dobey, well, of android :)
[22:40] <mcphail> tvoss_: which is ironic, because Ubuntu one used to work well on android :)
[22:41] <dobey> that's exactly what you're saying now. "android has no lifecycle, which sucks, and we're afraid of battery usage, so we're going into complete lockdown in this"
[22:41] <dobey> we have none of the background proccessing support of android on ubuntu phones :)
[22:41] <tvoss_> dobey, it has a lifecycle, which is easy to escape and to get wrong. so instead, we started locked down and open up step by step
[22:42] <tvoss_> painful and probably slower than we would like to: certainly
[22:43] <mcphail> tvoss_: it is very frustrating when we have been waiting for nearly a year for a decision about a way to allow user apps to access an SD card, never mind run background processes
[22:44] <mcphail> tvoss_: as a user/hobby dev it does stretch my patience at times
[22:45] <tvoss_> mcphail, sure, I can see that. the sd card situation will be solved soon'ish, the background processing is not meant to be solved in the general case, though
[22:45] <tvoss_> but we have been to that conversation before .)
[22:45] <mcphail> indeed :)
[22:45] <tvoss_> mcphail, as a hobby dev, you are not limited by the lifecycle though!
[22:46] <tvoss_> mcphail, and I'm sure you know how to use tweakgeek and friends
[22:46] <dobey> yes, the lifecycle is limiting. tweakgeek is not a solution
[22:46] <mcphail> yes, but I'd like to upload functional apps to the store
[22:48] <dobey> anyway, rc-proposed seems to be not working very nicely, and i think it's time i went to pub
[22:48] <tvoss_> dobey, enjoy :)
[22:50] <mcphail> tvoss_: hope you don't think I'm being a moaner... I appreciate your tireless work!
[22:50] <tvoss_> mcphail, no worries, I can take quite some blame :)
[22:50] <tvoss_> mcphail, and it's perfectly fine to moan at times
[22:50] <mcphail> tvoss_: :)
[23:08]  * TheHorribleBear waits for a Ubuntu phone without MediaTek cpu