Mailing List Archive

ext Michael Cronenworth <mike@cchtml.com> writes:

> If a user has access to downloading apps, then they will be notified of
> the Maemo update. If they want a new app, they must update Maemo, but
> they can continue using their old apps as long as they want. Refusing to
> update because of a personal preference should be discounted. Security
> updates, new features, and significant bug fixes should trump any
> personal preference about updates to Maemo itself.

I agree, but the Application manager is unfortunately less than helpful
in guiding the user through a required OS update. If a OS update is
needed to install an application, the Application manager will only give
a cryptic error message.

This needs to be fixed, obviously. There are plans, but neither
commitment nor schedules... :(
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

ext Dave Neary <dneary@maemo.org> writes:

> Then a new version of the SDK comes out, which is not backwards
> compatible. A number of potentially bad things can happen:

I agree with your points in general, but I want to qualify them a bit.

There are two issues:

- I think it is very important to be able to release new OS versions and
new SDK versions that add APIs.

- I also think that it is important to be able to remove APIs in a
controlled way, but much less so than being able to add APIs, and we
can leave that for later, once we have figured out how to add APIs.

> 1. New uploads get compiled with the new SDK, and get downloaded onto
> phones with the old OS, where they don't work.

This is one kind of bug: the new SDK has added APIs compared to the old
API, and applications that use the new SDK wont run on OS versions that
doesn't have that API.

Some will not work, and some will not even install, but most of them
should install and work. New uploads should only not install or work
(by necessity) when they actually use the added API. If they don't use
any of the added API, they should install and work with the old versions
of the OS.

Our SDKs are not very good at producing the necessary dependency
information for this (i.e., our library packages don't use
dpkg-gensymbols, and we do not maintain the -V option of dh_makeshlibs),
and as a result, almost all packages will erroneously refuse to install
into a old OS when they have been compiled in a new SDK.

This is a bug in the SDK (i.e., in the tools and in the packages), it is
unfortunately _not_ trivial to fix, but it is very worthwhile to fix it.
(RPM does it differently, so maybe this isn't actually worthwhile to
fix, but let's ignore that for now...)

We should at least check each new SDK release for undesired changes in
the shlibs files.

> 2. Developers working with the old SDK upload applications which don't
> even build with the new SDK

This is a different kind of bug: this will happen when the new SDK has
removed APIs compared to the old SDK.

It's a bug in the SDK and should be fixed.

> 3. To mitigate 2, we decide that all Extras apps need to be recompiled
> with the new SDK, [...]

That would be foolish, and we should not do it. As you say, we would
run into the SDK bug responsible for category 1 above. We can and
should avoid that by not recompiling applications just because the SDK
has been updated.

Instead, before accepting a SDK release, we should check whether it can
still compile all the Extras apps. If not, we have found a bug, either
in the SDK or in the Extras app. That bugs needs to be fixed, and there
wont be many of these.

> All of these push inconvenience to the phone user & application
> developer - all unnecessary overhead, especially if the APIs haven't
> changed and there are issues with run-time library versions (as we saw
> with PR 1.0 to 1.1).

Agreed.

> The only way to avoid badness when upgrading the SDK in a
> not-backwards-compatible way is to have scratchbox, every developer
> copy of the SDK, and the N900 firmware all upgrade at the same time.

That's fortunately not the only way, although the way outlines above
isn't particularily easy. The established GNU/Linux upstreams and
distributions have this pretty much under control.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

ext David Greaves <david@dgreaves.com> writes:

> My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov.
>
> The device never reminded her again. She only got pr1.1.1 because she noticed my
> device made a sound on account connections and hers didn't... I did 2 upgrades
> in succession. Normal users wouldn't have even noticed.

That's a bug in the "ignore" machinery: I think we only store which
packages have been ignored, but not which versions. This means that if
you ignore a OS update, you will never be notified again about OS
updates ever.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Marius Vollmer wrote:
> ext David Greaves <david@dgreaves.com> writes:
>
>> My wife must have done an 'ignore' on a Maemo5 update sometime in oct/nov.
>>
>> The device never reminded her again. She only got pr1.1.1 because she noticed my
>> device made a sound on account connections and hers didn't... I did 2 upgrades
>> in succession. Normal users wouldn't have even noticed.
>
> That's a bug in the "ignore" machinery: I think we only store which
> packages have been ignored, but not which versions. This means that if
> you ignore a OS update, you will never be notified again about OS
> updates ever.
Has a fairly big impact on the assumptions being made.... including those who
will never see the update that fixes the bug...

David

--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wed, 2010-02-24 at 17:48 +0000, Graham Cobb wrote:
> On Wednesday 24 February 2010 17:18:29 Thomas Tanner wrote:
> > On 24.02.10 18:04, Graham Cobb wrote:
> > > Why do I think many people will not upgrade? This device is a phone.
> >
> > The N900 is a mobile computer.
>
> I am talking about the people who perceive it to be a phone. "Like the
> iPhone".

I don't think iPhone owners really have the choice to not update.

Xav

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Thu, Feb 25, 2010 at 2:33 PM, Marius Vollmer
<marius.vollmer@nokia.com> wrote:

> That's a bug in the "ignore" machinery: I think we only store which
> packages have been ignored, but not which versions.  This means that if
> you ignore a OS update, you will never be notified again about OS
> updates ever.

How do I clear out my ignore history?

martin
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

ext David Greaves <david@dgreaves.com> writes:

>> That's a bug in the "ignore" machinery: I think we only store which
>> packages have been ignored, but not which versions. This means that if
>> you ignore a OS update, you will never be notified again about OS
>> updates ever.
>
> Has a fairly big impact on the assumptions being made.... including those who
> will never see the update that fixes the bug...

Yes, I agree. Back then, I was thinking that it would be annoying to
notify people about every single subsequent update if they have ignored
the first, but I have changed my opinion now...
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

ext Martin DeMello <martindemello@gmail.com> writes:

> How do I clear out my ignore history?

Try this:

$ rm ~/.hildon-application-manager/{seen,tapped}-updates

We don't really keep a history of what has been ignored, just a brief
record of what has been shown in the "Updates" view. This is compared
to /var/lib/hildon-application-manager/available-updates to drive the
notifier icon.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Random comments:

While some people view the N900 as a mobile computer, and I use mine that
way, I do believe that the majority of people buying an N900 are/will be
buying it as a phone. I bought it primarily as a phone and everyone I know
that has considered buying it, have been making the consideration in terms
of it being a phone. Many try to decide whether to buy an iPhone, an
Android or an N900.

In terms of the ability to upgrade or not, one of my friends who is a big
iPhone fan comments that she doesn't think that you can sync the iPhone with
a Mac without it automatically making any free upgrades. However, for
upgrades that you have to pay for it is not automatic. That includes moving
from one generation of the operating system to another.

They also note that if you've jailbroken your iPhone you can control what
you get for upgrades. One final comment was that if you don't ever sync
your iPhone with a Mac, you can go indefinately without any upgrades.

Based on this, I do believe it is reasonable for many people not to upgrade
for extended periods.

My two cents,
Aldon

-----Original Message-----
From: maemo-developers-bounces@maemo.org
[mailto:maemo-developers-bounces@maemo.org]On Behalf Of Xavier Bestel
Sent: Thursday, February 25, 2010 5:12 AM
To: Graham Cobb
Cc: maemo-developers@maemo.org
Subject: Re: Maemo 5 PR1.2 and Extras


On Wed, 2010-02-24 at 17:48 +0000, Graham Cobb wrote:
> On Wednesday 24 February 2010 17:18:29 Thomas Tanner wrote:
> > On 24.02.10 18:04, Graham Cobb wrote:
> > > Why do I think many people will not upgrade? This device is a phone.
> >
> > The N900 is a mobile computer.
>
> I am talking about the people who perceive it to be a phone. "Like the
> iPhone".

I don't think iPhone owners really have the choice to not update.

Xav

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Niels Breet wrote:
> Hi,
>
> - Maemo 5 PR1.2 will ship with Extras enabled by default but will use
> distribution: fremantle-1.2
> - 'older' devices will continue to fetch from distribution: fremantle
> - Autobuilder will be updated when PR1.2 is released and promotion will
> only happen to fremantle-1.2
>

Sorry if I'm a little late to this discussion, but if we're creating a
new distribution/repository which means there will be problems with
existing install files, wouldn't it be easier just to hack apt-* on
PR1.2 so that it looks for a new fremantle-1.2 distribution for the
Extras repository when the distribution is called Extras/fremantle?

It's not going to be nice hacking apt-get, but surely this would be much
easier than hacking changes into numerous services so that they detect
the firmware version downloading the file in order that the correct
install file can be served up.

In addition, if I back up my Extras/fremantle catalogue prior to
reflashing with PR1.2, will PR1.2 then automatically replace
Extras/fremantle with Extras/fremantle-1.2 after I restore all my
catalogues? If it doesn't, my device may have both Extras/fremantle and
Extras/fremantle-1.2 in it's source list, or the former may
overwrite/replace the latter, so is this likely to be a problem? Most
likely yes, as I then run the risk of downloading incompatible Qt4.5
apps from Extras/fremantle.

If apt-* could be hacked in PR1.2 to special case Extras/fremantle into
Extras/fremantle-1.2 on the http download, then install files would
continue to work unchanged, and restored backups would also work unchanged.

In the same way, if an Extras/fremantle-1.3 is required in PR1.3, the
same hack would be applied to apt-* in PR1.3 and nobody would be any the
wiser.

Regards
Neil

_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

> Niels Breet wrote:
>
>> Hi,
>>
>>
>> - Maemo 5 PR1.2 will ship with Extras enabled by default but will use
>> distribution: fremantle-1.2
>> - 'older' devices will continue to fetch from distribution: fremantle
>> - Autobuilder will be updated when PR1.2 is released and promotion will
>> only happen to fremantle-1.2
>>
>
> Sorry if I'm a little late to this discussion, but if we're creating a
> new distribution/repository which means there will be problems with
> existing install files, wouldn't it be easier just to hack apt-* on PR1.2
> so that it looks for a new fremantle-1.2 distribution for the Extras
> repository when the distribution is called Extras/fremantle?
>
The Application manager will be changed to use fremantle-1.2 as default
distribution.

> It's not going to be nice hacking apt-get, but surely this would be much
> easier than hacking changes into numerous services so that they detect the
> firmware version downloading the file in order that the correct install
> file can be served up.
>

By setting the default distribution, we don't need to do any detection.

> In addition, if I back up my Extras/fremantle catalogue prior to
> reflashing with PR1.2, will PR1.2 then automatically replace
> Extras/fremantle with Extras/fremantle-1.2 after I restore all my
> catalogues? If it doesn't, my device may have both Extras/fremantle and
> Extras/fremantle-1.2 in it's source list, or the former may
> overwrite/replace the latter, so is this likely to be a problem? Most
> likely yes, as I then run the risk of downloading incompatible Qt4.5 apps
> from Extras/fremantle.
>
The default 'maemo.org' entry in your catalog list will be changed to use
fremante-1.2 as distribution. When restoring backups the default
repositories will not be overwritten.

All repositories you have added yourself will be restored as normal. But
keep in mind that extras-testing and extras-devel won't change as they are
expected to run the latest.

> If apt-* could be hacked in PR1.2 to special case Extras/fremantle into
> Extras/fremantle-1.2 on the http download, then install files would
> continue to work unchanged, and restored backups would also work
> unchanged.

There seems to be no need to hack apt with current changes.

> In the same way, if an Extras/fremantle-1.3 is required in PR1.3, the
> same hack would be applied to apt-* in PR1.3 and nobody would be any the
> wiser.

Let's hope that is not needed ;)

> Regards
> Neil
>

--
Niels Breet
maemo.org webmaster


_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Ideally (or not ;/) IMHO what is needed

1: Separate repo for every software release; It would be even better
if this can be "variableized" in sources.list files (I don't see
such a feature in /etc/apt/sources.list; on the other hand for example
/etc/yum.repos.d/fedora.repo there is $releasever and $basearch variables
to affect the location...)

In case repositories are identical one can be symlinked to another in
linux machine...

2: MADDE autobuilder :D

For this, there is a machine with filesystem with snapshotting
capabilities. After basic, minimal system for the purpose is
installed, MADDE with initial targets(*) is installed and then
filesystem snapshot taken. I'd guess this is like the current
autobuilder system is set up -- there is sandboxed compilation
environment without network access and reset to initial stage
before/after each compilation. When developer submits software
for building she can choose for which targets to build (or
system tries to compile on all targets and reports successess).
There might be an option to reject addition to repositories
if any of the compilation fails or not...

(*) MADDE target (as of 2010-03-22) is a combination of compiler toolchain,
(immutable) sysroot (and optionally qt tools) and has a name to
be referred with. The original plan (which sticks today) is that
sysroots are not to be modifed so compilation environment is exactly
the same in each invocation with same target (locally as in
(autobuilder) server). Well, as MADDE uses also standard Linux (and
Mac!) tools this cannot be enforced fully but we trust that the effort
is good enough and support can handle it better than trying to be more
exact (with it's own problems).

Of course, developers using scratchbox-based system (for whatever reason :)
could have similar setup (base scratchbox targets for each software
release)


This way users can choose not to update their system (when there is good
reason for that) and developers can think of what effort they are going
to put on supporting many software releases with their projects.


Tomi
MADDE developer
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Monday 22 March 2010 17:23:11 Tomi Ollila wrote:
> 1: Separate repo for every software release; It would be even better
> if this can be "variableized" in sources.list files (I don't see
> such a feature in /etc/apt/sources.list; on the other hand for example
> /etc/yum.repos.d/fedora.repo there is $releasever and $basearch variables
> to affect the location...)

The sources.list version component you're looking for is 'fremantle' ;) Arch
is determined/used automatically, but if you really know what you're doing, it
can be done manually, too, with $(ARCH).

Regards,
Attila
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers