Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps

[Rodney Dawes]

On Wed, 2014-01-22 at 17:10 +, Colin Watson wrote:
> If you have any (non-bikeshed) concerns about this, please let me know
> before I get the landing ask for click 0.4.14 approved. :-)

How will we get a list of all the frameworks the system supports, for
apps to run on? We'll need to get the list of supported frameworks, when
querying the server for apps, in the click scope. We don't want to just
show all apps, and have the user install something which requires a
framework that isn't supported on the system, and then have the app not
work at all after installing, or fail to install after purchasing it, if
install will fail in this case.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] [PROPOSAL] No (click) apps on images by default

[Rodney Dawes]

On Wed, 2014-03-12 at 15:37 -0300, Sergio Schvezov wrote:
> - this opens the possibility of having a better set for phone and
> tablet (different customizations, preinstalled apps that is).

Are the apps where this actually matters currently, even packaged as
clicks? It doesn't seem like they are. Is that changing soon?



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Some bugs with click store.

[Rodney Dawes]

On Thu, 2014-03-13 at 16:38 +0400, Зонов Роман wrote:
> Both installed locally and fetched from the Internet. They appears in same 
> time.

Installed apps has nothing to do with the Internet. They take separate
paths in the code. It is however, possible, that something is causing
blocking in the process, which blocks the installed apps from being
shown prior to the available apps that come from the Internet.

This may be fixed when the new scopes land in the image in the next few
days, though.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing process, restoring "trunk" for development

[Rodney Dawes]

On Tue, 2014-04-08 at 12:31 -0300, Renato Filho wrote:
> This would cause confusion for the community it they want to
> contribute to the project, since the trunk is not up-to-date they will
> need to find which branch to use to start developing, otherwise they
> will get a lot of conflicts as soon as the blocked branches start to
> get merged.

This can be true, regardless of the landing process. If a lot of people
are contributing, it is very easy to end up with conflicts. The time it
takes to have approved MPs merged into trunk is irrelevant. I agree that
faster is certainly better, but it does not explicitly solve the issue
you mention here, to do so.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing process, restoring "trunk" for development

[Rodney Dawes]

On Tue, 2014-04-08 at 15:30 +0300, Alberto Mardegan wrote:
> In the last 5 minutes of the session, a solution was proposed: leaving
> "trunk" for development purpose (like it was before the CI train
> started) and push the landed commits into other branches, such as
> "trusty".

And what exactly would be landing commits to "trunk", or to "trusty"
there?

If all commits land in some branch that's not trunk, then trunk isn't
trunk, it is some thing that's behind the other branch in terms of
commits.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Tue, 2014-04-15 at 22:26 +0200, Christian Dywan wrote:
> Does this imply that the recommendation for .desktop files should also
> change? If scopes are slow to load with .mo files, wouldn't the same
> apply to .desktop files? Or maybe the question is what is "wrong" with
> scopes that they can't be as efficient as .desktop files?

I'm not quite sure what you're asking. The strings being in the .ini
or .desktop file directly is going to be faster than doing a bunch of
stat() calls on the disk, loading another binary file, finding the
translation index, grabbing the string, and finally showing it, when
we're already going to have to parse the .ini or .desktop files to get
the untranslated string, and the gettext domain, anyway. If the
translated strings are also in the same file, it's a lot less work that
has to be done, to get those translations into the UI. We would be
handling the .ini and .desktop files the same way.

Placing the gettext domain in the .desktop file is not part of the
FreeDesktop specification, anyway. It's just something that was done on
Ubuntu, to aid in the creation of translation packs. It was never "more
efficient" in terms of pure computing performance, to do it that way.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing app metadata

[Rodney Dawes]

On Tue, 2014-04-15 at 17:52 -0400, Chris Wayne wrote:


> 1) Do we have a plan for the legacy deb-packaged apps we have on the
> image (or do we just plan to get those as clicks ASAP?)

I'm not sure what the packaging plan is there, but as far as the click
scope is concerned, the .desktop is the only place we have to get
information about the apps which are packaged as debs (such as
webbrowser-app). We're currently pulling the title, description, and
screenshot URL, from the .desktop file. The scope currently doesn't pull
any translations for it, but it's not terribly hard for it to start
doing so. There are some other things that are actual regressions from
the old scopes API version of the scope, which we're trying to get fixed
first.
  
> 2) Would inline translations have any effect on the image size
> compared to having the translations in a .mo? (More specifically for
> the description bits as the question re: Names was already answered in
> the other thread)

Virtually no. As plain text, the .desktop file will compress extremely
well, unlike the .mo files. There may be a slight increase of a few
bytes, for a few apps, but I don't see it causing any issue with image
size.

> 3) Would this method use Launchpad's translations service, or would it
> need to be separate?

That is dependent on the app authors. If apps are hosted on Launchpad,
then I'm sure they might use the LP translations service. For the apps
we upstream, we will continue using the LP translations service, yes. I
see no need to not do that.

> 4) Do we anticipate saving all apps' metadata translations on disk, or
> just those that are pre-installed?

Only those that are installed. Whether they are pre-installed or not
doesn't matter. Apps that are in the store, but haven't been installed,
won't have any local data on the device (except for minor caching of
network responses, which will be a per-user store, and not stored in /
anywhere). Likewise, if a device has multiple users, we will need to
support the possibility that those users might use different languages,
and so will need to be able to translate to those languages when
offline, when such translations have been provided by the app authors.

However, while we want great translations for core apps, I think it's
also safe to expect that the vast majority of apps that end up in the
store in the future, are likely to have little to no translation
support; particularly for "changes" info added to descriptions when new
versions of an app are uploaded. Many developers don't have the skills
or time to do full and proper translation support for their apps. They
just want to make an app and sell it.




-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing app metadata

[Rodney Dawes]

On Wed, 2014-04-16 at 01:02 +0200, Michał Sawicz wrote:
> On 15.04.2014 21:40, David Planella wrote:
> > https://wiki.ubuntu.com/Touch/AppMetadataTranslations
> > 
> > Please click, scopes and store folks let me know if these are correct.
> 
> One thing missing there are static launcher quicklist actions, which are
> also stored in .desktop files.

Does Unity8 support those? Or will it in the future? If long-press on
the launcher is going to open the preview, then the quick list actions
aren't very quick. And I'm not sure we should be bother to parse all
those out and add custom actions to the launcher.

There's also other potential issues with confinement of apps and such, I
think. Do we have plans to deal with all those issues to continue
supporting quick lists in the converged Unity8 experience? Or is it
going to be a necessary loss in order to further the convergence story?



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing app metadata

[Rodney Dawes]

On Wed, 2014-04-16 at 11:40 +0800, James Henstridge wrote:
> On Wed, Apr 16, 2014 at 6:14 AM, Rodney Dawes
>  wrote:
> >> 2) Would inline translations have any effect on the image size
> >> compared to having the translations in a .mo? (More specifically for
> >> the description bits as the question re: Names was already answered in
> >> the other thread)
> >
> > Virtually no. As plain text, the .desktop file will compress extremely
> > well, unlike the .mo files. There may be a slight increase of a few
> > bytes, for a few apps, but I don't see it causing any issue with image
> > size.
> 
> I'm curious about this.  While .mo message catalogues are a binary
> fortmat, I would have thought the majority of their content would be
> text (the english and translated versions of each string).  I would
> have thought these would compress to a similar degree as plain text.

While the string portions of the .mo files will compress fairly well,
the rest of the file does not. It is still a binary file. There is a
fair bit of extra metadata in the .mo itself, and in the strings
section, which is not necessary to have in the .desktop files, as well.

What I really meant is that the packages that contain the .desktop files
will see only a small few bytes in change. The installed size will be a
little larger than that, but still not big enough that it should have a
real impact on the default image size, I don't think.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Wed, 2014-04-16 at 07:38 +0200, Martin Pitt wrote:
> It's not all that obvious really. You only pay the extra price for
> mmapping the .mo file once, and as soon as your application/scope has
> a single human readable string outside of the .ini file you are going
> to pay it anyway. And that price is very low -- on the SD/SSD-like
> cards that we have in phones you won't be able to tell the difference.

Not exactly. If you've got 200 applications installed, the click scope
has to mmap the current locale's .mo for every single one of those
applications (assuming translations are all in the .mo and no inlined
translations). So, that's > 200 .mo files that must be loaded by the
click scope (because the scope's .mo itself will be loaded, as well as
any for other libraries being used by the scope). Some of those
applications might have thousands of strings translated, which can make
for some very large .mo files, especially in multi-byte locales. It's
also quite a lot of disk access, as there will be stat() calls to see if
the .mo is there and readable, and to fall back to other languages (such
as pt if pt_BR isn't found), as well as having to load the .desktop
files themselves and parse them to get the original string, and the
gettext domain. For 200 applications installed, that can very easily end
up being well over 1000 disk IO hits.

Loading only the .desktop file for inline translations means close to,
if not, an order of magnitude less disk IO to read the strings, as we're
looping over the directory listing, and just loading all the .desktop
files, and can fall back to other locales internally, without having to
hit the disk to check for additional translations.

So it seems to me that inline translations is an obvious and significant
performance win there.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Wed, 2014-04-16 at 07:29 +0200, Martin Pitt wrote:
> For scopes in the Ubuntu archive I think it would be better to just
> reference the translation domain in the .ini file, similar to our
> .desktop files. Then they can be covered by langpacks and we wouldn't
> need to update all click apps for new translations.

No, instead of a simple update to the click, which can be installed from
system settings and only take a few seconds for the user to accomplish,
we'd have to build an entirely new image, and require the user to do a
full system update, which will take several minutes for the user to do,
even on an extremely fast connection, and if doing it OTA, may eat up a
significant portion of their bandwidth quota for the month. Or is there
some plan to ship those language packs as click packages that the user
has to install separately, and then update? (It's not clear to me how
the user is supposed to enable alternate languages on the phone images,
given they can't install .debs.)

> > We think using this option (inline translations in the ini files vs reading
> > the translations from .mo files) is the best solution in terms of
> > performance when reading the list of scopes, but we'd like to hear other
> > comments/views too.
> 
> I think the performance question is largely irrelevant. You are going
> to open both files at runtime anyway, you most likely have other parts
> of your click package than the ini file which have translatable
> strings). Also, the disk space for inline vs. .mo translations for a
> few strings isn't going to reach a significant size.

I don't think that's true. See my other reply for more details, but
inline translations can be orders of magnitude less disk access.

> So I think which approach to use should be decided based on how we
> want the translation lifecycle/rollout to look like only.

I don't think that's right. AFAIK, we don't even have a solid plan for
how alternate system (not click packaged apps or scopes) languages are
made available to the user, and how the user would enable them. They
can't be .debs, because the user can't install them. AFAIK, the only way
to enable some languages on the phone right now, is to do it via adb
shell by remounting / with the rw flag, doing an apt-get update,
installing the appropriate language pack, tweaking something in /etc,
and rebooting.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Wed, 2014-04-16 at 18:37 +0200, Martin Pitt wrote:
> Rodney Dawes [2014-04-16 11:37 -0400]:
> > No, instead of a simple update to the click, which can be installed from
> > system settings and only take a few seconds for the user to accomplish,
> > we'd have to build an entirely new image, and require the user to do a
> > full system update
> 
> Why would that be? The langpacks should already be installed, and if
> not, you don't choose a new language when installing an app, but in
> the settings app. This would be an issue for updating the
> translations themselves, but I would have assumed that we just fold
> them into regular system image updates.

Just like on full Ubuntu, only some langpacks are installed by default.
If I want to use a language that is not covered by those langpacks, how
do I get that language? And how do you propose it gets updated if there
is a change in it? We can't possibly ship every langpack that exists in
the default image. That would make the default image way too large.

> For non-Ubuntu click packages the langpack approach is obviously not
> working (but I wrote that already), for this case I don't see any
> option other than shipping the translations (either .mo files or
> inline, not much difference) within that click package.

For click packages, shipping the translations in langpacks makes no
sense at all. It's not worth the complication; even for click packages
where Ubuntu/Canonical is the upstream.

> > I don't think that's true. See my other reply for more details, but
> > inline translations can be orders of magnitude less disk access.
> 
> This needs to be measured first. "Orders of magnitude" is certainly a
> big exaggeration; it's an extra mmap() for a single string lookup and
> maybe three extra stat calls. It can surely take a factor of about
> three (of a very short time), so whoever designs this needs to decide
> whether the easier rollout of translations is worth that cost, and
> measure how much time either approach actually takes.

It's not an extra mmap for a single string lookup. It's at least one
stat and one mmap for EVERY SINGLE APPLICATION that is is installed. If
falling back to a more generic version of the locale is required, it
adds at least one more stat. We're not talking about a click package
itself loading the translations. We're talking about one app loading the
translations for all apps. It is not an exaggeration at all. It is a
fairly close estimate. And the convenience of lang packs would only be
for things where we are the upstream (and probably only things that are
in the image itself, rather than updated via clicks). I don't think the
convenience is worth the trade-off of disk IO as relates to performance,
or battery consumption.

> For the record, I have no big emotional attachments to langpacks on
> the phone -- if we don't want them, that's entirely fine to me. If we
> are fine with shipping new translations through rebuilding/reuploading
> the corresponding (click/deb) packages, or we don't care about
> updating translations separately, let's avoid the hassle completely.
> In the "update whole system as an image" the reasons for having
> langpacks in the first place are much smaller than for the classic
> .deb based desktop.

Indeed. And I don't see a convenient way to have langpacks which aren't
debs, which means they'd have to be part of a system update. We could
theoretically have clicks that are just langpacks for the core system,
but it would be complex to build them, and it would mean doing the same
thing in two different and conflicting ways; clicks for the phone
images, and debs for full Ubuntu installs.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Wed, 2014-04-16 at 19:11 +0200, Martin Pitt wrote:
> Rodney Dawes [2014-04-16 13:02 -0400]:
> > > This needs to be measured first. "Orders of magnitude" is certainly a
> > > big exaggeration; it's an extra mmap() for a single string lookup and
> > > maybe three extra stat calls. It can surely take a factor of about
> > > three (of a very short time), so whoever designs this needs to decide
> > > whether the easier rollout of translations is worth that cost, and
> > > measure how much time either approach actually takes.
> > 
> > It's not an extra mmap for a single string lookup. It's at least one
> > stat and one mmap for EVERY SINGLE APPLICATION that is is installed.
> 
> Yes, sure. But then it's 200 * very_short_time vs. 3 * 200 *
> very_short_time, so still a total factor of 3 :-)

I think it will more often than not be more than 3, I don't think
very_short_time will be anywhere near constant, and I don't think it's
going to be linear. But I do think the performance and battery
consumption as a result of disk IO are real things we need to be
concerned about here. The difference is not negligible. :)

> > We're talking about one app loading the translations for all apps.
> 
> FWIW, that might be too slow regardless of which approach we use.
> That's fairly similar to what gnome-menus did back then to read all
> the *.desktop files in the system to build the start menu. We've had a
> patch there which created a cache of all available translations which
> got updated automatically via a dpkg trigger whenever there was a
> change in /usr/share/applications. If even parsing 200 ini files takes
> too long for a fluid UI experience, this might be something to consider.

A cache might help, but I'm not sure it would be the best solution. It
would have to be a bit more complex than just the translations. There
are some technical challenges with the way the scopes API and Unity8
work, that make it a bit hard to be as fast as we should be, though. 

> > and it would mean doing the same thing in two different and
> > conflicting ways; clicks for the phone images, and debs for full
> > Ubuntu installs.
> 
> Well, it's going to be two different systems no matter what, unless we
> want to abolish the langpacks for desktop as well. But we have lived
> with two ways of shipping translations since breezy or so :-)

Perhaps for now, but at some point that will have to converge so that
they aren't two entirely separate systems. If they always remain two
separate systems, we'll have failed at the convergence story. :)



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Wed, 2014-04-16 at 19:04 -0400, Kyle Nitzsche wrote:
> On 04/16/2014 01:11 PM, Martin Pitt wrote:
> 
> > > And the convenience of lang packs would only be for things where we
> > > > are the upstream (and probably only things that are in the image
> > > > itself, rather than updated via clicks).
> > Yes, we agree (that's what I wrote as well). As I said, the langpack
> > concept makes a lot less sense on system images where it doesn't
> > matter which "package" the bit you update (a .mo file) came from.
> > 
> Deb based language packs (for core stuff) do make sense when phone
> oem/service provider system images are created. Their rootfs gets just
> the languages they need (not all languages), saving disk. 

But the update story is horrible, because the only way to update is to
upgrade the entire OS image. As is the story for anyone who buys a phone
with those langauges, and needs a different language.

We can do better than that.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Thu, 2014-04-17 at 09:09 -0400, Kyle Nitzsche wrote:
> Just noting that our traditional deb based lang packs approach (for core 
> stuff)
> in the context of the monolithic system image enables:
> * producing stock Ubuntu devices with as wide a set of languages as is wanted
> * while also allowing custom phones/tablets to trim that down to the hand 
> picked
> languages they want and thereby freeing disk space

While the debs do allow this, it is only convenience to us that they are
debs we are doing it with. There are other ways we could enable this,
without debs, but it requires work. The debs are convenient right now,
but when requirements change and we need to provide translations updates
without upgrading the whole image, they will not be so convenient.

> If we do not have the ability to add translations for core stuff (not 
> including
> click pkgs) beyond that baked into the image, then the pressure will be to add
> as many languages into the stock image as possible. In my experience, OEMs are
> often quite clear that their product does not need all those languages and 
> they
> choose to delete them for the disk space. Lang packs enable these options
> without much fuss, it seems to me.

The main issue with the current debs system is that we are shipping a
lot of translations we don't actually need to be on the system, because
our language pack debs are built from the requirements of the full
Ubuntu ISO, and not the phone image. So we are already hitting a
conflict of interest between the two.

> I look forward to hearing about how/whether we intend to support adding
> translations for core stuff beyond that provided in the system image when it 
> is
> built. If we can do that, this part of the discussion is moot.

I would hope we intend to support that. We've been supporting it for 10
years in Ubuntu. I don't see why we'd stop supporting it just because
some OEMs want to ship images with only a subset of translations. If we
don't support it, it means some people will never be able to use an
Ubuntu phone, without building their own custom images and reflashing a
device. I sure hope that isn't how we intend to continue supporting it.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Thu, 2014-04-17 at 10:24 -0400, Kyle Nitzsche wrote:
> So to be clear, I don't really care if it is debs or not. It's just that debs
> already work (except for the requirement to add translations/languages at
> runtime). And we have a fully functioning set of things that enable:
> * customized images (only include the languages you want)
> * customized packages (that add features and just those features' translations
> to a pkg while falling back to the translations provided for the pkg by lang 
> packs).

This is the case at the moment, because it is convenient at the moment.
I don't think it will continue to remain that way in the future, as we
move closer and closer to having a converged system.

> The only thing we do not have now (as previously mentioned in this thread) is
> adding a language at runtime that it not baked into the system image. Can an
> overlay file system solve this by allowing language deb installation (by a
> language selector settings widget like in 'classic' now) into a read-write 
> area
> that is joined with the read-only area?

I don't know if an overlay is the way to fix that, and I don't know that
we want to enable the installation of debs for this at all. I also don't
think it's necessarily important to solve it right now. It needs a lot
more thinking and discussion, as it's not a trivial problem to solve. I
do think it is important to mention it and provide a little thought on
it right now though, as we don't want to solve the problem of i18n in
scopes in one way, and then solve the enabling of non-default languages
in another way in the future, and have to go back and re-implement a lot
of things, because those conflict.

> Yes: Perhaps the lang packs for Ubuntu Desktop would not be the same as for
> Ubuntu for phones/tablets.

I don't think that's what we want. That would be working against the
goal of having a converged Ubuntu image. It might be a viable short-term
option to optimize the phone images for the initial Meizu/Bq phones, but
I don't think it is a viable long-term goal for Ubuntu. OEMs/providers
might want to have custom images with certain languages by default, but
for the images one downloads from ubuntu.com, it seems like it would be
the same image, whether it's for installing on a phone, tablet, or PC,
once we've hit the convergence goal.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Thu, 2014-04-17 at 09:52 -0500, Ted Gould wrote:
> On Wed, 2014-04-16 at 14:10 -0400, Rodney Dawes wrote: 
> > On Wed, 2014-04-16 at 19:11 +0200, Martin Pitt wrote:
> > > Rodney Dawes [2014-04-16 13:02 -0400]:
> > > > We're talking about one app loading the translations for all apps.
> > > 
> > > FWIW, that might be too slow regardless of which approach we use.
> > > That's fairly similar to what gnome-menus did back then to read all
> > > the *.desktop files in the system to build the start menu. We've had a
> > > patch there which created a cache of all available translations which
> > > got updated automatically via a dpkg trigger whenever there was a
> > > change in /usr/share/applications. If even parsing 200 ini files takes
> > > too long for a fluid UI experience, this might be something to consider.
> > 
> > A cache might help, but I'm not sure it would be the best solution. It
> > would have to be a bit more complex than just the translations.
> 
> For me I can't figure out why the click scope would be reading the
> desktop files of click apps anyway, it should be building a cache when
> the app is installed. We have good hooks for that now. It could also
> rebuild the cache when the language is changed. Both of those are
> significantly more rare conditions than searching for applications.
> Also, the cache can be built with the names already tokenized and
> optimized for search as well.

The click scope doesn't install things, and click isn't building the
necessary cache anywhere. The scope can't build either of those (unless
it's going to read the desktop files, in which case it would have to
read them every time anyway to make sure they are in the cache), because
the scope is stateless. The scope may not even be running when an app is
installed. There would have to be an external tool to build such a
cache, regardless of what the cache contains.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

Those are the same language packs currently installed on the phone
images as well. This is what I meant by them including too much. A very
large number of the translations provided by these -base packages are
totally not useful on the phone. Heck, a very large number of the
translations aren't even applicable to the default install on a PC from
the ISO either. It will likely be quite a lot of work to get them split
up properly into meaningful packs, and I don't know if there is any plan
to invest in doing that.

And while it will help reduce the size to do that cleanup, it doesn't
fix the issue of how to upgrade them independently of the image itself,
or how to enable translations for other languages not on the image.

On Thu, 2014-04-17 at 23:15 +0800, James Henstridge wrote:
> So on my system, I currently have the following language pack .debs installed:
> 
> language-pack-en
> language-pack-en-base
> language-pack-gnome-en
> language-pack-gnome-en-base
> 
> And there is a language-pack-kde-en package I could install for
> additional KDE specific localisation.  So there already seems to have
> been an attempt to provide more focused localisation.
> 
> If we wanted to use language packs on the Ubuntu Touch image, it
> doesn't seem out of the question to provide language packs that cover
> only the touch image, which should minimise the storage impact.
> 
> James.
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Thu, 2014-04-17 at 10:26 -0500, Ted Gould wrote:
> Correct, that external tool would be a click hook that the click scope
> would install. Basically similar to the hook that UAL installs today.
> The architecture would be similar to how URL dispatcher does things:

Well, it would be the hook, and the tool that the hook runs and actually
does the parsing and cache generation, a la update-desktop-database
being run in a dpkg trigger. But sure, that's a possibility, assuming
that cache is the right solution to the problem.

I don't want to implement caching to work around problems in the scopes
architecture and the way the dash UI works. For example, the only way to
"move" an app from the "available" category to the "installed" category,
is to re-do the search, right now. But a cache is a workaround for that,
not a solution to the problem. I'm also not sure the QML for the UI is
even capable of handling something like a move right now.

The cache also doesn't solve the problem of deciding whether to use
inline translations in .desktop files, or to use .mo files for the
translations. All it does is move the parsing to another point in time.
The performance and battery usage concerns still remain. Even with a
cache, we don't want the thing building the cache to have to load all
the .desktop files, and all the .mo files, to do it, I don't think.
Having inlined translations in the .desktop files will still be a bigger
win there.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Nexus 7 2013 tmobile

[Rodney Dawes]

On Sat, 2014-04-19 at 16:43 -0700, Sameer Verma wrote:
> On Sat, Apr 19, 2014 at 1:15 PM, Sameer Verma  wrote:
> > I have a Nexus 7 2013 with T-Mobile's radio/SIM (it has WiFi as well).
> > Is this device OK for flashing? I see that this page only has Nexus 7
> > 2013 WiFi.
> >
> > https://wiki.ubuntu.com/Touch/Install#Target_devices
> 
> This is what I get so far:
> 
> sverma@imagenius:~$ ubuntu-device-flash --channel=trusty-proposed --bootstrap
> 2014/04/19 16:40:30 Expecting the device to be in the bootloader... waiting
> 2014/04/19 16:40:30 Device is |deb|
> 2014/04/19 16:40:30 Device deb not found on server
> https://system-image.ubuntu.com channel trusty-proposed

The target devices page is correct. The 2013 wifi is 'flo'. The 'deb'
device is not supported by the official builds yet. You may be able to
use multirom to dual boot, or community builds for single boot.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Mon, 2014-04-21 at 13:27 +0200, Martin Pitt wrote:
> Rodney Dawes [2014-04-17 11:41 -0400]:
> > And while it will help reduce the size to do that cleanup, it doesn't
> > fix the issue of how to upgrade them independently of the image itself,
> 
> Why would we need to do that? We do image upgrades by far more often
> than we upgrade our langpacks, so it's not a problem at all to just
> fold the translation updates into the regular image updates.

Do the cleanup? Or upgrade langpacks independent of the image itself?
We're only shipping image updates far more often than langpacks
currently, because we're still under very early and heavy development.
We we start shipping on actual hardware, users aren't going to want to
install image updates every day, or even every few days. And no matter
how many image updates we ship, if the image doesn't include the
language the user needs, it's not going to solve that user's problem.

The cleanup we should do, because we aren't shipping brasero, metacity,
gedit, eog, nautilus, etc… on the image. But currently their
translations are being shipped there. How many MB will we gain back in
the image, if we pull the translations for all the things we aren't
shipping there? How many additional languages could we ship as a result
of that cleanup? Heck, there are lots of translations for things that
aren't even included in the default install of the ISO image, and
certainly not in the phone image. Like MoinMoin, git, or bacula.

> > or how to enable translations for other languages not on the image.
> 
> Yes, that's hard to do as long as we have translations in .debs and
> system images aren't able to deal with those. But OTOH when we don't
> ship translations in langpacks but in the apps themselves, we don't
> have the option at all to enable/disable languages individually
> because we'd always ship with all of them.

Apps will certainly have their own translations in their own packages.
I'm talking about the system language. If the system translations aren't
available, it doesn't matter what translations are in the apps
themselves, because users will only be able to choose languages that are
included in the image already. With the current solution of having
langpacks on the image, we either have to ship them all, or get rid of
them and ship all the translations in their respective packages.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

On Mon, 2014-04-21 at 19:54 +0200, Rasmus Eneman wrote:
> As a user I want to be able to buy a phone anywhere and just go to
> System Settings and choose or install my language. So languepacks
> needs to be supported and be installable individually. If this is by
> deb or something else doesn't matter. The only app that would be
> allowed to install language packs is system settings so if it's using
> debs doesn't mean that users can install debs.
> Of cource the language packs needs to be trimmed to only contain
> what's in the image. Apps needs to bring their own translations.

Actually, yes it does mean that langpacks won't be installable, because
only root can install debs, and the rootfs partition must be writable,
which it is not. The / partition is read-only, and thus nothing can be
installed to it, without enabling some sort of "developer mode" to make
it writable. You certainly don't want to have to enable developer mode,
or plug in via USB and use developer tools, to be able to install the
language you need, when you buy a new phone.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing scopes

[Rodney Dawes]

Only if the langpacks are not debs. Nobody is necessarily talking about
changing the UX. The UX right now doesn't even exist yet. Just because
something has historically worked a certain way in Ubuntu, doesn't mean
that's the right way for it to work on the phone, in a confined
environment. And the technical solution can only be implemented once
we've decided what that UX should be, exactly. 

On Mon, 2014-04-21 at 22:50 +0200, Rasmus Eneman wrote:
> But you could mount the locations of langpacks on a R/W partition and
> letting System Settings install them can be done with Apparmor.
> Technicall isues should be solved, not user experiace changed.
> 
> On Apr 21, 2014 8:19 PM, "Rodney Dawes" 
> wrote:
> On Mon, 2014-04-21 at 19:54 +0200, Rasmus Eneman wrote:
> > As a user I want to be able to buy a phone anywhere and just
> go to
> > System Settings and choose or install my language. So
> languepacks
> > needs to be supported and be installable individually. If
> this is by
> > deb or something else doesn't matter. The only app that
> would be
> > allowed to install language packs is system settings so if
> it's using
> > debs doesn't mean that users can install debs.
> > Of cource the language packs needs to be trimmed to only
> contain
> > what's in the image. Apps needs to bring their own
> translations.
> 
> Actually, yes it does mean that langpacks won't be
> installable, because
> only root can install debs, and the rootfs partition must be
> writable,
> which it is not. The / partition is read-only, and thus
> nothing can be
> installed to it, without enabling some sort of "developer
> mode" to make
> it writable. You certainly don't want to have to enable
> developer mode,
> or plug in via USB and use developer tools, to be able to
> install the
> language you need, when you buy a new phone.
> 
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] [Development] anti-theft

[Rodney Dawes]

The system has support for click packages which cannot be removed by the
user. However, if the phone is plugged in to USB and the Android
development tools are used, then the device can be wiped completely
clean, from underneath the OS. There's nothing we can do about that in
the OS itself right now, and any anti-theft support at that low level
would have to be implemented by the hardware vendors, not necessarily as
part of the Ubuntu OS that runs on the device.

But as far as click packages go, it is perfectly reasonable to have a
pre-installed package that cannot be removed by the user, in normal
operation of the phone. The click package system already supports this.


On Sat, 2014-04-12 at 18:53 -0430, Yasmany Cubela Medina wrote:
> I study the idea of prey but it would be an installed app so if you
> could remove it from your phone there is no protection enymore, i mean
> if the theif could uninstall de app then this solution its no so
> definitive.
> 
> 
> The main idea its to protect the phone(device) from the core main
> code, some service that will be configured at start and can be
> uninstalled form the system, and only let the phone start if there is
> an authorized account in the phone(device)
> 
> S.U.C.C.E.S.S
> Success is a journey, not a destination.
> Ing. Yasmany Cubela Medina:
> Linux user 446757
> Ubuntu user 13464
> 
> 
> 
> On Sat, Apr 12, 2014 at 2:11 PM, Daniel Holm 
> wrote:
> Hi,
> 
> I've been thinking about this kind of app as well and would
> very much like one. Since I already use Prey I started there
> and asked them about an app, but they were not yet interested
> in making one for Ubuntu Touch.
> 
> However, as they pointed out, and which already has been
> discusses, Prey is open source and we could perhaps try to do
> a port. Start a project and let people that want, participate.
> 
> An app like this is our course a very much wanted one. I don't
> want to loose my lovely Ubuntu phone ;)
> 
> Vänlig hälsning / Yours sincerely,
>Daniel Holm
>IT Consultant
>Web Developer
>Student, Political Science
>d.hol...@gmail.com
>http://www.danielholm.se
> 
> Den 11 apr 2014 14:59 skrev "Yasmany Cubela Medina"
> :
> 
> Yes i know about prey and of course we dont need to
> reinvent the wheel. deliver prey pre instaled and
> configured on ubuntu phone will be a very good
> starting point, the main idea its that the phone will
> be unsusable if its not unther the first owner
> account.
> 
> S.U.C.C.E.S.S
> Success is a journey, not a destination.
> Ing. Yasmany Cubela Medina:
> Linux user 446757
> Ubuntu user 13464
> 
> 
> 
> On Fri, Apr 11, 2014 at 7:27 AM, Facundo Batista
>  wrote:
> Simos Xenitellis escribió (el 11/04/14 08:52):
> 
> > Did you hear about Pray?
> >
> >   https://preyproject.com/
> >
> >
> > And to take it a bit further, you are
> suggesting to port the client code for Prey to
> Ubuntu Phone,
> > https://github.com/prey
> >
> > (other clients are available at
> https://preyproject.com/download )
> 
> 
> It may be an excellent idea if we deliver Prey
> pre-installed.
> 
> My experience: I just bought a Moto-G phone,
> and tried to setup the "location service in
> case of theft" of Motorola...
> it was too complicated, needed to go between
> phone and web several times, couldn't make it
> work.
> 
> Setting up Prey is a breeze. It's a very well
> thought product.
> 
> My point is: let's not reinvent the wheel :)
> 
> Regards,
> 
> --
> .   Facundo
> .
> Canonical - Ubuntu Engineering
> 
> 
> 
> --
>   

Re: [Ubuntu-phone] Code for Google Online account?

[Rodney Dawes]

In lp:account-plugins

On Wed, 2014-04-23 at 22:52 +0200, Daniel Holm wrote:
> Hi all,
> 
> I was thinking about a ownCloud online account and wanted to take a
> look at the code for the Google online account plugin, but I can't
> find it?
> 
> Where is it?
> 
> Thanks,
> Daniel
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing Team 01.05.14

[Rodney Dawes]

On Fri, 2014-05-02 at 03:34 -0600, Selene Scriven wrote:
>   - Installing an app without a U1 account configured no longer 
> works.  This is a regression.  Tap the app, tap install, tap 
> "go to accounts" to configure a U1 account, and then...  
> nothing.  Back to the app preview.  However, the install 
> works after configuring a U1 account through a different 
> route.

What exactly does "and nothing" mean here exactly?

It has always been the case that in this situation, you configure the
account, go find the app again (because there's no way for us to go from
the accounts settings directly back to the preview and immediately start
the install), open the preview, and hit Install. There were also no
changes to the scope in build #8, so I find it hard to think this would
have broken. It may be that in that version of the scope, you ran into
the crash that could sometimes happen on search, if you searched for the
app after adding the account (possibly bug #1297297).

However, build #9 does have a new version of unity-scope-click, which
has many bug fixes, including total replacement of the code that was
previously crashing there.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing Team 01.05.14

[Rodney Dawes]

On Fri, 2014-05-02 at 11:29 +0100, Alan Pope wrote:
> (although I can see a corner use case where you can pan apps left and
> right, one app plays through the left channel, another app through the
> right - it would keep my kids quiet in the back of the car when they
> share a set of headphones!)

It would also be nice to allow the music app to play in background,
while playing games. Some people do like to do that.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] First Utopic Image is here !!!

[Rodney Dawes]

On Sun, 2014-05-04 at 10:36 +0800, Shuduo Sang wrote:
> The 'availables' list do not show on my N4 with utopic r9. No log
> found in /var/crash.

This may be due to bug #1307981 [1] or just that the search was
performed before network became available. You can check
~phablet/.cache/upstart/scope-registry.log for errors related to the
search, and likely will see a "host not found" error. Doing a manual
search for an app should resolve it, unless the local DNS cache on the
phone is caching the resolution failure, and just always failing to look
up the host on future attempts. If that happens, rebooting may also
"fix" it.

[1]
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1307981



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing Team 01.05.14

[Rodney Dawes]

On Tue, 2014-05-06 at 12:03 +0100, Dave Morley wrote:
> The reason I say feature request rather than bug fix is there is no
> setting to change sensitivity and there is no lock function currently so
> both of these features would need adding.  Yes it is a bug that it is
> sensitive but the bug is asking for features to be added that don't 

The solution to a bug being a feature addition does not make the bug not
be a bug. Just making the screen rotation less sensitive, and disabling
the vibration feedback for every little thing that ever happens, will be
a huge improvement, even without any user visible setting to alter it.

Even missing features are bugs. "Unable to do foo" is a bug, not a
feature request, and in some cases, can be a serious usability issue.

That said, please file bug reports in the form of describing the
problem, not what you think the solution should be. "Screen rotation too
sensitive" is the problem, and "Add screen rotation settings" is only
one of many possible solutions to the issue. Bug reports should not be
trying to tell the developer what to do, but tell them what is wrong. So
please file reports in the former form.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Internationalizing app metadata

[Rodney Dawes]

On Tue, 2014-04-15 at 21:40 +0200, David Planella wrote:


> The situation right now is that translations come from the Store,
> where there is support for editing them via a form. It should also be
> soon possible for clients (e.g. the click scope) to fetch those
> translations when online.

I don't think the server is filtering on Accept-Language yet to send
translated values in the JSON for app metadata, however the click scope
is now sending the Accept-Language header, so this should start working
as soon as the server starts filtering on that value and sending
translated values where appropriate.

> 1) Where: options to implement offline translations include adding
> internationalization support to either .desktop or click manifest
> files, and from a talk with dobey, it seems the manifest files would
> be a good candidate. When online, translations could be downloaded and
> refreshed if necessary.

There is a branch up which adds support for translations of apps in the
click scope. This includes translation of the Name and Comment fields in
the .desktop file (the only translated fields which are being loaded by
the scope at the moment). For apps packaged as clicks, this means the
translations will need to be merged back into the .desktop file, as the
click scope has no way to know where to load the translations from for
click packages via gettext domain. This includes the pre-installed click
packaged core apps. For the pre-installed apps which are not click
packages, we are currently supporting the use of the gettext domain
loading, but these apps should be converted to clicks at some point, and
have their translations merged back into the .desktop file where
necessary.

This also does not resolve the issue of having translated screenshots
for app previews, nor translated icons (in cases where metaphors do not
translate to other cultures). I'm not sure how we could fix these issues
exactly.

> 3) Inline translations or MO files: for performance reasons, the
> suggestion is to include the translations inline in in the manifest or
> desktop files, as they could be read while listing all available apps
> without having to additionally open each app's .mo file. Thoughts on
> this?

Not only for performance reasons, but also for practicality. There is no
way for the click scope to know where on the filesystem the .mo files
might be for a click package. So click packages will need to have their
translations merged back into the .desktop files.




-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] How do I fix my phone?

[Rodney Dawes]

The same partition for /home also contains /opt and several other
loopback mounts for things in /etc and such to allow for writable
content. Perhaps you could uninstall some apps to free up some space?

On Mon, 2014-05-12 at 12:38 +0100, Sam Bull wrote:
> So, for the second time now, I've run out of disk space, and phone is
> completely non-functioning.
> 
> But, I can't even work out what I should be deleting to free up space.
> Disk free says I have used 13GB in my home partition and there is no
> free space, while disk usage says I've used 6.8GB. Disk usage indicates
> nothing out of the ordinary for me to delete, so where's the rest of my
> disk space gone??
> 
> root@ubuntu-phablet:~# df -h /home
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mmcblk0p23   13G   13G 0 100% /home
> root@ubuntu-phablet:~# du -sh /home
> 6.8G  /home



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] CPU or GPU acceleration?

[Rodney Dawes]

Ubuntu is pretty fast on my Nexus 5. The sound is choppy sometimes, yes,
but that has nothing to do with the video acceleration scheme. It's due
to bugs that occur on a device which is not well supported yet.


On Mon, 2014-05-12 at 23:47 +0400, Zonov Roman wrote:
> May be it is because my phone is not supported officially, but Nexus 5 
> (hammerhead). It also has very laggy sound. 
> 
> I worry because Nexus 5 is more powerful, than Nexus 4.
> 
> 12.05.2014, 23:44, "Oliver Grawert" :
> > hi,
> > Am Montag, den 12.05.2014, 23:27 +0400 schrieb Zonov Roman:
> >
> >>  Thank you for your answers. Because of not so smooth interface I can't 
> >> use UT now. I hope, that situation will change in near future:) But 
> >> no...it changes now, thanks to community and you, Ricardo, of course)
> >
> > on what device are you testing ? while it is a tiny bit slower than
> > android on the nexus4 I dont really see a massive difference in day to
> > day use  ... the same goes for the 2013 model of the nexus7 ...
> >
> > ciao
> > oli
> >
> > ,
> > --
> > Mailing list: https://launchpad.net/~ubuntu-phone
> > Post to : ubuntu-phone@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~ubuntu-phone
> > More help   : https://help.launchpad.net/ListHelp
> 
> -- 
> Best regards,
> Zonov Roman.
> 
> VK: http://vk.com/feed
> Facebook: https://www.facebook.com/roman2861
> Twitter: https://twitter.com/zonov_roman
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] problem with WiFi networks that use WPA encryption - mako - build #41

[Rodney Dawes]

Working fine here on my Nexus 5.

On Wed, 2014-05-21 at 19:10 +0200, Sebastian Gomułka wrote:
> Is it just me or maybe there is a problem on Ubuntu Touch with WiFi
> networks that use WPA encryption?




-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Renaming to: Ubuntu App Launch

[Rodney Dawes]

Is there a particularly good reason to not provide a symlink, or a
wrapper script that issues a deprecation warning when run, for
compatibility?

On Thu, 2014-05-22 at 11:13 -0500, Ted Gould wrote:
> Hello Folks,
> 
> Upstart App Launch is dead, long live Ubuntu App Launch!
> 
> We've discussed it before and I've got a MR ready for UAL to make the
> naming change so that we're ready to move away from Upstart as our
> Init system. I'd like to work with folks on running sed through their
> code and landing this change next week. If you've got a test script or
> something that is dependent on the name "upstart-app-launch" please be
> prepared to change. In theory, we should be able to do it in one silo
> and folks shouldn't notice, I'm just worried about dependencies that
> are external to debs or not mentioned. If you have a dependency that
> you know of that I'm unlikely to find, please mention it.
> 
> If for some reason this seriously effects you in a negative way,
> please speak up now!
> 
> Thanks,
> Ted
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Renaming to: Ubuntu App Launch

[Rodney Dawes]

Well, won't it break all existing click apps when the update is
installed? Or will the update regenerate all installed click .desktop
files for the user as well? If not, then at least a symlink will be
required until they are all regenerated.


On Thu, 2014-05-22 at 11:43 -0500, Ted Gould wrote:
> 
> No reason to take on tech debt if we don't have to. Certainly if a
> bunch of people reply that it's an issue it's not impossible to do
> that. But cruft is cruft, I'd rather be proactive on cleaning it.
> 
> Ted
> 
> On Thu, 2014-05-22 at 12:36 -0400, Rodney Dawes wrote: 
> > Is there a particularly good reason to not provide a symlink, or a
> > wrapper script that issues a deprecation warning when run, for
> > compatibility?
> > 
> > On Thu, 2014-05-22 at 11:13 -0500, Ted Gould wrote:
> > > Hello Folks,
> > > 
> > > Upstart App Launch is dead, long live Ubuntu App Launch!
> > > 
> > > We've discussed it before and I've got a MR ready for UAL to make the
> > > naming change so that we're ready to move away from Upstart as our
> > > Init system. I'd like to work with folks on running sed through their
> > > code and landing this change next week. If you've got a test script or
> > > something that is dependent on the name "upstart-app-launch" please be
> > > prepared to change. In theory, we should be able to do it in one silo
> > > and folks shouldn't notice, I'm just worried about dependencies that
> > > are external to debs or not mentioned. If you have a dependency that
> > > you know of that I'm unlikely to find, please mention it.
> > > 
> > > If for some reason this seriously effects you in a negative way,
> > > please speak up now!
> > > 
> > > Thanks,
> > > Ted
> > > 
> > 
> > 
> 
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Renaming to: Ubuntu App Launch

[Rodney Dawes]

Oh. I guess they don't need to be regenerated. I thought they were
generated with upstart-app-launch in the Exec line, but it looks like
they're just calling aa-exec-click instead. Sorry.

Every image update/flash will result in all hooks being re-run for all
packages? That was what I was asking. Of course the hook would be run if
the package was installed again, or a new package was installed, but for
existing installs, I don't think the hooks are re-run on full image
updates, are they? (I don't mean for pre-installed apps.)


On Thu, 2014-05-22 at 11:55 -0500, Ted Gould wrote:
> 
> Not sure why they'll need to be all regenerated, mostly those desktop
> files are a bridge, but not used by UAL at all. I hope that someday
> soon they'll go away on the Unity8 desktop.
> 
> That being said, they will be as the click hooks are rerun by the
> package hook and the result will be removing one hook and adding
> another WRT to click. In both cases the hook gets executed.
> 
> Ted
> 
> On Thu, 2014-05-22 at 12:49 -0400, Rodney Dawes wrote: 
> > Well, won't it break all existing click apps when the update is
> > installed? Or will the update regenerate all installed click .desktop
> > files for the user as well? If not, then at least a symlink will be
> > required until they are all regenerated.
> > 
> > 
> > On Thu, 2014-05-22 at 11:43 -0500, Ted Gould wrote:
> > > 
> > > No reason to take on tech debt if we don't have to. Certainly if a
> > > bunch of people reply that it's an issue it's not impossible to do
> > > that. But cruft is cruft, I'd rather be proactive on cleaning it.
> > > 
> > > Ted
> > > 
> > > On Thu, 2014-05-22 at 12:36 -0400, Rodney Dawes wrote: 
> > > > Is there a particularly good reason to not provide a symlink, or a
> > > > wrapper script that issues a deprecation warning when run, for
> > > > compatibility?
> > > > 
> > > > On Thu, 2014-05-22 at 11:13 -0500, Ted Gould wrote:
> > > > > Hello Folks,
> > > > > 
> > > > > Upstart App Launch is dead, long live Ubuntu App Launch!
> > > > > 
> > > > > We've discussed it before and I've got a MR ready for UAL to make the
> > > > > naming change so that we're ready to move away from Upstart as our
> > > > > Init system. I'd like to work with folks on running sed through their
> > > > > code and landing this change next week. If you've got a test script or
> > > > > something that is dependent on the name "upstart-app-launch" please be
> > > > > prepared to change. In theory, we should be able to do it in one silo
> > > > > and folks shouldn't notice, I'm just worried about dependencies that
> > > > > are external to debs or not mentioned. If you have a dependency that
> > > > > you know of that I'm unlikely to find, please mention it.
> > > > > 
> > > > > If for some reason this seriously effects you in a negative way,
> > > > > please speak up now!
> > > > > 
> > > > > Thanks,
> > > > > Ted
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> 
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing team 02.06.14

[Rodney Dawes]

On Mon, 2014-06-02 at 20:03 +0200, Łukasz 'sil2100' Zemczak wrote:
> From the user point of view images #59 and #60 work normally, so no
> worries. Those include the new unity8 with the greeter working now
> separately of unity8.

On my Nexus 5, I had to switch back to "devel" as with 59/60, the screen
would go completely black after a bit, and never come back. I see ogra
mentioned a similar issue on Nexus 7 (flo) in the "Image #57 Unity8
issue" thread. Any idea what regressed there?

> ** Pictures taken with flash are almost completely black (Bill)
> https://bugs.launchpad.net/camera-app/+bug/1322121
>  -> Camera-app might be rewritten soon

I took a picture in Malta with flash on my Nexus 5, and it actually came
out completely white, not black.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Fwd: Ubuntu touch 14.10 screen problem after install

[Rodney Dawes]

Which Nexus 7?

2012 is no longer supported (and lots of freezes were happening on the
latest 14.04 images that were built for it).


On Mon, 2014-06-02 at 20:51 +0200, Márton Parrag wrote:
> 
> 
> -- Forwarded message --
> From: Márton Parrag 
> Date: 2014-05-31 15:57 GMT+02:00
> Subject: Ubuntu touch 14.10 screen problem after install
> To: ubuntu-touch-corea...@lists.launchpad.net
> 
> 
> After I installed ubuntu touch and I boot the first time the screen is
> frozen. I could not do anything just off divice. Then the second time
> when I started Ubuntu touch 14.10 I was able to solve and then frozen
> on the screen.  
> 
> 
> What can I do?
> 
> 
> I installed ubuntu with Ubuntu Dual Boot app and I attached picture
> for it.
> 
> 
> Summerise my problem is my nexus 7 under ubuntu always frozen the
> screen.
> 
> 
> Plz help me.
> 
> 
> THNAKS
> 
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Developers: changelog quality

[Rodney Dawes]

On Thu, 2014-06-05 at 14:05 +0200, Oliver Grawert wrote:
> As one of the persons on the landing team who is in charge to nod off
> packaging changes I will from today on *NOT ACK ANY PACKAGING CHANGES*
> that do not:
> 
> a) have a descriptive enough changelog entry so that a developer not
> affiliated with your code can understand what changed, why it changed
> and where it changed in the tree.

Can we fix the CI train so that it doesn't reformat multi-line commit
messages in the MP into a single very long line of very hard to read
text?

Also, how does one get reasonable changelog entries that follow the
Debian style? It seems with CI train, we don't get very nice
debian/changelog entries. For example, for a manual upload to bump the
Standards-version, a typical entry would be like this:

  * debian/control:
- Update standards version to 3.9.5.

But with Ci train, depending on what is put in the commit message field
of the MP, we might get something like this:

  * - Update standards version to 3.9.5.

Or if there are other changes:

  * - Update standards version to 3.9.5. - Add dependency on
foo-bar-dev.

It would be nice if we could get changelog entries that more closely
match the classic manual upload changelog entries, for the automated
builds.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Identifying memory issues, #2

[Rodney Dawes]

On Wed, 2014-06-04 at 18:37 +0100, Alan Pope wrote:
> Here's the only output I managed to grab and paste before it froze:-
> 
> http://paste.ubuntu.com/7588543/

Not directly related to memory, but why are all the backgrounded apps
using > 6% CPU? And why is Unity8 using almost 40%? What is crashing
there (apport is using almost 20% CPU)? With the numbers in your paste,
your CPU is around 80% utilization, which will certainly heat the phone
up and run the battery down.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Identifying memory issues, #2

[Rodney Dawes]

On Thu, 2014-06-05 at 20:03 +0200, Thomas Voß wrote:
> Good catch, the more important question is: Why are two apps running
> in parallel?
> Our lifecycle policy does not allow for that.

Well, if my understanding of the policy and its implementation is
correct, then they are stopped/suspend, and simply waiting for the
signal to resume when the user taps on the app under "Recent" or
switches with the right-edge swipe.

Also, the policy is very frustrating. It means it is not easy, if not
wholly impossible, to write certain classes of applications, that need
to continue running in the background for valid reasons; including
several apps that I was wanting to write. :(


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing team 06.06.14

[Rodney Dawes]

On Fri, 2014-06-06 at 09:23 -0700, Robert Park wrote:
> Good news everyone!
> 
> Image #71 has been promoted, and it's our greenest image yet! This
> means TRAINCON-0 is over and normal landings are resumed.

What project/package exactly should one file general regressions
against?

For example, with image #50 my phone was working basically fine
(sometimes the modem stays offline, but otherwise fine). After updating
#71, when the screen powers off, it very often will not power on again.
The issue seems to happen much less when plugged in to charge, but is
very common when on battery only. I have no idea what caused this
exactly (though I suspect something related to the greeter splitting),
so where should I file it?



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Bad voice call quality on Nexus 4 (old modem firmware)

[Rodney Dawes]

On Tue, 2014-06-10 at 11:26 -0300, Ricardo Salveti de Araujo wrote:
> Unfortunately we're unable to automatically push such updates to our
> users as we're not able to distribute such binaries, so that's why you
> need to manually update them.

Can we not do some wget/shasum magic to download the firmware from the
Google site, and then flash it to the phone, similar to how we install
Adobe Flash (we don't actually distribute the binary, but just wget it
in the dpkg install scripts)?



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Calling for Click signing

[Rodney Dawes]

On Fri, 2014-06-13 at 15:48 +0100, Ondrej Kubik wrote:


> If two different apps are coming from same developer and share same
> package name ( and same signature) will they share same sandbox or
> will they be able to peak into each other's sandbox, at least data
> wise?

The only ways currently for two apps to share data, under confinement,
is for both of those apps to be in the same package, or to share that
data via contenthub/mediahub.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Simple mass-change: Mark universe packages for langpacks, please include in your next MP

[Rodney Dawes]

On Fri, 2014-06-13 at 17:56 +0100, Iain Lane wrote:
> Hi Martin,
> 
> On Fri, Jun 13, 2014 at 03:38:58PM +0200, Martin Pitt wrote:
> > […]
> > Due to the CI train I can't just upload these or stage these in
> > lp:, but we need MPs and verification, etc. As this won't
> > change anything at runtime it hardly makes sense to go through all
> > this fuss just for this change alone.
> 
> IMHO you could upload for these. At the next train upload people will
> notice and then it will be trivial to sync the change back in.

It's actually quite annoying to have changes pushed directly to the
archive for the things I manage that are in CI train. It means someone
is probably then also going to manually commit the change to trunk, and
sometimes the wrong version is used for the upload, or conflicts get
introduced. So I certainly prefer for things not to be uploaded direct
to the archive, but instead go through the standard MP and CI process
that all the changes we devs make must go through.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Simple mass-change: Mark universe packages for langpacks, please include in your next MP

[Rodney Dawes]

On Fri, 2014-06-13 at 21:15 +0100, Iain Lane wrote:
> These are one line additions to debian/control.

They are rebuilds. Maybe for all the packages that isn't an issue, but
for C++, it means that anything that provides a template the code uses,
and which has changed since the last build, has the potential to break
the behavior of the code using that template, as they are processed at
compile time, and not at runtime when the shlib is loaded.

Not trying to be annoying, but having two conflicting ways of getting
things done now, very much is annoying.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Cellular Fail

[Rodney Dawes]

On Tue, 2014-06-17 at 09:35 -0400, Tony Espy wrote:
> On 06/16/2014 09:58 AM, Pat McGowan wrote:
> > In my experience No signal shows up when in fact the modem is on and
> > you have no connection.
> > When the modem is off it does not appear, which is what needs fixing.
> 
> There's at least one bug tracking this issue ( ie. no icon to reflect 
> modem offline ):
> 
> https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1315144

I think part of the problem here is that we are not showing the signal
carrier in any way in the normal UI. Instead, we have "Search" in the
top bar. But with that moving into the header in apps and the dash, we
should probably show the carrier name, and when there is no carrier show
"Searching for network" or "No SIM, SOS only" or similar, as every other
phone on the market has done for the last 20 years.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Landing team 17.06.14

[Rodney Dawes]

On Tue, 2014-06-17 at 19:49 +0200, Łukasz 'sil2100' Zemczak wrote:
> Top news: image #85 promoted! There are some changes of interest in this
> image, one of which is the new design of address-book-app, dialer-app
> and messaging-app. This image also doesn't use the desktop translation
> files anymore - this means there might potentially be some applications
> that are be missing translations (like, for instance, the dialer-app).
> We apologize for any possible inconveniences. We assure you that those,
> if identified, will be fixed as soon as possible.

What changed exactly with the translations here? These apps weren't
using translations embedded in the .desktop files anyway, but were using
the X-Gettext-Domain= in the .desktop file to point to their translation
domain. Did this change to include the translations in the .desktop
files directly? Or was the X-Gettext-Domain= entry just removed?



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Calling for Click signing

[Rodney Dawes]

On Wed, 2014-06-18 at 14:39 +0100, John Lenton wrote:
> On 18 June 2014 14:27, Ondrej Kubik  wrote:
> > Idea is to protect from using side load to update existing application with
> > intruder's version to gain access to application private data or phone's
> > resources.
> 
> sorry for being dense, but what's the scenario where you are able to
> sideload while also not being able to just get the data you want off
> of the phone directly?

Yeah, one kind of needs a rooted phone with physical access to be able
to install arbitrary click packages not from the store. In which case,
you are root, and have a phone you can just walk off with anyway.

Signatures aren't to prevent users/developers from being dumb when
rooting their phones and installing arbitrary click packages.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Hammerhead not turning screen on

[Rodney Dawes]

On Wed, 2014-06-25 at 15:14 +0200, aleksandar jevtic wrote:
> Having problem on latest images with hammerhead. Booted succesfully
> (utopic-proposed #96) and when phone or user turns the screen off  and
> try to turn it back on nothig happens screen is still black. However
> when phone is charging this problem does not occur.
> Need some help to point me to right direction.
> Thanks.

Yes, this has been happening since around image #71. Unless you have
enough understanding of the power management code and hardware, I'm not
sure there is anything you can do. I've flashed to image #50 from devel
channel and disabled automatic download of system images on my phone,
until this can get fixed.

(Also, you don't need to send the same e-mail multiple times to get an
answer. :)


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Tue, 2014-06-24 at 09:29 +0100, Matthew Paul Thomas wrote:
> One problem with this approach is that users wouldn't be able to make
> an informed decision. What would be the harm of saying yes? Less
> battery life, but how much less? Nobody would know.

This is my main problem with the current app lifecycle design. It
doesn't allow a user to have control over whether they use more or less
battery life. We're trying to provide a chastity belt for it, and never
giving the choice. Yes, if I go running, or biking, or hiking, or
driving around, and use certain apps to do data logging or other things,
my battery might not last as long. But I also can plug my phone into the
charging port in my car, or put a generator on my bicycle, or build a
kinetic generator to use when running, to help balance the extra usage.

It's fine if my app that uses extra battery is confined, and that a
notice of extra power consumption is presented to the user when it is
installed, but there needs to be a way for me to provide a background
process which can run all the time if necessary, to do certain things.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Mon, 2014-06-23 at 09:12 +0200, Thomas Voß wrote:
> > IRC and messaging platforms not covered by "Online Accounts"
> 
> Push notifications FTW, they provide an easy and straightforward way
> out of the lifecycle trap.

Push notifications are totally the wrong solution for IRC/IM services.
At that point, you've relegated the benefit of using IRC/IM to building
a complex system to essentially do SMS. As far as users are concerned,
it would be far less hassle for them to just send an SMS.

> > Other things to which I'm not currently thinking to but that may be useful
> >
> >
> > The current approach is to use system services to achieve the results: this
> > is what happens with music and messaging apps. The problem with this
> > approach is that we may end up with the need to create really many services
> > and still not cover all the needed requisites. On the other hand we may just
> > deny the developers and the users to create and use certain kind of apps.
> > The advantages of not allowing background services are mainly longer battery
> > life and better overall performances.
> >
> 
> Sure, and I would like to add security and privacy on top: Any app or
> service running in the background can easily spy on the user. The
> flashlight-app on Android harvesting a user's location is one of the
> prominent examples why this is an actual issue (see [1]). Not having
> ordinary app's or their services (intents) running in the background
> helps a lot in establishing and maintaining a clean state.

Let's not conflate the lack of confinement on Android, with background
services being able to do things. Even without background services,
there is absolutely nothing preventing me from writing a flashlight app
on Ubuntu, which sends your location to some server when it runs. It
might not do it persistently, but does it matter? Let's also not try to
be nannies to every possible "bad app" situation. Even with confinement,
and the app lifecycle, there are thousands of malware things I could do
in my app. If we limit things too much, developers won't want to build
apps on our platform, simply because they can't do what they need to do,
and users won't want to use our platform, simply because they can't do
what they need to do. Security and privacy are important, but removing
the user's freedom and free will in pursuit of them, will get us
nowhere.

> We are about to implement this feature for system services. For app
> services, this trust model does not hold as you cannot force an
> application author to prompt the user for trust.

For a background service to work, the confinement implementation could
require appropriate entries in the click package manifest, and the
information could be presented at install time, or when the app is first
run, by the system, and not by the app or service itself.

> > could be autokilled/paused when battery life is low (this approach is the
> > one used by Samsung, Google Drive, Dropbox) but should still allow the user
> > to resume the service if he/she needs it even on low battery
> > could be paused/resumed according to the number of running apps and services
> >
> 
> We can certainly come up with a lot of interesting heuristics, infer
> information from usage patterns of the phone etc.. However, they are
> still heuristics and we would loose a very important property of the
> system: Predictable battery life & secure system behavior, no matter
> what applications are installed on the phone.

There is no such thing as predictable battery life. Arbitrary external
factors even play with battery life. There is absolutely no way you can
reliably predict battery life in the real world. The best we can do is
replicate testing conditions of say the Nexus 4, and hope to achieve
similar or better battery life in those same conditions, when running
Ubuntu instead of Android; or on a phone of similar battery capacity
with similar hardware, that is shipped with Ubuntu from the factory.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 11:55 +0200, Rasmus Eneman wrote:
> Other cases are Spotify and Grooveshark, neither which can use a
> generic service. We already have one Spotify app,  that only plays
> when opened, which means that it is useless. 

This is just a bug as a result of them being webapps. Once Oxide (and
thus the browser, and webapp-container) has support for streaming the
audio through the persistent media player backend, then these should
work fine as webapps.

If they were native apps pushing the audio through the backend instead,
it should already work today (ie, the same way the Music app itself
works).





-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 11:21 -0400, Marc Deslauriers wrote:
> It most certainly matters. The amount of applications in the Android store 
> that
> were created _specifically_ to generate revenue from user tracking is
> staggering. Having the flashlight app only be able to do it when it is in the
> foreground removes the incentive to have this sort of malware in the first 
> place.

I didn't say it didn't matter. But it only matters to a point. There are
so many things that I want to write apps for on Ubuntu, but the design
of confinement and lack of background processing, just makes it
impossible to do. Adding system services for some things isn't going to
change this situation for me. A large number of the things don't make
sense as system services.

>  Let's also not try to
> > be nannies to every possible "bad app" situation.
> 
> This is exactly what we need to do, else we're going to end up with a store 
> full
> of malware. We have the opportunity to do things right at the moment, and we
> need to draw some hard lines on what is allowed and what is not.

Our store is going to have plenty of malware in it if our platform
becomes as popular as Android. No matter what we do in terms of
confinement. The only way to not have any malware at all, is to not have
any apps.

>  Even with confinement,
> > and the app lifecycle, there are thousands of malware things I could do
> > in my app.
> 
> Please be specific, so we can fix these issues right away.

They are not fixable in any way that is meaningful to users. If we were
to confine apps that use location data such that they can't talk to the
network, then that immediately prevents anyone from writing any mapping
applications for example. If I want to write a game that mines for
bitcoins on your CPU in the background while you're playing the game,
there's no way for us to confine it. Maybe we implement CPU usage quotas
so that any one app can't use over N% of the CPU, but it doesn't prevent
the possibility of doing such an action. Games are a great place to do
these things in Ubuntu, because they require the user to constantly be
tapping the screen while playing them; which keeps the screen alive, and
the process running. Or my game could use your Twitter account from
online accounts, and start spamming your followers with your current
score in the game.

Some of these things are just not going to be hard to do if we're going
to allow any sort of reasonable development of apps on our platform.
Others we might be able to have clever confinement stories for, to make
it harder for developers to exploit. But in general, I think we should
let the ratings and reviews system in the store take care of this. If an
app does too much and kills batteries fast, users will write bad
reviews.

What we need is a good permissions handling story that doesn't destroy
the UX of actually using the platform and any apps on it, so that if say
a flashlight app is grabbing the location, the user can know about it.
The story here in Android and iOS is generally bad, because they don't
provide fine grained control over things, and require apps to request
all permissions to do some things. If we can provide fine-grained
control, and require capabilities to be listed in the click manifest for
the app's package, we can provide an appropriate UX which is not
overbearing, or horribly incorrect, for the user.

>  If we limit things too much, developers won't want to build
> > apps on our platform, simply because they can't do what they need to do,
> > and users won't want to use our platform, simply because they can't do
> > what they need to do. Security and privacy are important, but removing
> > the user's freedom and free will in pursuit of them, will get us
> > nowhere.
> 
> Sure it will, it will get us to the point of being the platform people want to
> use because their phone is fast and has great battery life from not running a
> zillion background services.

Or a platform people won't bother using, because they can't use it for
the useful things they do, which iOS and Android to allow them to do.
Just because iOS/Android have app stores that have a hundred thousand or
more malware apps, doesn't mean the majority of users are using those
apps daily or that iOS and Android don't have users. 

> It's not about allowing everything, it's about finding innovative solutions to
> enable everything app developers want without compromising on security and 
> privacy.

We don't need to allow everything, but we shouldn't block everything,
either. I'm all for security and privacy, but not at the expense of
actually being able to use my phone for all the things I need to do. 

> Contrary to other platforms, ours is open...anyone can help write the 
> functions
> of the core os. If we need an IRC background service, for example, let's allow
> developers to contribute to the blessed one that we can ship as part of the OS
> instead of simply allowing arbitrary apps to run arbitrary background 
> ser

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 18:34 +0200, Benjamin Zeller wrote:
> Am 25.06.2014 18:31, schrieb Rodney Dawes:
> > On Wed, 2014-06-25 at 11:55 +0200, Rasmus Eneman wrote:
> >> Other cases are Spotify and Grooveshark, neither which can use a
> >> generic service. We already have one Spotify app,  that only plays
> >> when opened, which means that it is useless. 
> > This is just a bug as a result of them being webapps. Once Oxide (and
> > thus the browser, and webapp-container) has support for streaming the
> > audio through the persistent media player backend, then these should
> > work fine as webapps.
> >
> > If they were native apps pushing the audio through the backend instead,
> > it should already work today (ie, the same way the Music app itself
> > works).
> Just playing the stream over the backend won't be enough for
> Grooveshark at least, looking at the API they won't the app to send
> messages after 30secs and at the end of a song.
> 
> Can something like that be done as well?

I guess that would require a special case background service then. I
haven't looked at their API. If it requires the client to ping it every
30 seconds, then I don't think it can be done with the current system
(though I don't know the exact details of how the backend works).


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 13:23 -0400, Marc Deslauriers wrote:
> So I gather you have the same problem on iOS, as much of the same limitations
> exist there?

I don't now, nor have I ever, owned any iOS devices. Nor have I
developed any apps for them. I do know that the types of apps I want to
write, do exist on iOS though, so clearly there must be some way to run
background services on iOS, even if it simply means that an app with
full UI is running in the background.

For example: http://www.innovatemotorsports.com/products/ot2.php

This app supports logging and performance metrics. Surely they don't
expect the user to tap the screen every 5 seconds to keep it alive,
while also trying to drive a car at its peak performance on a race
track.

So how is iOS enabling apps with requirements for background processing
like this?


> I disagree with that. The Android store contains a massive amount of malware, 
> in
> contrast to the Apple store which contains very little. The difference is that
> Apple performs manual reviews for apps, apps have very little control on what
> they can do in the background, and they are very confined. Android's automated
> app approval process that basically allows every app to request any 
> permissions
> is the problem.
> 
> I believe our solution is better than that. Our app approval process is
> automated if you use the default confinement policy groups. If you need
> something more, you then need to go through a manual review / partner 
> agreement,
> etc. This should allow us to get the benefits of the Android app submission
> process, with the security of the Apple store.

Apple also only support a very limited set of hardware, and have a high
rejection rate, even for legitimate apps. They have a stricter set of
rules about how an app is submitted to the store, and not simply a
stricter set of rules for how the app is run on the device. The
combination of the two certainly leads to less malware, and I'm not
proposing that we simply throw confinement out the window. But we need a
reasonable balance, which doesn't require developers to deal with
partner agreements and building a system service that ends up in the
images.

Like the balance we're trying to achieve with submission approvals, I
think we need an appropriate balance for background services.

> Sure, but that can't happen once the app is no longer in the foreground. I do
> understand that a game can steal your cpu cycles while you're playing, but,
> honestly, that isn't much of a threat, IMHO.
> 
> As soon as you enable an app to run in the background, that becomes a much 
> more
> important threat.

I don't think it's more important. I think they are equally important.
And I think the user should be allowed to make a decision on how
important they think it is. The main issue should be how we expose that
decision to the user.

> > The story here in Android and iOS is generally bad, because they don't
> > provide fine grained control over things, and require apps to request
> > all permissions to do some things. If we can provide fine-grained
> > control, and require capabilities to be listed in the click manifest for
> > the app's package, we can provide an appropriate UX which is not
> > overbearing, or horribly incorrect, for the user.
> 
> This is why we are using trusted helpers, they allow the user to transparently
> grant fine-grained permissions with context. When they can't be done
> transparently, for example, granting access to your location, they can still 
> be
> done when required providing the user with context.
> 
> There is no good way of displaying or asking security relevant questions to a
> user when an app is in the process of being installed.

There is no designed way of displaying that information to the user
currently. It however, is totally possible for any information about
those permissions in the click package, to be indexed by the store, and
it would be possible for the click scope to show that information, in
the app details, and in a confirmation page when the user clicks
Install.

> I'm sorry, but AFAIK, iOS has very limited background service capabilities, 
> and
> it seems to be doing just fine. That is the model we should be looking at, not
> the Android model.

> How would you write those apps for iOS?

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20

Apps can have long-running background tasks for certain things, on iOS.
I suppose their manual validation of submissions to the store checks
against their list of allowed things for this case. I'm not sure how we
could automate such checks though, but it could be possible for us to
run an app inside a confined sandbox with some virtual bluetooth things
exposed to the sandbox, to see what the app is doing, and flag for
manual review if it tries to do something outside that scope. Or we
cou

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 15:31 -0300, Sergio Schvezov wrote:
> Apps that implement these services must declare the services they support 
> and use system frameworks to implement the relevant aspects of those 
> services.

This doesn't mean that Apple provides a system background process to
read the data and log it where the app wants to log it, though. It means
the app can continue running indefinitely.

I'm not sure what "use system frameworks" means exactly here though, as
I can't immediately think of how one would write an iOS app that
monitors a stream of data from a bluetooth device, without using the
system bluetooth/serial APIs. It is not clear from the long-running
process docs there, what "system framework" means exactly in that
context.




-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
> On 14-06-25 02:11 PM, Rodney Dawes wrote:
> > On Wed, 2014-06-25 at 13:23 -0400, Marc Deslauriers wrote:
> >> So I gather you have the same problem on iOS, as much of the same 
> >> limitations
> >> exist there?
> > 
> > I don't now, nor have I ever, owned any iOS devices. Nor have I
> > developed any apps for them. I do know that the types of apps I want to
> > write, do exist on iOS though, so clearly there must be some way to run
> > background services on iOS, even if it simply means that an app with
> > full UI is running in the background.
> > 
> > For example: http://www.innovatemotorsports.com/products/ot2.php
> > 
> > This app supports logging and performance metrics. Surely they don't
> > expect the user to tap the screen every 5 seconds to keep it alive,
> > while also trying to drive a car at its peak performance on a race
> > track.
> > 
> > So how is iOS enabling apps with requirements for background processing
> > like this?
> 
> AFAIK, iOS 4 allowed an app that was in the foreground to run in the 
> background
> for a few minutes to finish processing. I think it used to be 10 minutes, and
> was reduced with iOS 7 to improve battery life.
> 
> In this case, isn't the app simply running in the foreground?

No. It means the app is running, whether it is in the foreground or
background. It doesn't need to be the current foreground app. Running
apps, the automotive data logging app I linked, etc… continue running
even in the background, to be able to monitor location, log performance
data from BT/ANT+ devices, and perform actions based on location or the
data stream from a connected device.


> > There is no designed way of displaying that information to the user
> > currently.
> 
> Hum? That is what trusted helpers do. When an app wants to access the user's
> location, there is a prompt which asks for permission. That's what the trusted
> prompt session work in Unity 8 is about.

That is not installation time. My reply was following the context. :)

>  It however, is totally possible for any information about
> > those permissions in the click package, to be indexed by the store, and
> > it would be possible for the click scope to show that information, in
> > the app details, and in a confirmation page when the user clicks
> > Install.
> 
> That is the exact thing we're trying to avoid. Users aren't able to either
> understand or make informed decision when they hit confirmation pages,
> especially during installation. The Android model is broken, let's not 
> emulate it.

Why are they not able to understand or make informed decisions? Do we
have actual user testing and psychological analysis data for this? Or
are we just assuming that is the case because the way Android does
things lacks fine grained or meaningful descriptions of what an app
needs, and that people have just gotten used to apps having to request
access to everything, and thus ignore the meaning of what it is asking?
You know, much in the same way that users don't read license agreements
or terms of service, and just automatically click through the process to
get it over with?

I agree that the habits are bad, but bad habits do not indicate the
inability to understand or make an informed decision. It certainly does
not mean we can't work to provide meaningful information at the point of
looking through the app store, or during installation, either.

> >> I'm sorry, but AFAIK, iOS has very limited background service 
> >> capabilities, and
> >> it seems to be doing just fine. That is the model we should be looking at, 
> >> not
> >> the Android model.
> > 
> >> How would you write those apps for iOS?
> > 
> > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
> > 
> > Apps can have long-running background tasks for certain things, on iOS.
> 
> Apps can only run in the background for a limited time, and they can use 
> certain
> APIs to get woken up regularly, but they can't run in the background save for 
> a
> few exceptions. This is why IRC apps on iOS disconnect after a few minutes, or
> are designed for jailbroken devices.

No, apps can run in the background indefinitely, per the documentation
link I provided above, in order to handle a situation in the specific
list of situations described in that documentation. Skype does not
automatically disconnect after a few minutes. And AFAIK, it does not
need to remain in the foreground to sta

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 13:23 -0600, Selene Scriven wrote:
> I'd very much like it if we put control over this in the end 
> user's hands, and give them the ability to override obnoxious 
> decisions made by the app developers.  I really don't want 
> Facebook running in the background, pinging the server every few 
> minutes...  I just want it available on demand for the rare times 
> I need to use it on the go.  And the same goes for pretty much 
> everything else on the phone.

How you want to use the phone, and h ow I want to use the phone are
different though. Which is why that decision needs to be in the user's
hands. Having the platform take a hard line stance on that one way or
the other is bad. It's bad on Android because there is no regulation on
what apps take advantage of the ability to have background processing.
It's bad on Ubuntu (currently) because there is no way to have an app
that needs specialized background processing.

As for Facebook, you don't have to worry about the Facebook app doing.
The Friends app does all the pinging for you. ;)



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 17:10 -0300, Sergio Schvezov wrote:
> On miércoles 25 de junio de 2014 16h'29:10 ART, Rodney Dawes wrote:
> > On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
> >> On 14-06-25 02:11 PM, Rodney Dawes wrote: ...
> >
> > No. It means the app is running, whether it is in the foreground or
> > background. It doesn't need to be the current foreground app. Running
> > apps, the automotive data logging app I linked, etc… continue running
> > even in the background, to be able to monitor location, log performance
> > data from BT/ANT+ devices, and perform actions based on location or the
> > data stream from a connected device.
> 
> Please take the time to read the full length of the document I linked to.
> 
> In there you will see that most of the stuff is in progress of being 
> implemented; For location you want to tie into the equivalent of the 
> location service and tell it to wake up every x distance; similarly done 
> for other services.

No, I don't want a geofence. I want it to wake up whenever there is a
change from the location service. The same way it works in iOS.

For monitoring a data stream from a bluetooth device for example, I'd
want my app to be waked whenever new data is delivered to the socket,
and for my app to have sufficient time to process that data before being
suspended again.

> iOS does kill your app (as described in the documentation) and the user has 
> the illusion of it still running thanks to the provided services.

No, it suspends the app, and wakes it when necessary. It is only
actually killed if no background processing is happening.

With the way we are suspending apps that are not in the foreground, we
could do the same waking when needed that iOS does for those apps.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 15:39 -0400, Marc Deslauriers wrote:
> That's not how bluetooth devices work on iOS. If your app is in the 
> foreground,
> you can get realtime events. If your app goes to the background and gets
> suspended after a couple of minutes, your BT device needs to accumulate data 
> and
> send it periodically at which point iOS will start up your application in the
> background for a maximum of a few seconds just long enough to receive and
> process it.

It is how bluetooth devices work in iOS, according to the docs. The
system wakes the app when a backgrounded app needs to process data from
the bluetooth device. It does not require any special buffering to be
implemented in the device.

See
https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html#//apple_ref/doc/uid/TP40013257-CH7-SW6


>  I'm sorry, but AFAIK, iOS has very limited background service 
>  capabilities, and
>  it seems to be doing just fine. That is the model we should be looking 
>  at, not
>  the Android model.
> >>>
>  How would you write those apps for iOS?
> >>>
> >>> https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
> >>>
> >>> Apps can have long-running background tasks for certain things, on iOS.
> >>
> >> Apps can only run in the background for a limited time, and they can use 
> >> certain
> >> APIs to get woken up regularly, but they can't run in the background save 
> >> for a
> >> few exceptions. This is why IRC apps on iOS disconnect after a few 
> >> minutes, or
> >> are designed for jailbroken devices.
> > 
> > No, apps can run in the background indefinitely, per the documentation
> > link I provided above, in order to handle a situation in the specific
> > list of situations described in that documentation. Skype does not
> > automatically disconnect after a few minutes. And AFAIK, it does not
> > need to remain in the foreground to stay on a call.
> 
> No, but they need to use the services provided by iOS, they can't just run in
> the background. This is what we want to do also.

The services in iOS are generic framework services. There is no OBD-II
service for example. There is simply the core bluetooth service, and it
handles the waking of the app and passing the data to it. The support
for background processing is clearly documented in the iOS App
Programming Guide. It does not require implementing a new type of
service to handle new types of data over USB or Bluetooth. The
statements from this and other threads implies though, that one would
have to implement new system services for such things, on Ubuntu.

If however, we implement something in the same way that iOS implements,
I am fine with that. I don't need a separate process to do background
processing. I just need the app to be waked and handed the data when it
is appropriate to do so, without me having to get a new system service
written and shipped on the image, in order to do what I need.

> > 
> > Maybe the app with full UI needs to remain open always on iOS, and there
> > are not actual separate background processes without UI, but they do not
> > need to remain in the foreground to remain processing.
> > 
> 
> Perhaps you should tell the developers of all the iOS IRC apps how to make 
> their
> application run in the background:
> 
> http://colloquy.info/project/wiki/MobileFAQs#CanIrunMobileColloquyinthebackground
> 
> http://www.macworld.com/article/1153252/linkinus_irc_iphone.html
> 
> http://www.appannie.com/apps/ios/app/limechat-irc-client/

I don't know what those apps are doing exactly for creating a
connection, but prior to iOS 7 at least, I don't think "IRC" fit into
any of the acceptable long-running background tasks allowances. As of
iOS 7, it seems to fit under the "Fetching small amounts of content
regularly" as documented in the iOS App Programming Guide. To quote the
guide:

Fetching Small Amounts of Content Regularly
In iOS 7 and later, an app that retrieves content regularly from the
network can ask the system for background execution time to check for
new content. You enable support for background fetches from the
Background modes section of the Capabilities tab in your Xcode project.
(You can also enable this support by including the UIBackgroundModes key
with the fetch value in your app’s Info.plist file.) At appropriate
times, the system gives background execution time to the apps that
support this background mode, launching the app directly into the
background if needed. The app object calls the
application:performFetchWithCompletionHandler: method of its app
delegate to let you know when execution time is available.

When the application:performFetchWithCompletionHandler: method of your
delegate is calle

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 13:40 -0700, Alex Chiang wrote:
> >> > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW20
> >> >
> >> > Apps can have long-running background tasks for certain things, on iOS.
> >>
> >> Apps can only run in the background for a limited time, and they can use 
> >> certain
> >> APIs to get woken up regularly, but they can't run in the background save 
> >> for a
> >> few exceptions. This is why IRC apps on iOS disconnect after a few 
> >> minutes, or
> >> are designed for jailbroken devices.
> >
> > No, apps can run in the background indefinitely, per the documentation
> > link I provided above, in order to handle a situation in the specific
> > list of situations described in that documentation.
> 
> No -- iOS apps do not *actually* run in the background indefinitely.
> This is trivially observable on an iPhone.

Running indefinitely != "in the low level running state for an
indefinite period." Running indefinitely means it has an active PID, and
it might be in sleeping, stopped, or running states. For example, open
top and you'll see that most processes, including the daemons in the
background, are in the sleep (S) state, even on a massive i7 workstation
where battery life isn't an issue. Running doesn't mean it's consuming
energy. It just means it is in memory.

> - start Strava (GPS app to track your running/cycling data)
> - launch the camera in HDR mode, take a photo of the awesome scenery
> - load Google Maps app to figure out your next turn
> 
> Go back into Strava and observe that it has been killed by the OS.
> Strava will ask you if you wish to resume recording from last known
> point.

Do you have the source code to Strava? Is it open source?

Do you want to buy me an iPhone 4S and a Macbook so I can actually build
an iOS app and test it against what the documentation says?

My only reference is the documentation. I can't tell you how a specific
proprietary app that was probably contracted out to a random "build a
random iOS app" development house works, but I can tell you what the
documentation says to me.

>From your statement about how Strava behaves, it sounds to me like it is
not registering for background processing to the location service,
according to what the documentation about long-running background
processing and the location service on iOS, says.

If you want to send me an iPhone 4S and a Macbook though, I'm happy to
investigate further by writing an app for iOS and testing it against the
documentation. But I have no way to write such an app without a Mac, or
test it without an iPhone, or at least an iPod (assuming the iPod has
the same level of GPS and bluetooth capabilities of the iPhone).

I'm pretty certain the Ubuntu One music streaming app for iOS continued
streaming audio as a background process though, and did not need the
screen on or to be the foreground app the user was fiddling with, for
streaming to work. And not because it was a single URl that was
constantly sending data that some system process was listening to.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Wed, 2014-06-25 at 17:10 -0300, Sergio Schvezov wrote:
> On miércoles 25 de junio de 2014 16h'29:10 ART, Rodney Dawes wrote:
> > On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
> >> On 14-06-25 02:11 PM, Rodney Dawes wrote: ...
> >
> > No. It means the app is running, whether it is in the foreground or
> > background. It doesn't need to be the current foreground app. Running
> > apps, the automotive data logging app I linked, etc… continue running
> > even in the background, to be able to monitor location, log performance
> > data from BT/ANT+ devices, and perform actions based on location or the
> > data stream from a connected device.
> 
> Please take the time to read the full length of the document I linked to.

The Apple doc? It clearly indicates to me that long-running background
processes remain running.

I think maybe there is some confusion in this thread about what
"running" means. A sleeping/stopped process is still running and has a
PID. A killed process is not running. Apps which do not register
themselves as long-running background processes will certainly be
stopped indefinitely, or killed on iOS.

However, it is not clear to me if iOS is actually stopping processes, or
if they are just sleeping and waiting for the main loop to send an
event, when they are registered for long-running background processing.
It is clear that it does wake the process and call a callback in that
process, depending on the task it is registered for, though.




-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Thu, 2014-06-26 at 08:08 +0200, Thomas Voß wrote:
> Hmmm, I see some problems here: I don't think a user starting a
> torrent app on the phone is a strong indication of the user wanting to
> waste battery life and his/her cellular data plan. I think the user
> can rightly expect the system to transparently take care of scarce
> system resources like:
> 
>   * power
>   * cpu cycles
>   * gpu cycles
>   * memory

And yet my laptop still gets 6+ hours of battery life, despite it being
an i7 CPU with 8GB of RAM and a 1080p screen. We still need to care
about power management and wasting of CPU/memory on these platforms as
well.

There's also the problem of convergence and how this will function on
the "Internet of Things" devices, where every app is a background
process that needs to run forever (like apache and dnsmasq). There is no
foreground there. Or are we going to re-implement inetd to manage
whether those services are running or not? 

> On top, I don't think that each and every single app out there
> requires sophisticated background processing to be immediately useful
> to the user. The entire conversation in this thread focuses on that
> one part of the app lifecycle and we spent quite some time and thought
> to present a solution that keeps *most* users and *most* developers
> happy. On top, the presented solution of system-provided services is
> meant to grow over time based on the feedback we receive from users
> and developers, and we can get started adjusting/identifying services
> right now.

Nobody is saying every single app needs sophisticated background
processing to be useful to the user. However, the ones I want to write,
do in fact, need it. Is there any actual documentation on how this
magical system services plan will actually work when it arrives at some
arbitrary point in the future? I've seen NO documentation linked in this
thread about it, but there has been plenty of claim to its greatness.
How can I actually see documentation of how it is supposed to work, and
provide feedback on it to make it better for all developers?

> The other point I want to make: Being strict about the app lifecycle
> is surely difficult and takes time and thought. But it allows us to
> evolve the platform. Along that lines, just opening up the world to
> apps to do whatever they want is not maintainable over time as you
> usually cannot take back any sort of functionality that you once
> committed to.

While we surely cannot be too lenient on app confinement, there is such
a thing as being too strict. Just ask anyone who has ever raised a
teenager. We need proper balance, and right now the use of STOP/CONT
signals to pause/resume an app and prevent it from processing feels like
a workaround to bad UX (it's currently incredibly hard to actually kill
apps on Ubuntu touch) and the use of qmlscene as a production service
(it's only meant to be a development tool).



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Thu, 2014-06-26 at 16:09 +0200, Thomas Voß wrote:
> I assumed that you know:
> 
> https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#heading=h.28drra4u9knx
> 
> given that the document has been around for quite some time now, and
> has been referenced multiple times in other mail threads on this list.
> It might not contain all of the details you are after, but it gives a
> very good overview of the design that we implemented. There are also
> multiple UOS sessions available from youtube. Anyway: I'm happy to
> iterate on the document and adjust it if concrete points are missing.

No, I didn't know about this doc. However, it doesn't actually describe
anything about what system services will exist or how they will
function. The only information about background tasks in that doc is a
very short list of a few very specific use cases that might need
background processing.

> See my comment before. Also: We already put a bunch of background
> services in place, an updated version of the location service is about
> to land. Push notifications are well on their way, too. With that, and
> given the numerous updates by individual teams being reported to the
> mailing list, I wonder what else would help in terms of documentation?
> I agree that it would be great to have complete SDK and API docs
> available and any help is appreciated to reach that point. And feel
> free to reach out to me on irc.

Where are these services and how apps are expected to use them,
documented? I don't need complete SDK/API docs at this point, but a
general overview of how we expect this to look and function on a
technical level would be nice to see.

> Sorry, but I think you are ignoring the arguments that multiple people
> have presented in this mail thread. We have pointed out that we are
> well aware that we are taking a somewhat conservative and strict
> choice to ensure predictable battery life and performance. None of the
> alternative approaches presented in this thread qualify for
> predictable battery life and performance, they all focus on solving
> the perceived issue of a lack of flexibility for application
> developers.

I am not ignoring any arguments. But "predictable battery life" is not
an argument. Battery life is  unpredictable. There are way too many
variables to predict battery life. Battery life can only be predicted in
a controlled environment. Long running tests of minimal usage and very
heavy usage, combined to find the average, will give you an average
expected battery life on a particular piece of hardware, which is used
for marketing and declared an estimate in those materials. Beyond that,
you will have no idea what sort of battery life I will get on my phone.
There are way too many variables for you to make any reasonable guess.
Where I live on the planet, how many calls I make, how I travel, how I
carry my phone, what accessories I connect to my phone, what apps I use,
how often I use them, etc… all have an impact on what the battery life
of my phone will be. Yes, if I have 30 apps running in the background
all actively doing things, it's going to be bad. But it's also going to
be bad if I spend 4 hours straight actively playing one game. Arguing
about battery life isn't something that will provide a solution to any
actual problem.



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Thu, 2014-06-26 at 14:36 +0200, Michael Zanetti wrote:
> I'd also be fine if this question only pops up if the user has qualified as 
> power user (e.g. a setting to enable this advanced stuff) and just decline it 
> automatically for non tech savvy people.

This won't work. Any setting which is "let me do more stuff" will
consistently be enabled by users, even when they have no idea what to do
with the extra stuff. Power user settings have been shown in usability
studies to be a bad choice. If we need settings, we're doing it wrong.


-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Background services: a problem that we need to face

[Rodney Dawes]

On Thu, 2014-06-26 at 07:50 +0200, Thomas Voß wrote:
> On Wed, Jun 25, 2014 at 11:17 PM, Rodney Dawes
>  wrote:
> > On Wed, 2014-06-25 at 17:10 -0300, Sergio Schvezov wrote:
> >> On miércoles 25 de junio de 2014 16h'29:10 ART, Rodney Dawes wrote:
> >> > On Wed, 2014-06-25 at 14:44 -0400, Marc Deslauriers wrote:
> >> >> On 14-06-25 02:11 PM, Rodney Dawes wrote: ...
> >> >
> >> > No. It means the app is running, whether it is in the foreground or
> >> > background. It doesn't need to be the current foreground app. Running
> >> > apps, the automotive data logging app I linked, etc… continue running
> >> > even in the background, to be able to monitor location, log performance
> >> > data from BT/ANT+ devices, and perform actions based on location or the
> >> > data stream from a connected device.
> >>
> >> Please take the time to read the full length of the document I linked to.
> >
> > The Apple doc? It clearly indicates to me that long-running background
> > processes remain running.
> >
> 
> Okay, let's take a look at the iOS documentation:

> The background execution state is not a persistent state, it is a
> transitional one, with "Suspended" (a.k.a. SIGSTOP'd) being the usual
> follow-up state. Also note that the system reserves the right to
> transition apps from "Background" to "Suspended" or even "Killed" at
> any time. The grace period that apps can request cannot be extended
> indefinitely. Obviously, both iOS and Ubuntu try to keep as many apps
> as possible in the "Suspended" state to ensure fast resurrection
> (i.e., SIGCONT) of apps. However, in the case of Ubuntu, if memory
> pressure arises, the oldest suspended apps are automatically killed.

No. There are TWO levels of background state on iOS. There is the
short-term background processing state, which is what you're talking
about. There is also a long-term background processing state. Please
read the FULL documentation there, and not only the first paragraph. In
particular see this section:

https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html#//apple_ref/doc/uid/TP40007072-CH4-SW24

It explicitly states that apps declare in advance that they use
long-running background tasks. When declaring one or more of the
background modes as documented in this section, the app is continually
running, or waked from the sleep state, in order to process such events.
These apps are not shoved into STOP and left there until the user brings
the app back to the foreground, nor are they arbitrarily killed (unless
there are extenuating circumstances that might require it). The apps are
live and have plenty of time to process things before being put back to
sleep state. On iOS, the app can even see how much time it has left
before being killed, and can request more time when processing in the
background.

> Please also note that our lifecycle explicitly states: We only
> guarantee an app to be running while it is in the foreground. If it is
> in the background, it may or may not be running. This is exactly the
> same contract between the apps and the system as on iOS. Sure, we
> might think about extending grace periods before suspending an app,
> but we are free to do so as we did not, should not and will not give
> any guarantee on the amount of resources granted to an application
> running in the background.

It is not exactly the same contract as iOS. It is similar. The contract
in iOS depends on what the app declares it needs, in advance. I've also
seen no evidence that iOS actually uses STOP/CONT for background
processes in this case. The documentation says "sleeping" or "suspended"
but does not clarify what that means exactly. Given the list of items
under "Being a Responsible Background App" though, it seems this is more
likely to be the "Sleeping" state and not SIGSTOP.

> The difference between sleeping and stopped is significant, though.
> Sleeping means cooperation by app authors which we cannot assume.
> Stopped can be and is enforced by the system according to our
> lifecycle state machine.

Sleeping can be enforced somewhat by creating CPU quotas, and it is
possible to examine apps for bad behavior in a sandbox during automated
review. It simply requires the effort to do so.  If we can reliably wake
from SIGSTOP and have the app respond to callbacks, it doesn't matter to
me if it's actually sleeping or STOP though. The important part here is
that the app is waked by the system service, has its registered callback
run in its event loop, and that it can request more time to

Re: [Ubuntu-phone] Building Hammerhead Kernel

[Rodney Dawes]

Hi,

I just saw these mails, but is there any reason you're trying to go
about flashing this device the hard way? There are already images built
for hammerhead, which you can install using an alternate server as
described on the wiki page:

https://wiki.ubuntu.com/Touch/Devices#Server_at_http:.2BAC8ALw-system-image.tasemnice.eu

Not trying to discourage. Just curious as to what you're doing. There is
an issue with the latest builds, where the screen does not unblank when
pressing the power button, after the phone has been removed from the
charger, and could use some help with getting fixed, if you have enough
knowledge to figure the issue out.



On Fri, 2014-06-27 at 17:20 -0400, David Peter wrote:
> Ok ok still shenaniging... Obviously I need to learn about
> meta-package.
> I guess that I have to create a kernel meta package like the one
> downloaded from rsalveti's ppa.
> 
> I won't give up :)
> 
> 
> On Jun 26, 2014 1:28 AM, "David Peter" 
> wrote:
> Getting closer
> 
> 
> Method inline building modifying
> device/lge/hammerhead/BoardConfig.mk with:
> TARGET_KERNEL_UBUNTU := false
> 
> adding
> TARGET_KERNEL_CONFIG := hammerhead_defconfig
> TARGET_KERNEL_SOURCE := kernel/lge/hammerhead
> 
> and
> BOARD_KERNEL_IMAGE_NAME := zImage-dtb
> 
> 
> I have a dtb kernel, now recovery is working. Ubuntu Touch
> still does not boot.​
> ​ Checking the installed-files.txt compared to the one coming
> from the prebuilt kernel it
> 
> sounds like the only missing stuff now
> are /system/lib/modules/3.4.0-1-hammerhead/​
> ​ libs.
> ​
> 
> 
> 
> 
> 
> 
> On Thu, Jun 26, 2014 at 12:00 AM, David Peter
>  wrote:
> Hi Guys,
> 
> I feel like playing with the Hammerhead Kernel
> 
> 
> I have figured out how to build the project:
> 
> https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b 
> phablet-4.4.2_r1 
> then flash my hammerhead using rootstock-touch-install
> and a daily image. So far so good.
> 
> 
> 
> Next, what do I have to do with the kernel sources
> project
> https://code-review.phablet.ubuntu.com/ubuntu/kernel/trusty 
> -b hammerhead ?
> 
> 
> 
> I have tried 3 ways:
> 
> 
> 1) building kernel in tree
> 
> - copy the kernel sources to kernel/lge/hammerhead
> 
> - modify device/lge/hammerhead/BoardConfig.mk
> 
>   in order to make TARGET_KERNEL_UBUNTU := false
> 
>   and add TARGET_KERNEL_CONFIG := hammerhead_defconfig
>TARGET_KERNEL_SOURCE :=
> kernel/lge/hammerhead
> 
> 
> 
> --> built kernel image smaller than the prebuilt one
> from rsalveti PPA (I guess it is a dtb story). Nothing
> will work
> 
> 
> 2) building kernel in tree with cyanogenmod
> BoardConfig.mk
> 
> 
> --> built kernel image sizing the same as the prebuilt
> one from rsalveti PPA (a dtb one by the way). Recovery
> works, Ubuntu-Touch won't boot though
> 
> 
> 
> 3) building myself the kernel sources
> 
> export ARCH=arm
> export SUBARCH=arm
> export CROSS_COMPILE=arm-eabi-
> make hammerhead_defconfig
> make
> 
> 
> ... no result yet, it was still building when I
> dicided to write this email as I don't know what to do
> next.
> 
> 
> 
> 
> 
> 
> What is the proper way to build the kernel and to
> produce the img boot recovery and system files?
> 
> Can you give me some guidelines?
> 
> 
> 
> 
> I am keeping notes of that process and will suggest a
> wiki update.
> 
> 
> Regards
> 
> David
> 
> 
> 



-- 
Mailing list: https

Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation

[Rodney Dawes]

On Thu, 2015-08-27 at 12:15 +0200, Michael Zanetti wrote:
> * I find it a little harder to find my silos in bileto, I think that's
> partially because the list has less spacing than the entries in the
> dashboard had, but also because bileto still shows my old, already
> landed silos.

I think this is hard, because it's just a large list, and the only
separation of anything really, is with whitespace. Even just keeping
track of the row for your landing can be a bit difficult, if you are
scrolling horizontally in a window, versus using a full screen browser.
One thing that would help here, I think, is simply changing the UI to
show "My Requests" separately from all the others, and always at the
top. Providing clear separation for the requests I make, from the
hundreds being made by others, will certainly make it easier to track my
own, especially when other requests come in after mine.



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation

[Rodney Dawes]

Hi Robert,

One small thing that I think would help a lot, is to have the link to
the PPA, have the "/+packages" added to the end of the URL. The main PPA
page by itself is pretty much useless, and what I need is to get at the
links to download the armhf .debs that were built, or to see build logs,
which are all on the +packages page.


On Wed, 2015-08-26 at 17:17 -0700, Robert Park wrote:
> Anyway, take it for a spin, please let me know what you think!
> Hopefully this is helpful ;-)



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] App working in background

[Rodney Dawes]

Background processing is not readily available yet, no. There are
numerous discussions on how to allow background processing, bluetooth
access, etc…

For Spotify/Pandora/etc… they could use the media-hub interface, to get
continuous playback of music streams in the background, currently.


On Sun, 2015-08-30 at 18:20 +0200, Krzysztof Tataradziński wrote:
> Hello,
> If someone clarify me one thing, I will be grateful.
> Suppose that some big player from mobile market want to develop app
> for Ubuntu phones. In example Spotify - they want to develop app that
> will be able to work in background and with screen turned off (on
> Android I've used it in that way almost all the time (when running
> with Endomondo)).
> Another thing - sport trackers - they also want to work with screen
> turned off. Third one - some file cloud services like Insync, Box,
> etc.
> For now it's impossible, right? Are there any plans to allow working
> apps in that way? How we can attract some big players on market when
> that basic feature is unavailable?
> 
> 
> Best regards,
> Krzysztof Tataradziński
> https://launchpad.net/~ktatar156
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] How to translate two strings

[Rodney Dawes]

On Sun, 2015-08-30 at 22:59 +0200, Krzysztof Tataradziński wrote:

> Thanks, I was also thinking in that way. But the question for now is
> what is 'trash info file'?
> Is it a one file with some logs about all deleted files?
> Maybe that 'trash info file' is created (in directory of origin
> deleted file) when we delete some file and contain some information
> where goes deleted file?
> Second question (connected with first one) - why this file is needed
> in system, what its purpose?

See "Contents of a trash directory" in the FDo spec[1]. These files only
exist on filesystems where a Trash directory following the spec is
present. The two messages you're asking about would appear when there
are specific errors when dealing with emptying Trash, or restoring items
from Trash.



[1] http://standards.freedesktop.org/trash-spec/trashspec-latest.html




signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] If Gmail can, why other apps can't?

[Rodney Dawes]

The notifications don't come from the app. They come from a system
service running in the background, which polls Google to notify you of
new things. The app is not running in the background.


On Fri, 2015-09-11 at 23:17 +0200, Krzysztof Tataradziński wrote:
> Hello,
> 
> I saw that even when I close Gmail webapp (that one default installed)
> I'm receiving notifications about new e-mails. How that is done? I
> mean why there is no possibility for now to allow other apps working
> in background, even when we close them (by swype down/up), but Gmail
> webapp can do that? Why Gmail is so special (besides of that most of
> us use it ;) ) to allow do this for it, but it's blocked/not
> implemented for rest of apps?
> 
> 
> Best regards,
> Krzysztof Tataradziński
> https://launchpad.net/~ktatar156
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] If Gmail can, why other apps can't?

[Rodney Dawes]

No, Google doesn't provide push notifications for Ubuntu (yet anyway).
It's being checked in accounts-polld.

Push notifications and accounts-polld are quite different things.


On Fri, 2015-09-11 at 22:35 +, Gran PC wrote:
> It looks like the Gmail webapp has a server-side counterpart to it
> that receives your emails and sends them to your device using Ubuntu's
> normal push notification service (which anyone can
> use): 
> https://developer.ubuntu.com/en/start/platform/guides/push-notifications-server-guide/
> 
> 
> This is also in use in some other apps like Twitter; it doesn't mean
> the app is running in the background constantly, it's just using polld
> to receive notifications.
> 
> 
> Cheers.
> 
> On Fri, Sep 11, 2015 at 11:18 PM Krzysztof Tataradziński
>  wrote:
> 
> Hello,
> 
> I saw that even when I close Gmail webapp (that one default
> installed) I'm receiving notifications about new e-mails. How
> that is done? I mean why there is no possibility for now to
> allow other apps working in background, even when we close
> them (by swype down/up), but Gmail webapp can do that? Why
> Gmail is so special (besides of that most of us use it ;) ) to
> allow do this for it, but it's blocked/not implemented for
> rest of apps?
> 
> 
> Best regards,
> Krzysztof Tataradziński
> https://launchpad.net/~ktatar156
> 
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] It's possible to install Skype (app, not web app) in Ubuntu Touch?

[Rodney Dawes]

On Tue, 2015-09-15 at 16:35 +0200, Marco Alexander Harrendorf wrote:
> I could be wrong, however, the major problem is at the moment that the
> microphone, webcam and so on of the Ubuntu phone cannot be accessed by
> X11 applications.
> E.g. the Chromium ARM package is compiled with WebRTC support, so that
> it could be directly be used for VOIP chats. However, since the
> microphone cannot be accessed this functionality is useless and I
> guess that this would be true for all other ARM packages. Meaning even
> if Skype would provide an ARM package we could not use it at the
> moment on Ubuntu phone.

If Microsoft were to provide a Skype that works for Ubuntu phones, it
would be in their best interest to provide a version which is designed
to work on phones, in the same way that the Skype client on iOS is not
the same as the Skype provided for MacOS. Instead, they should provide a
Skype client package following the rules of confinement on Ubuntu, and
also with an interface suitable for use on a phone, which could work on
a tablet or traditional PC as well.

Even if MS did provide a Skype package built for ARM and it was
unconfined with access to the mic and whatever else, the current Skype
client is not well suited for use on a phone, so it would be difficult
to use anyway. The best solution would be to provide a quality build
that follows the confinement rules and isn't a legacy X11 application
that requires you to plug in a keyboard/mouse/display to use it.



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Scopes not working without WiFi

[Rodney Dawes]

Hi Guillame,

On Wed, 2015-09-16 at 22:02 +0200, Guillaume F wrote:
> The Ubuntu Store is the biggest problem, since it means that I can't 
> install/uninstall anything or even view a specific app's page (to see 
> ratings, what's new in the latest version…) unless I'm home.


I'm not sure what would be causing such an issue with the store. A few
things you can try, to help debugging the problem:

- Check in ~/.cache/upstart/scope-registry.log for network errors when
accessing the store
- Long press on an icon in Apps scope and see if store info loads there
- Try loading https://search.apps.ubuntu.com/api/v1/search?q= in browser


Please file a bug [1] with the relevant information attached.


[1] https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+filebug




signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Scopes not working without WiFi

[Rodney Dawes]

On Thu, 2015-09-17 at 15:23 +0200, Guillaume F wrote:
> In that case, should I still file a bug against unity-scope-click?

I think not. This sounds like more of an issue with general network
access when on cellular data, and is not limited to the scopes, or even
to Ubuntu given what you said below.

> Then again, I could be a bit paranoid, but couldn't the operator be
> responsible for this selective slowdowns? I have the same problem with
> my self-hosted websites, and I discovered it with my previous
> (Android) phone. Question is, why would Free mobile block some
> websites, and what could I do about it?

It doesn't sound like they are actually blocking the sites outright.
However, there are many things that could be simply causing you to have
almost no bandwidth available. The operator could be limiting the
bandwidth, or you could just have incredibly poor latency on the
connection, which can cause such issues. They could also be forcing
connections through a proxy that causes various things to break. It's
hard for me to say really, since I'm not in France, and not on their
network.

To debug further, you may need to do some low level network debugging
with command line tools, by creating a chroot on the phone and
installing the tools within it. I'm not sure if your operator will
provide tech support if you're using Ubuntu, but if you have an Android
phone showing the same issues, maybe you can consult the operator for
support, to help find out what the issue is?



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Fwd: [Ubuntu-touch-coreapps] [ubuntu-system-settings] GSM codes handling broken in system-settings, dialer-app, or address-book-app

[Rodney Dawes]

Sounds like perhaps a bug in ofono, dialer-app, or perhaps
url-dispatcher (if the # is there, but is getting dropped)?

On Thu, 2015-09-17 at 15:27 +0100, Alan Pope wrote:
> Forwarding to a more appropriate list.
> 
> Peter, probably best to bring these things up here on ubuntu-phone list.
> 
> 
> -- Forwarded message --
> From: Peter Bittner 
> Date: 16 September 2015 at 22:04
> Subject: [Ubuntu-touch-coreapps] [ubuntu-system-settings] GSM codes
> handling broken in system-settings, dialer-app, or address-book-app
> To: ubuntu-touch-corea...@lists.launchpad.net
> 
> 
> I've been noticing a bug with GSM codes for a while. It was already
> there before OTA-5. Now I'm unsure where to file the bug, because I
> can't tell which app is the offending party.
> 
> How to reproduce the bug:
> 
> - I'm trying to use a GSM code stored on my SIM card. Namely, it's a
> code to query the current credit on the SIM (*147#).
> - When I go to the Dialer and I press the Contacts icon, that leads me
> to the Contacts app ... where I can't find the SIM codes. (see below
> why I mention this)
> - When I go back to the Dialer and I press the Settings icons, that
> leads me to the Phone screen in the System settings.
> - I continue with Services on my first SIM card. (Good! All the
> numbers I expect are listed: service numbers and GSM codes of my
> network provider.)
> - When I select an obvious GSM code ("Mobile Balance") a detail page
> opens with a "Call" button at the bottom. When I press this button the
> Dialer app opens with the GSM code *but* with the last character (hash
> code) *missing", i.e. "*147" instead of "*147#" is shown.
> - Of course, when I place a call to this number the phone thinks it's
> a regular, albeit short number and tries to perform a regular call.
> Only when I append a "#" character in the end I can successfully send
> the GSM code and received the reply (which work flawlessly).
> 
> That's obviously a bug, but which component is the affected one? The
> sender (system-settings) or the receiver (dialer-app)? Then,
> interestingly, there's no bug tracker configured in the
> ubuntu-system-settings project.
> https://bugs.launchpad.net/ubuntu-system-settings
> 
> A design comment: The dialog box being displayed for the answer from
> my network provider has two action buttons, Cancel and OK. They both
> seem to have the same function: dismiss the dialog. Probably a single
> button, Close, would also do it.
> 
> Finally, I'd like to have easier access to the Service numbers on my
> SIM card. At the moment I can only access them via the System Settings
> > Phone > Services (of one of my SIM cards). It would be handy to have
> them also in the Contacts app, e.g. via a special options menu (I
> think that's how Android has got it, at least on my ancient Samsung
> phone). An additional option in the Contact app's settings screen
> could do it (I don't want to import the numbers from the SIM; I want
> to use them, period.). I need those numbers only sometimes, and I
> usually have a hard time remembering where to find them.
> 
> Thanks in advance for clarifying,
> Peter
> 
> --
> Mailing list: https://launchpad.net/~ubuntu-touch-coreapps
> Post to : ubuntu-touch-corea...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> -- 
> Alan Pope
> Community Manager
> 
> Canonical - Product Strategy
> +44 (0) 7973 620 164
> alan.p...@canonical.com
> http://ubuntu.com/
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Does Ubuntu Touch support self-hosting?

[Rodney Dawes]

Recommended way to install regular .deb packages on Ubuntu Phone?
https://askubuntu.com/questions/620740/recommended-way-to-install-regularcli-deb-packages-on-ubuntu-phone/623311#623311

You can compile on the device, in a chroot, if you really need to. I
wouldn't recommend bothering with such thing though, unless there is
some absolute pressing need to do so.


On Sat, 2015-09-19 at 17:41 -0400, Bob Summerwill wrote:
> I have just bought a Meizu MX4 Ubuntu Edition.  It is one of my target
> platforms for porting of the Ethereum Light Client.  See
> http://doublethink.co.
> 
> This is my first Ubuntu Touch development, though I have done some
> Firefox OS, Tizen and Sailfish.
> 
> Does Ubuntu Touch support self-hosting or only cross-compilation from
> Ubuntu desktop?   In the simplest form, I am asking whether GCC can be
> run on-target.  Thanks!
> 
> Bob Summerwill
> http://bobsummerwill.wordpress.com/about/
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] API to get contact avatar?

[Rodney Dawes]

"template": "unconfined",

That might work for stuff we have reasonable control over and ship by
default on the images, but doesn't work in general for developers
writing apps or scopes, since we can't safely allow unconfined apps and
scopes into the store.


On Mon, 2015-10-05 at 11:49 -0400, knitzsche wrote:
> Hi Jani,
> 
> My calls-scope and texts-scope both show the contact's avatar when
> there is one.
> 
> See around this:
> http://bazaar.launchpad.net/~calls-scope-team/calls-scope/calls-scope-trunk/view/head:/src/query.cpp#L247
> 
> Cheers,
> Kyle
> 
> On 10/02/2015 11:26 AM, Jani Monoses wrote:
> 
> > Hello, 
> > 
> > is there an API to get an address-book contact's avatar via the
> > content hub?
> > I know one can get a vcard's url that way, but that does not contain
> > avatar info.
> > 
> > 
> > thanks
> > Jani
> > 
> > 
> > 
> > 
> > 
> > 
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] phone total wipe

[Rodney Dawes]

On Mon, 2015-10-26 at 18:11 +, Wayne Ward wrote:
> Ive done a reinstall of my phone which gives you a fresh install but 
> when i went to add a cron my crons still there
> and i have a problem were i cant add a cron as a user have to add it as 
> root becuase its broke for some reason
> how can i just flash my phone BQ4.5 to the latest stable image and start 
> again
> I know connect with usb cable and run a command but whats the command 
> and will it flash all the old cron stuff etc like
> a proper full reinstall of the phone.
> 
> Regards
> Wayne
> 

Use the --wipe option when flashing the device while booted into Ubuntu
in developer mode, or the --bootstrap option while flashing from
fastboot, following the instructions[1].

[1] https://wiki.ubuntu.com/Touch/Devices#Working_with_ubuntu-device-flash



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] OTA-7 for Community Build?

[Rodney Dawes]

I don't think that image server has been updated in quite some time. It
does not have channels following stable and rc-proposed, to rebuild for
hammerhead.


On Mon, 2015-11-02 at 10:35 -0500, Bruce Griffis wrote:
> I don't see an OTA-7 yet for the community build for the Nexus 5.
> Where would I look first to see if OTA-7 is already out on
> system-image.ubuntu.com for the community-supported build? I read
> through launchpad and saw where OTA-7 was released, and that it ran a
> little late for the supported Nexus 4. What I'd like to be able to
> figure out is what channel I should look at to see if OTA-7 is
> released for the community build so I can know if there is an issue
> with the community build on system-image.ubuntu.com or if the problem
> is at system-image.tasemnice.eu. I read there should be about two
> hours between when the OTA is released on system-image.ubuntu.com and
> when it is reflected on system-image.tasemnice.eu
> 
> 
> I'm enjoying Ubuntu Touch 15.04 r23 on my N5 and am looking forward to
> OTA-7 and especially OTA-8. 
> 
> 
> Regards,
> 
> Bruce Griffis
> 



-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] OTA-7 for Community Build?

[Rodney Dawes]

The Nexus 5 is not an officially supported device. There are no official
"OTA N" updates for it. As you said, the image server in question is
managed by a single person, and it is provided as a convenience, not as
a means of creating a level of support that appears to be official.

I'm not sure what issue you're having exactly, but any issues specific
to the Nexus 5 are unlikely to be fixed by newer image builds.


On Mon, 2015-11-02 at 13:08 -0500, Bruce Griffis wrote:
> I wouldn't call it an offering. It is an individual contributor that
> put up a system-image server (and I believe is paying the costs
> associated with that server). That's why I want to make sure the
> community image of OTA-7 is out before chasing an issue that might not
> be an issue. Server is current on daily updates on devel-proposed.
> 
> 
> 
> The page that references it is:
> https://wiki.ubuntu.com/Touch/Devices
> 
> 
> Scroll down to the section on Working Ports w/ System Image Server.
> 
> On Mon, Nov 2, 2015 at 12:42 PM, kaabud...@yahoo.de
>  wrote:
> On 02-11-15 16:35, Bruce Griffis wrote:
> I read there should be about two hours between when
> the OTA is released on
> system-image.ubuntu.com
>  and when it is
> reflected on system-image.tasemnice.eu
> 
> 
> Where did you read that? I'd be curious to better understand
> the system-image.tasemnice.eu offering.
> 
> 
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Forcing to install Twitter Scope

[Rodney Dawes]

Sounds like you are hitting an existing bug[1314382] that sometimes
appears and is difficult to track down.

[1314382] 
https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1314382


On Sat, 2015-11-21 at 09:30 +0100, Krzysztof Tataradziński wrote:
> Hello,
> After last OTA I see that in settings->updates there is twitter scope.
> I've installed it. But I don't want to have it, so after 5-10 seconds
> I've uninstalled it. But hey! In updates that scope appeared again.
> Why Canonical is forcing to install that scope in all phones? They
> think: hmm... Our users are too stupid to find that scope in Store and
> check out how great it is, so we will force them to install it.
> 
> Don't get me wrong - After all OTA I'm doing full wipe to get phone
> cleaned as much as I can. Next step -> I'm uninstalling all
> Scopes/Apps that I don't use, because I want decide what I want to
> have in my phone. Still can't uninstall amazon, ebay scopes. And now I
> see pending install (formally 'update') of Twitter scope all the time.
> 
> Best regards,
> Krzysztof Tataradziński
> https://launchpad.net/~ktatar156
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] LTE for reference hardware?

[Rodney Dawes]

Yes, 4G/LTE works on Ubuntu. However, on the Nexus 4, you have to use a
very old radio firmware to enable it, as Google disabled its usage via
firmware update at one point.

I use Ubuntu exclusively on my Nexus 5, and 4G works fine on it.


On Sat, 2015-11-28 at 08:25 -0800, Eric Holmi wrote:
> Good morning (or afternoon depending on where you live),
> As most of you know, the Nexus 4 has some limited 4G and LTE support.
> I know it has the hardware for LTE band 4. Does current stable Ubuntu
> software have support for LTE? And I believe we are still 32bit as far
> as the phone OS goes, so what is the time line for adding 64 bit OS
> parts?
> Thanks 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] LTE for reference hardware?

[Rodney Dawes]

No. The Nexus 4 is not a retail device, and radio firmware is not part
of the Ubuntu images. You'll have to go find the old image that has the
radio firmware which supports LTE, and flash it onto your Nexus 4
manually.

The bq e4.5 and e5 do not support LTE at all. They are not the same
hardware as the Nexus 4.

The bq Aquaris devices radio is specified as:
3G HSPA+ (900/2100)
2G GSM (850/900/1800/1900)


On Sat, 2015-11-28 at 10:14 -0800, Eric Holmi wrote:
> Does the Nexus 4, BQ4.5, or BQ5 have that firmware
> installed with Ubuntu aa a default install?
> 
> On Saturday, November 28, 2015, Rodney Dawes
>  wrote:
> Yes, 4G/LTE works on Ubuntu. However, on the Nexus 4, you have
> to use a
> very old radio firmware to enable it, as Google disabled its
> usage via
> firmware update at one point.
> 
> I use Ubuntu exclusively on my Nexus 5, and 4G works fine on
> it.
> 
> 
> On Sat, 2015-11-28 at 08:25 -0800, Eric Holmi wrote:
> > Good morning (or afternoon depending on where you live),
> > As most of you know, the Nexus 4 has some limited 4G and LTE
> support.
> > I know it has the hardware for LTE band 4. Does current
> stable Ubuntu
> > software have support for LTE? And I believe we are still
> 32bit as far
> > as the phone OS goes, so what is the time line for adding 64
> bit OS
> > parts?
> > Thanks
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Hdmi cable

[Rodney Dawes]

There is no X server on the phone.

However, this issue is that the hardware is not enabled at the hardware
level. There is no working around that in software.


On Tue, 2016-01-12 at 19:45 -0500, Eric Holmi wrote:
> Is there a potential work around to make the device send X server
> output to both the micro USB and display simultaneously by modifying
> the X server config files, or by modding the display configuration
> files?
> 
> 
> On Tue, Jan 12, 2016 at 7:29 PM, Nathan Haines 
> wrote:
> On 01/12/2016 04:21 PM, Wayne Ward wrote:
> Can anyone tell me which cable / adapter id need to
> buy to get my Bq 4.5
> connect to hdmi monitor please Link would nice..
> Wayne
> 
> The Ubuntu BQ and Meizu phones cannot connect to external
> displays.
> 
> -- 
> Nathan Haines
> Ubuntu - http://www.ubuntu.com/
> 
> 
> 
> 
> 


signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Hdmi cable

[Rodney Dawes]

The phone images use Mir, Not Xorg.

No, you can't bypass the lack of hardware by CPU magic. The pins on the
chip are not wired up to support MHL. There is no way to enable MHL
through software when there is no hardware to support it.


On Tue, 2016-01-12 at 21:35 -0500, Eric Holmi wrote:
> Ok. Now Im confused. How can there be graphics without a graphics or x
> server? Besides, couldnt you use a CPU thread to bypass any hardware
> limitations by routing the GPU's output through it, because the CPU
> has access to everything? 
> 
> 
> On Tue, Jan 12, 2016 at 9:22 PM, Rodney Dawes
>  wrote:
> There is no X server on the phone.
> 
> However, this issue is that the hardware is not enabled at the
> hardware
> level. There is no working around that in software.
> 
> 
> On Tue, 2016-01-12 at 19:45 -0500, Eric Holmi wrote:
> > Is there a potential work around to make the device send X
> server
> > output to both the micro USB and display simultaneously by
> modifying
> > the X server config files, or by modding the display
> configuration
> > files?
> >
> >
> > On Tue, Jan 12, 2016 at 7:29 PM, Nathan Haines
> 
> > wrote:
> > On 01/12/2016 04:21 PM, Wayne Ward wrote:
> > Can anyone tell me which cable / adapter id
> need to
> > buy to get my Bq 4.5
> > connect to hdmi monitor please Link would
> nice..
> > Wayne
> >
> > The Ubuntu BQ and Meizu phones cannot connect to
> external
> > displays.
> >
> > --
> > Nathan Haines
> > Ubuntu - http://www.ubuntu.com/
> >
> >
> >
> >
> >
> 
> 
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Hdmi cable

[Rodney Dawes]

Nope.

As was already mentioned, the only possibility for such devices which
lack MHL support, is to use something like Miracast or other wireless
video streaming, when support for it lands in Ubuntu.

You can't add MHL to a device which doesn't have hardware support for
it, in the same way you can't add Bluetooth LE support to a device whith
doesn't have the hardware for it.


On Tue, 2016-01-12 at 21:49 -0500, Eric Holmi wrote:
> Ok. It just seems like there is some fancy way to do it. Maybe share
> GPU ram with CPU or something?
> 
> 
> On Tue, Jan 12, 2016 at 9:47 PM, Rodney Dawes
>  wrote:
> The phone images use Mir, Not Xorg.
> 
> No, you can't bypass the lack of hardware by CPU magic. The
> pins on the
> chip are not wired up to support MHL. There is no way to
> enable MHL
> through software when there is no hardware to support it.
> 
> 
> On Tue, 2016-01-12 at 21:35 -0500, Eric Holmi wrote:
> > Ok. Now Im confused. How can there be graphics without a
> graphics or x
> > server? Besides, couldnt you use a CPU thread to bypass any
> hardware
> > limitations by routing the GPU's output through it, because
> the CPU
> > has access to everything?
> >
> >
> > On Tue, Jan 12, 2016 at 9:22 PM, Rodney Dawes
> >  wrote:
> > There is no X server on the phone.
> >
> > However, this issue is that the hardware is not
> enabled at the
> > hardware
> > level. There is no working around that in software.
> >
> >
> > On Tue, 2016-01-12 at 19:45 -0500, Eric Holmi wrote:
> > > Is there a potential work around to make the
> device send X
> > server
> > > output to both the micro USB and display
> simultaneously by
> > modifying
> > > the X server config files, or by modding the
> display
> > configuration
> > > files?
> > >
> > >
> > > On Tue, Jan 12, 2016 at 7:29 PM, Nathan Haines
> > 
> > > wrote:
> > > On 01/12/2016 04:21 PM, Wayne Ward wrote:
> > > Can anyone tell me which cable /
> adapter id
> > need to
> > > buy to get my Bq 4.5
> > > connect to hdmi monitor please
> Link would
> > nice..
> > > Wayne
> > >
> > > The Ubuntu BQ and Meizu phones cannot
> connect to
> > external
> > > displays.
> > >
> > > --
> > > Nathan Haines
> > > Ubuntu - http://www.ubuntu.com/
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] [Challenge] Ebook reader

[Rodney Dawes]

On Mon, 2016-02-01 at 15:19 -0500, Robert Schroll wrote:
> > 9) It should be possible to sync the library, reading positions etc 
> > to a
> > central source
> 
> I purposefully architected Beru so that the reading positions and other 
> settings were stored in their own U1DB that could be synchronized over 
> Ubuntu One.  And then Ubuntu One shut down.

Ubuntu One is not shut down. What was shut down was the file/music
sync/streaming/storage/store services. U1DB is still up AFAIK, and
Ubuntu One is still the SSO account infrastructure for Ubuntu. Also,
anyone can run a U1DB server and you could sync the db in your app to
any U1DB server that supports sync. You just need some way to configure
it and trigger the sync.



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] [Challenge] Ebook reader

[Rodney Dawes]

On Mon, 2016-02-01 at 17:53 -0500, Robert Schroll wrote:
> On Mon, Feb 1, 2016 at 5:07 PM, Rodney Dawes 
>  wrote:
> > Ubuntu One is not shut down. What was shut down was the file/music
> > sync/streaming/storage/store services. U1DB is still up AFAIK, and
> > Ubuntu One is still the SSO account infrastructure for Ubuntu.
> 
> I was under the impression, perhaps mis-formed, that Ubuntu One (the 
> database) would have allowed database synchronizing via Ubuntu One (the 
> file sync service), which you signed into with your Ubuntu One (the 
> authentication service) login.  If that's not the case, the confusion 
> is your* own damn fault for giving them all the same name.

It was always clearly stated that the U1DB server was still up, and that
it was not done via file synchronization. I'm pretty sure the Qt U1DB
implementation that exists on the phone was also written mostly after
the Ubuntu One file sync services were taken offline, or at least
announced that the service would be taken offline. Would be a bit odd to
continue promoting an API for a service that was dead, don't you
think? :)

> > Also,
> > anyone can run a U1DB server and you could sync the db in your app to
> > any U1DB server that supports sync.
> 
> Are there any public U1DB servers out there?  If not, this is about as 
> useful to most people as being able to compile your own kernel.

There is u1db.ubuntu.com of course. It at least appears to be up, though
I haven't tried to sync anything to it. I don't know that anyone is
actually using it either.

I thought there was a blog post somewhere about how to sync a U1DB with
Ubuntu One using the account on the phone, in QML, but I can't seem to
find it now. Maybe Christian (kalikiana) can help clarify that when he
comes back on-line.

> Robert
> 
> * referring to Canonical as a whole here, not any individual.
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] mediaplayer-app occupies full screen

[Rodney Dawes]

The mediaplayer-app is full screen because it's the app for playing
videos. If you only have audio and want it in the background, you should
instead look into just using the mediahub API to play the stream. If
this is a podcast, you might be able to use the Podbird app to listen to
it instead.


On Tue, 2016-02-02 at 15:47 +0100, Matthias Apitz wrote:
> Hello
> 
> I often listen my favored news radio station with a short commando
> launched by a shell script from the terminal:
> 
> cat df.sh
> # play D-radio sream
> ubuntu-app-launch mediaplayer-app 
> http://stream.dradio.de/7/251/142684/v1/gnl.akacast.akamaistream.net/dradio_mp3_dlf_s
> 
> Please note, the stream is audio only, no video. Why mediaplayer-app
> does occupy the full screen? I'd like to see at least the status
> indicator bar on top of the BQ E4.5. Is there some how an option to
> control this?
> 
> Thanks
> 
>   matthias
> 
> -- 
> Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  ☎ 
> +49-176-38902045
> UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370)
> UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5
> 



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] mediaplayer-app occupies full screen

[Rodney Dawes]

On Tue, 2016-02-02 at 17:26 +0100, Matthias Apitz wrote:
> On Tuesday, 2 February 2016 16:34:37 CET, Rodney Dawes wrote:
> > The mediaplayer-app is full screen because it's the app for playing
> > videos. If you only have audio and want it in the background, you should
> > instead look into just using the mediahub API to play the stream. If
> > this is a podcast, you might be able to use the Podbird app to listen to
> > it instead.
> > 
> 
> 
> Thanks for the answer. Could you please be so kind an provide a workin 
> shell script example, to be launched from the terminal-app, for the URL I 
> gave:
> 
> >> cat df.sh
> >> # play D-radio sream
> >> ubuntu-app-launch mediaplayer-app 
> >> http://stream.dradio.de/7/251/142684/v1/gnl.akacast.akamaistream.net/dradio_mp3_dlf_s
> 
> I could not manage to get podbird-app to replace mediaplayer-app, it 
> complains about some missing keyfile, and doe not play the stream.

I meant, use Podbird to manage your podcast subscriptions, not to try to
launch it with the stream URL simply by replacing mediaplayer-app with
it in your command. Install the app from the store, and add the podcast
to it which youa re trying to listen to (the rss podcast icon on its web
site).



signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Shashlik running Android apps on Linux

[Rodney Dawes]

On Mon, 2016-02-22 at 13:20 -0800, Bob Summerwill wrote:

> 
> If you want to see something amazing, check out "Android as an App" on
> SailfishOS.   That kind of magic should be possible for Ubuntu Phone
> as well, I think.

The security model of Ubuntu, and that of Android, do not mesh at all.
Sailfish is not Ubuntu, and to compare the two in this regard of running
Android apps, is to completely ignore all of the work that has gone into
Ubuntu for security.

A general purpose solution for running Android apps would defeat the
security work that has been put into Ubuntu, and open up your Ubuntu
phone to all the same malware and other problems that Android has.


However, anyone is more than welcome to attempt to create a package
which contains one of these translation engines, and their
favorite .apk, and side-load it onto their phone, and attempt to use it.
You won't get Android push notifications. You won't get contacts or
calendar integration. You will get an Android App running on your Ubuntu
phone. If you want full system integration, then the best way for that
to happen, is to have a port of the app.




signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] bluez on ubuntu phone

[Rodney Dawes]

Hi Nick,

Low level APIs like bluez are generally not part of the SDK meant to be
used by applications on the phone, and higher level QML APIs are what
are supported in the SDK. However, currently there is also no policy
group for talking to bluez over dbus, nor any supported method of
performing background processing, so you won't be able to create a
device pairing, or perform any background tasks, within an application
you intend to upload to the store, currently.

If you're just looking to experiment with the examples, you can follow
the instructions in my answer on Ask Ubuntu[1] about how to set up a
chroot to compile and run traditional CLI tools on the phone.

[1] https://askubuntu.com/questions/620740/#623311


On Sat, 2016-03-12 at 03:21 +0200, Николай Шатохин wrote:
> Hello.
> 
> I'm trying to run few bluez examples on my ubuntu phone from here: ht
> tp://people.csail.mit.edu/albert/bluez-intro/x502.html
> But Ubuntu SDK can't compile it because can't found bluez headers
> (and I suppose lib too). So, how to get it worked?
> 
> Best regards,
> Nick
> -- 
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp

signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Can't buy app via Ubuntu Store

[Rodney Dawes]

Hi,

It seems there are some new issues that have appeared recently in the
payment process, that may have been caused by some other changes in the
phone images as of late. We are currently working on making it easier
to maintain some of the components, and to catch some of these things
earlier on in the process.

I'm sorry you're having such trouble trying to buy an app. Can you go
to https://pay.ubuntu.com/ and verify that your card is configured for
USD, and can you send me (privately) all of the "~/.cache/upstart/*pay-
ui*" files on your phone? Hopefully the logs will tell us what went
wrong.

Thanks.


On Sun, 2016-03-13 at 19:45 +0100, Peter Bittner wrote:
> Hi there,
> 
> I'm finally ready to buy my first app and pay real money on the
> Ubuntu
> Store. Unfortunately, this doesn't seem to work. The payment process
> hangs after I enter my "Ubuntu One password". Here's what I do:
> 
> - Go the the Ubuntu Store via the Apps scope (at the end of the
> screen)
> - Scroll down until I see the app (or search for it, doen't make a
> difference) and tap on it
> - See the details of the app, and tap on the orange amount button
> - The payment app loads (displays "Zahlung" in German, and the US$
> amount to pay)
> - Enter the password I use for https://login.ubuntu.com/ (below my
> read-only email address), the payment type is PayPal (cannot be
> changed; note that I don't have PayPal)
> - Tap on the orange "Pay now" button
> - Modal dialog is displayed ("Wird geladen ..." / "Bitte warten ..."
> i.e. Please wait in German)
> 
> Then the payment app obviously hangs.
> Here's what the syslog says: http://paste.ubuntu.com/15376312/
> 
> Because the dialog is modal over the Scope app there is not even a
> way
> to kill the dialog / payment app via the phone screen. I have to
> restart the phone using the hardware button.
> 
> Oh, I just figured that on https://pay.ubuntu.com/payment/ I have 4x
> the very same payment pending. Outch!  :-)
> 
> Any clue what's going on and how I can fix this? How can I give money
> to Canonical? :-)
> 
> Peter
> 

signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Interruptions. When?

[Rodney Dawes]

On Mon, 2016-03-14 at 13:53 +, Matthew Paul Thomas wrote:
> The second part would be designing and implementing an inviting way
> for
> people to configure it. It’s pointless having the world’s most
> sophisticated system for fine-tuning notifications if no-one uses it.

We were born with that most sophisticated system already. It's kind of
disappointing how many people fail to use it on a daily basis, though.

It's like nobody remembers what life was like 10 years ago before the
iPhone existed. When we didn't want to be called or hear the ringer,
aka get notifications, we turned the thing off or put it in vibrate
only, or just plain ignored the thing; just like we did with land lines
(anybody remember those)?

Why don't people know how to just ignore things any more? It works
better than any attempted magical software trying to intuit what it is
exactly that you want at any given moment. Because no software is going
to be able work correctly for anyone, that tries to be that smart. It
will just be a horrible experience for the vast majority.

IMO, the best solution for this problem isn't in software or design,
it's social. A phone isn't just a tool; it is an extension of one's
self.


signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Difficulty Sending Messages to this List (was Re: (no subject)

[Rodney Dawes]

No, that is not the problem. Sending a message with a different e-mail
address will have your message land in the moderator queue, and you
will get an e-mail saying so. If it goes through and ends up in the
spam folders of people subscribed to the list, then the only relation
to e-mail address used, may be that certain e-mail providers often have
more spam sent through them, and thus, your e-mail address may be
identified as spam.

Beyond that, sometimes the e-mail message simply reads as if it could
be spam, as not everyone is a native English speaker, and sometimes
certain combinations of words and various typos, will simply be caught
by spam filters.

I have definitely seen mails from others on this list end up in the
spam folder in gmail. But my local spamassassin config is a bit
smarter, and it doesn't tend to send them to spam, when I go pull them
out of gmail's spam folder.



On Fri, 2016-03-18 at 18:25 +0100, Peter Bittner wrote:
> Have them check whether they use the same, identical email address
> for
> posting messages that they have subscribed with.
> 
> I'm 99% sure this is the problem.
> 
> It's like faxes. Why the hack do people lift the receiver and then
> hang up when they hear the fax signal? Probably because the system is
> not intelligent enough to not let them lift the receiver when a fax
> is
> coming in. (That would be the actual solution. And the phone
> shouldn't
> even ring.)
> 
> I think when you are a software developer or a manager you should be
> able to understand the underlying problem. But of course,
> subscription
> to mailing list is an old-fashioned thing that just works. Just that
> it was not designed to times when everyone has 3 or more different
> email addresses. Welcome to 2016!
> 
> Difficult to fix. At least difficult to quick-fix.
> 
> Peter
> 
> 
> 2016-03-18 17:42 GMT+01:00 Randall Ross  :
> > 
> > I'm wondering how widespread this issue is...  I've had two friends
> > this
> > week tell me that although they can receive ubuntu-phone messages,
> > they
> > cannot post. Is this a case of over-aggressive spam filters, or
> > perhaps a
> > moderation queue issue?
> > 
> > Can the list admin investigate?
> > 
> > Cheers,
> > Randall.
> > 
> > On 03/18/2016 09:18 AM, Krzysztof Tataradziński wrote:
> > 
> > Hello,
> > I'm only forwarding ;)
> > 
> > "
> > -- Forwarded message --
> > From: Marcin Hofmann 
> > Date: 2016-03-17 18:01 GMT+01:00
> > Subject: Mailing list bug
> > To: ubuntu-phone@lists.launchpad.net
> > 
> > 
> > I do not know if You noticed that lots of messages from this
> > mailing list
> > land in a spam folder of our e-mail boxes? The way we communicate
> > does NOT
> > work! How are we expected to create a better world when the
> > communication
> > chain is broken? A few days ago I sent a message with a problem
> > that nobody
> > answered. As I found out later someone found my message by mistake
> > in spam.
> > Wouldn't it be a better to make a forum with a clear topic list so
> > no of our
> > messages are gone and so that we can easily find some old
> > information, sent
> > months ago that we now badly need? If I were I manager in a company
> > like
> > Canonical I'd ban using mailing list. The spam filters nowadays are
> > to
> > strong and block important information.
> > 
> > Cheers
> > 
> > GTriderXC
> > "
> > 
> > Best regards,
> > Krzysztof Tataradziński
> > https://launchpad.net/~ktatar156

signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] Installing Dekko fails always

[Rodney Dawes]

Hi,

Does the error happen after the progress bar reaches 100%, or does it
happen immediately when starting the download? Can you check in the
$HOME/.cache/ubuntu-download-manager/ director for an error log, and
find the error in that log?

Also, can you include the output of "system-image-cli -i" if you can
run it from under adb if you can't use the Terminal app?

Thanks.



On Sat, 2016-03-19 at 20:49 +, cewe2005-newslet...@yahoo.de wrote:
> Hello there, 
> after updating a few apps of my ubuntu phone aquaris 4.5 (ubuntu
> version 15.04) Dekko didn't work anymore, it only showed an white
> screen. So I tried to solve the problem with uninstalling the app,
> but since then I cannot reinstall it. It always appears the message:
> "Download or installation failed"
> With 'terminal' its the same, but with other apps, the installation
> works normal. 
> 
> So what can I do now? Has anybody an idea, what I can do right now? I
> need help with that.
> Thanks for your work and help!
> 
> 
> -- 
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp

signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp

Re: [Ubuntu-phone] ubuntu one

[Rodney Dawes]

I don't think syncing is the answer. For example, I am using 400 GB of
space in my home directory on my workstation. That's more than 10 times
the total amount of space my phone has. It would obviously be
impossible to sync it.

What I want is not syncing. It is access and caching of certain more
important things, like contacts/calendar.  I don't need to copy all my
data to my phone, because I don't need it all the time.

I certainly don't want sync services killing battery and eating data
all the time trying to keep things synchronized, when it's not really
necessary.


On Fri, 2016-04-01 at 23:34 +0100, Wayne Ward wrote:
> I just read a post before about the sync stuff
> I agree that the system should now have a cloud sync option without
> the
> messing about with rsync and messy owncloud etc
> why did they drop ubuntu one?
> it worked for one and people like me are prepared to pay for space...
> like other platforms you should be able to log in and sync 
> data
> music
> calendars
> contacts
> bookmarks
> tasks
> app data
> 
> including back up if required..
> 
> people get 2 gig free and of course they need more so pay a small fee
> for more space...
> if we cant have ubuntu one why not get a small team integrating sync
> options ie owncloud and google cloud services as it seems to me a lot
> of people are asking how to do this and its messy?... is it on the
> list
> of things to do or waiting for people to develop this? as i think you
> now have tablet / server / phone / computer desktop / laptop desktop
> and no sync between these - i think in todays way of mobile and
> computing this is part and parcel of every platform 
> 
> thoughts please?
> 
> Wayne Ward
> 
> 
> 

signature.asc
Description: This is a digitally signed message part
-- 
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp