Mailing List Archive

On 24 February 2010 11:21, Niels Breet <niels@maemo.org> wrote:

> Nokia will encourage people to upgrade to the latest release as much as
> possible and we expect people to switch to PR1.2 at a high rate.
>
> Please let me know what you think, we have to come to a consensus as soon
> as possible if we want to have this change included in PR1.2.
>

Off-topic question - would I be able to upgrade to PR1.2 if I'm still
missing PR1.1.1? For some strange reason I didn't receive that update OTA
and I don't feel like flashing my device.

--
Dawid 'evad' Lorenz * http://adl.pl

null://there is no place like 127.0.0.1

Hi Niels,

Am 24.02.2010 um 12:21 schrieb Niels Breet:

> - 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

I think that's a good idea. Separate builders an QA queues would bring little benefit but cause a lot of work and confusion.

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

Hi,

On 24 February 2010 12:21, Niels Breet <niels@maemo.org> wrote:
> Hi,
>
> Maemo 5 PR1.2 seems to be a release with some large changes which are not
> backwards compatible with previous releases. Most visible change will be
> the inclusion of Qt4.6, but there will be some other smaller changes.

after all the main/official way to write applications for N900 is using C+Gtk.

Developers who are using Qt (both C++ and Python) know that are using
something still experimental (even if already so good).
There are pro/cons using Qt right now. Ok, we'll have to rebuild/adapt
our applications when PR 1.2 is out, but for sure we'll be ready for
Harmattan/MeeGo development :)

So, go on!

--
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wednesday 24 February 2010 12:29:02 Andrea Grandi wrote:
> Developers who are using Qt (both C++ and Python) know that are using
> something still experimental (even if already so good).

That is incorrect. Even though Nokia calls Qt 4.5.x 'community supported', it
is shipped with all N900 devices from day 1 and is used by applications in
both Extras and the Ovi store. It misses the 4.6 goodies, but it does work
and IS based on a stable release of Qt.

Regards,
Attila

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

On Wednesday 24 February 2010 12:21:45 Niels Breet wrote:
>Please let me know what you think, we have to come to a consensus as soon
>as possible if we want to have this change included in PR1.2.

How will this PR1.2 change be reflected on the maemo.org dowloads section
(i.e. how will it be ensured that the user gets presented the correct
install-this link) ?

Second, is there a safety mechanism considered that will disallow inclusion
of 'the other' firmware's repository to prevent potential version-related
breakage ?

> This will effectively mean that the 'old' Extras will not get any updates.
> New versions of applications will go to fremantle-1.2 Extras. Extras-devel
> and Extras-testing will not be changed, as they are expected to run the
> latest and greatest anyway.

What happens to apps (especially those with Qt dependencies) _currently_ in
Extras, i.e., how will they get to the fremantle1.2 Extras repo ?

Regards,
Attila

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

hi,

Niels Breet wrote:
> Maemo 5 PR1.2 seems to be a release with some large changes which are not
> backwards compatible with previous releases. Most visible change will be
> the inclusion of Qt4.6, but there will be some other smaller changes.

When you say "not backwards compatible", does that mean that
applications built with 1.0 or 1.1 will not work on 1.2? Or is it ABI
compatible, but adds new interfaces, so that applications built with 1.2
won't necessarily work on 1.1 or 1.0 (which is a different & less
serious issue in that if you don't use the new interfaces your
application should still work unchanged on the older releases)?

Cheers,
Dave.

--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org

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

> On Wednesday 24 February 2010 12:21:45 Niels Breet wrote:
>
>> Please let me know what you think, we have to come to a consensus as
>> soon as possible if we want to have this change included in PR1.2.
>
> How will this PR1.2 change be reflected on the maemo.org dowloads section
> (i.e. how will it be ensured that the user gets presented the correct
> install-this link) ?

A different .install file can be offered based on your browser string.
>
> Second, is there a safety mechanism considered that will disallow
> inclusion of 'the other' firmware's repository to prevent potential
> version-related breakage ?
>

There is not a lot we can do there. If a user adds the repository on an
'old' device, some applications just won't install because dependencies
are missing.

>> This will effectively mean that the 'old' Extras will not get any
>> updates. New versions of applications will go to fremantle-1.2 Extras.
>> Extras-devel
>> and Extras-testing will not be changed, as they are expected to run the
>> latest and greatest anyway.
>
> What happens to apps (especially those with Qt dependencies) _currently_
> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?
>
The Qt apps are currently blocked from being promoted to prevent issues.
The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt
4.5.3 is not available in Extras and will probably not be available on any
repository enabled by default on the device. This means that applications
depending on this, will not work.

Those applications need actual changes to work with Qt4.6 iirc.
>
> Regards,
> Attila
>

--
Niels Breet
maemo.org webmaster


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

I don't know whether this has been discussed before:

what is wrong with forcing users that have the necessary Internet access
to download applications from Extras, to also upgrade to
the lastest firmware, which is supposed to fix bugs anyway.
Why would anybody not upgrade the firmware?
Why is backwards compatibility necessary for Fremantle minor releases?

Enforcing the requirement could make our life so much easier.
We could have a package "maemo-extras" which enables the extras
repository and which always depends on the latest firmware version.
Or we could add the current firmware version to the dependencies of
packages build on autobuilder.
Users who don't want to upgrade would have to stick with the on-device
applications.

cheers

On 24.02.10 12:21, Niels Breet wrote:
> Maemo 5 PR1.2 seems to be a release with some large changes which are not
> backwards compatible with previous releases....
> - 'older' devices will continue to fetch from distribution: fremantle
> This will effectively mean that the 'old' Extras will not get any updates.
...
> Nokia will encourage people to upgrade to the latest release as much as
> possible and we expect people to switch to PR1.2 at a high rate.


--
Thomas Tanner ------
email: tanner@gmx.de
GnuPG: 1024/5924D4DD
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

I would prefer if devs could get the PR1.2 update a week or so earlier than
the general release. This way most of the necessary updates from Qt 4.5 to
4.6 could be done before the general public gets the new firmware. Also the
normal 10 day quarantine should not apply to these case.

Thanks,

Sascha

Hallo!

>> What happens to apps (especially those with Qt dependencies) _currently_
>> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?

> The Qt apps are currently blocked from being promoted to prevent issues.
> The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt
> 4.5.3 is not available in Extras and will probably not be available on
any
> repository enabled by default on the device. This means that applications
> depending on this, will not work.
>
> Those applications need actual changes to work with Qt4.6 iirc.

No, what happens witht he packages currently ine extras?

* Will they automatically moved to fremantle-1.2 Extras? Sounds like this
is not possible.
* Will they automatically rebuild against then current SDK? f yes, how do
we find out it will work?
* Will fremantle-1.2 Extras be intially empty and we have to get all
packages in it again trhought he extras-testing process (Ooohhh, noooo,
that will take ages!)

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

On Wednesday 24 February 2010 11:21:45 Niels Breet wrote:
> - 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

I can't say I like this. My personal view is that there will be a lot of
people running earlier software for quite a long time. How long do Nokia
believe it will be before 80% of new devices being sold in retail stores have
PR1.2 pre-installed? Can we keep track of stats showing how many people are
accessing the old repository?

However, as I don't have any evidence, I don't object to this approach. It at
least leaves the door open for the community to decide later that we do need
to update the fremantle extras, if necessary. Let's go with it for now.

We do need to have a plan for exactly when the changeovers will happen. When
will the autobuilder switch over and when will the promotion interface
change? Developers need to know so they know what they need to do if they
need to get a final update out to PR1.1 users.

For example, I have the GPE stuff sitting in extras-testing. I would really
like this to make it into the PR1.1 repository, even though the next update
will only make it to PR1.2.

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

Hi,

On 24 February 2010 13:27, Sascha Mäkelä <sascha.makela@gmail.com> wrote:
> I would prefer if devs could get the PR1.2 update a week or so earlier than
> the general release. This way most of the necessary updates from Qt 4.5 to
> 4.6 could be done before the general public gets the new firmware. Also the
> normal 10 day quarantine should not apply to these case.

it would be a nice idea imho :)
I would like it too!

--
Andrea Grandi
email: a.grandi [AT] gmail [DOT] com
website: http://www.andreagrandi.it
PGP Key: http://www.andreagrandi.it/pgp_key.asc
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Hello,

On Wednesday 24 of February 2010, Niels Breet wrote:
> - Maemo 5 PR1.2 will ship with Extras enabled by default but will use
> distribution: fremantle-1.2

IMHO, it may be better to have a distribution name like freemantle-2 just to
not cause confusions if/when PR1.3 (or other) is released. Having 1.2 in name
implies that it should be changed in every new PR.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

> hi,
>
> Niels Breet wrote:
>
>> Maemo 5 PR1.2 seems to be a release with some large changes which are
>> not backwards compatible with previous releases. Most visible change
>> will be the inclusion of Qt4.6, but there will be some other smaller
>> changes.
>
> When you say "not backwards compatible", does that mean that
> applications built with 1.0 or 1.1 will not work on 1.2?

That would be forward compatible in my book ;)

> Or is it ABI
> compatible, but adds new interfaces, so that applications built with 1.2
> won't necessarily work on 1.1 or 1.0 (which is a different & less serious
> issue in that if you don't use the new interfaces your application should
> still work unchanged on the older releases)?

Applications built on PR1.2 won't work on older versions. There are
exceptions, some applications might work, but those make this very
complicated.

>
> Cheers,
> Dave.
>
>
> --
> maemo.org docsmaster Email: dneary@maemo.org
> Jabber: bolsh@jabber.org
>

--
Niels Breet
maemo.org webmaster


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

> On Wednesday 24 February 2010 11:21:45 Niels Breet wrote:
>
>> - 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
>
> I can't say I like this. My personal view is that there will be a lot of
> people running earlier software for quite a long time. How long do
> Nokia
> believe it will be before 80% of new devices being sold in retail stores
> have PR1.2 pre-installed? Can we keep track of stats showing how many
> people are accessing the old repository?

Nokia retail figures -> ask Nokia. I'm pretty sure that getting that info
will not be easy.

I have the Extras downloads figures now. So we can check the percentages
after the switch.

> However, as I don't have any evidence, I don't object to this approach.
> It at
> least leaves the door open for the community to decide later that we do
> need to update the fremantle extras, if necessary. Let's go with it for
> now.
>
> We do need to have a plan for exactly when the changeovers will happen.
> When
> will the autobuilder switch over and when will the promotion interface
> change? Developers need to know so they know what they need to do if they
> need to get a final update out to PR1.1 users.

The same day as the SDK will be released seems to be a right time for me.
I don't know the exact release date of course. I'll make sure things are
prepared in advance, so the actual switch can be done relatively quickly.
>
> For example, I have the GPE stuff sitting in extras-testing. I would
> really like this to make it into the PR1.1 repository, even though the
> next update will only make it to PR1.2.

True, this is something we need to think of. It is clear for every
promotion happening before the PR1.2 release, but when we switch it will
go to fremantle-1.2 by default. (Unless we do something to prevent that)

>
> Graham


--
Niels Breet
maemo.org webmaster


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

> Hallo!
>
>
>>> What happens to apps (especially those with Qt dependencies)
>>> _currently_
>>> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?
>
>> The Qt apps are currently blocked from being promoted to prevent
>> issues. The fremantle-1.2 repository will probably need to be 'legacy'
>> clean. Qt 4.5.3 is not available in Extras and will probably not be
>> available on
> any
>> repository enabled by default on the device. This means that
>> applications depending on this, will not work.
>>
>> Those applications need actual changes to work with Qt4.6 iirc.
>>
>
> No, what happens witht he packages currently ine extras?
>

fremantle-1.2 will just be a copy with applications which don't work removed.

>
> * Will they automatically moved to fremantle-1.2 Extras?

All apps that are not touching the changed APIS are expected to work just
fine. Nokia people are running Extras apps on PR1.2 test images just fine.

>* Will they automatically rebuild against then current
> SDK? if yes, how do we find out it will work?

Testing shows not a lot of problems, only the obvious Qt apps.

> * Will fremantle-1.2 Extras be intially empty and
> we have to get all packages in it again trhought he extras-testing process
> (Ooohhh, noooo,
> that will take ages!)
>
No, don't worry.

> --
> Gruß...
> Tim
>

--
Niels Breet
maemo.org webmaster


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

> I would prefer if devs could get the PR1.2 update a week or so earlier
> than the general release. This way most of the necessary updates from Qt
> 4.5 to
> 4.6 could be done before the general public gets the new firmware.

It looks like there is a chance to get the SDK out before the actual
device OS update, but the discussion is still going on. I hope to have
more information on that later.

> Also
> the normal 10 day quarantine should not apply to these case.

I'm not sure if that is a good idea. The quarantine is there for a reason,
the switch between these Qt releases can actually introduce issues. If we
have the SDK in time, then the overlap will be minimal anyway.

> Thanks,
>
>
> Sascha

--
Niels Breet
maemo.org webmaster


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

On Wed, Feb 24, 2010 at 15:30, Niels Breet <niels@maemo.org> wrote:

> > Also
> > the normal 10 day quarantine should not apply to these case.
>
> I'm not sure if that is a good idea. The quarantine is there for a reason,
> the switch between these Qt releases can actually introduce issues. If we
> have the SDK in time, then the overlap will be minimal anyway.
>

I was under the impression that for many Qt apps a simple repackaging will
do the trick. If this is the case, would it not make sense to make those
updates available? After all, before the updates are released to Extras,
many users are going to have Qt apps that won't work on their N900. Surely
we want to correct that as soon as possible. And what about existing Qt 4.5
based apps in Extras? Should the be demoted when PR1.2 is released?

About that SDK. Could we have something on MADDE too?

Cheers,

Sascha

On Wednesday 24 February 2010 13:20:40 Thomas Tanner wrote:
> Why would anybody not upgrade the firmware?
> Why is backwards compatibility necessary for Fremantle minor releases?
> Enforcing the requirement could make our life so much easier.

There can be a number of reasons, ranging from various regressions (like
sticking to 42-11 because of WiFi issues in 51-1), policies (if it ain't
broken, don't fix it, not all bugs affect all people), cost/stability (I
might not want to upgrade when roaming) or simply firmware non-availability
(firmwares are not rolled out simultaneously for all countries, ask UK
folks :). Forced upgrades are usually a last-resort measure, done only if
there is a legal reason (like compliance with some regulations, maybe things
related to emergency calls, etc).

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

On 24.02.10 15:18, Attila Csipa wrote:
> On Wednesday 24 February 2010 13:20:40 Thomas Tanner wrote:
>> Why would anybody not upgrade the firmware?
>> Why is backwards compatibility necessary for Fremantle minor releases?
>> Enforcing the requirement could make our life so much easier.
> There can be a number of reasons, ranging from various regressions (like
> sticking to 42-11 because of WiFi issues in 51-1), policies (if it ain't
> broken, don't fix it, not all bugs affect all people), cost/stability (I
> might not want to upgrade when roaming) or simply firmware non-availability
> (firmwares are not rolled out simultaneously for all countries, ask UK
> folks :). Forced upgrades are usually a last-resort measure, done only if
> there is a legal reason (like compliance with some regulations, maybe things
> related to emergency calls, etc).

Forced upgrades of some components for installation of a new package is
standard practice for all package management systems (keyword version
dependencies).
I think the main problem is that the mp-fremantle-pr packages
hardcodes the exact version of all PR packages instead of specifying the
minimum version. If a user could selectively upgrade a core package
without conflicting with mp-fremantle-pr they would not be forced to
completely upgrade the firmware for new extras apps.
(BTW, the broken dependency specification in the PR also makes it
impossible to remove unnecessary language packs)

In a (Debian based) distribution the proper way to handle such conflicts
would be to specify the minimum required version in each extras apps
(e.g. qt4.5) and to switch to a new package name if the new package is
no longer backwards compatible (qt4.6).

If it not possible to install both qt4.5 and qt4.6 due to space
constraints the user should have the option to either deinstall old
qt4.5 apps or wait until all his extras apps are upgraded 4.6.

--
Thomas Tanner ------
email: tanner@gmx.de
GnuPG: 1024/5924D4DD
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

>> How will this PR1.2 change be reflected on the maemo.org dowloads section
>> (i.e. how will it be ensured that the user gets presented the correct
>> install-this link) ?
>
>A different .install file can be offered based on your browser string.

How are you going to make sure you catch all of them ? For MicroB, okay, but
Firefox, Tear, Midori, whatnot ? Does not really sound like a foolprof
solution (you also need to sync with Maemo Select, and just hope that there
are not too many links floating around) :(

>> Second, is there a safety mechanism considered that will disallow
>> inclusion of 'the other' firmware's repository to prevent potential
>> version-related breakage ?
>
>There is not a lot we can do there. If a user adds the repository on an
>'old' device, some applications just won't install because dependencies
>are missing.

There are a few more troublesome scenarios that can present themselves - like
if someone adds the old repo, and has a repo-refresh issue with the new one
afterwards (I often have this problem with extras-testing and extras-devel).
In both this and the scenario you mention, H-A-M/apt will prevent downgrades,
luckily, but it's easy to cut off your own upgrade path if you DO manage to
install something from the wrong repo.

>> What happens to apps (especially those with Qt dependencies) _currently_
>> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?
>>
>The Qt apps are currently blocked from being promoted to prevent issues.

It would be helpful if this would be visible from the testing page, too (not
just for 4.6). I have several Qt4.5 dependent packages in the QA queue
nearing required quarantine delay fulfillment. It's just a waste of tester
and developer time then.

>The fremantle-1.2 repository will probably need to be 'legacy' clean. Qt
>4.5.3 is not available in Extras and will probably not be available on any
>repository enabled by default on the device. This means that applications
>depending on this, will not work.
>
>Those applications need actual changes to work with Qt4.6 iirc.

Okay, so we basically ditch Qt4.5-compiled applications currently in Extras.
Is the Ovi team aware of this as there are quite a few Qt 4.5 applications in
Ovi repositories,too ? Will they get their fremantle1.2 repo, too (I know,
ask them -> wait for a meaningful response so long that it becomes moot :) )
or will they hope Qt ABI compatibility gets them through ? And if you think
Ovi has no bearing on Extras downloads, take into consideration Firefox is in
Ovi, so if browser string based info is used, it will bite you if it's not
handled in a timely manner :)

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

Hi,

Niels Breet wrote:
>> Niels Breet wrote:
>>> Maemo 5 PR1.2 seems to be a release with some large changes which are
>>> not backwards compatible with previous releases. Most visible change
>>> will be the inclusion of Qt4.6, but there will be some other smaller
>>> changes.
>> When you say "not backwards compatible", does that mean that
>> applications built with 1.0 or 1.1 will not work on 1.2?
>
> That would be forward compatible in my book ;)

Tomayto-tomahto.

backwards compatible usually means that new interfaces support old
applications. Windows 95 was backwards compatible with Windows 3.1, so
old .exes still ran unchanged. You didn't even have to recompile.

That's what I'm asking - will PR 1.0 packages & executables continue to
work on PR1.2?

>> Or is it ABI
>> compatible, but adds new interfaces, so that applications built with 1.2
>> won't necessarily work on 1.1 or 1.0 (which is a different & less serious
>> issue in that if you don't use the new interfaces your application should
>> still work unchanged on the older releases)?
>
> Applications built on PR1.2 won't work on older versions. There are
> exceptions, some applications might work, but those make this very
> complicated.

All applications? That seems unusual - especially since the GNOME
project (and thus a bunch of the libraries in the API) work very hard to
ensure API & ABI compatibility. If I compile, unchanged, an application
with the PR1.2 API which previously worked on PR1.0, I would expect the
new package to continue to work correctly. I would expect it to stop
working only after I started using interfaces not available in the old
platform.

Cheers,
Dave.

--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org

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

Hi,

Sascha Mäkelä wrote:
> I was under the impression that for many Qt apps a simple repackaging
> will do the trick. If this is the case, would it not make sense to make
> those updates available? After all, before the updates are released to
> Extras, many users are going to have Qt apps that won't work on their
> N900. Surely we want to correct that as soon as possible. And what about
> existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2
> is released?

I know of at least one case where Maemo-specific changes were made in Qt
4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon
integration). So it is entirely possible that some apps which previously
compiled will not do so after the upgrade.

Cheers,
Dave.



--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org

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

On 24 February 2010 14:18, Attila Csipa <maemo@csipa.in.rs> wrote:

> simply firmware non-availability
> (firmwares are not rolled out simultaneously for all countries, ask UK
> folks :).
>

Me me me! I really wish to know "officially" why PR1.1.1 still hasn't been
rolled as OTA update for my device...

--
Dawid 'evad' Lorenz * http://adl.pl

null://signatures are for wimps

On Wednesday 24 February 2010 15:43:47 Thomas Tanner wrote:
> In a (Debian based) distribution the proper way to handle such conflicts
> would be to specify the minimum required version in each extras apps
> (e.g. qt4.5) and to switch to a new package name if the new package is
> no longer backwards compatible (qt4.6).

> If it not possible to install both qt4.5 and qt4.6 due to space
> constraints the user should have the option to either deinstall old
> qt4.5 apps or wait until all his extras apps are upgraded 4.6.

The complications stem from the way this is handled in Maemo, at least for Qt.
I just hope this slightly complex PR1.2 Qt transition is not a snowball
effect of how some Maemoisms were added (hacked :) ) into Qt4.5/4.6 and even
more that this is not a sign of how these things will be handled in the
future. Backwards compatibility was something Qt4 was very well known for,
and desktop environments often bump their Qt versions for backports (hell,
even LTS versions of Ubuntu did that), without requiring
repository/application hoop-jumping.


> Forced upgrades of some components for installation of a new package is
> standard practice for all package management systems (keyword version
> dependencies).

It seems we have a different definition of forced upgrade :) (I would use the
required term for what you described)


Regards,
Attila


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

Hello,

On Wednesday 24 of February 2010, Dave Neary wrote:
> Sascha Mäkelä wrote:
> > I was under the impression that for many Qt apps a simple repackaging
> > will do the trick. If this is the case, would it not make sense to make
> > those updates available? After all, before the updates are released to
> > Extras, many users are going to have Qt apps that won't work on their
> > N900. Surely we want to correct that as soon as possible. And what about
> > existing Qt 4.5 based apps in Extras? Should the be demoted when PR1.2
> > is released?
>
> I know of at least one case where Maemo-specific changes were made in Qt
> 4.5 for Maemo and are no longer available in Qt 4.6 (related to Hildon
> integration). So it is entirely possible that some apps which previously
> compiled will not do so after the upgrade.

Is this a library-only issue or a system issue? i.e. is the problem in the new
qt library or (let's say) in the capabilities of the new system's components
(e.g. removed dbus interfaces).

If this is a library-only issue, then there is no reason (except from disk
space, but /opt should be a viable solution) why you could not have the newer
versions of "problematic" libraries coexist with their old versions. For
example, one could have both libqt4-core and libqt4-6-core. Old apps will
still be linked against libqt4-core while new apps will be linked against
libqt4-6-core. Then, at some point at the future (PR1.3 ?) you could
completely remove those old libraries.

... then again I do not have much experience on doing such things.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Graham Cobb wrote:
> I can't say I like this. My personal view is that there will be a lot of
> people running earlier software for quite a long time. How long do Nokia
> believe it will be before 80% of new devices being sold in retail stores have
> PR1.2 pre-installed? Can we keep track of stats showing how many people are
> accessing the old repository?

How can you not like this? What is your reasoning? You brought this same
response to the last Maemo update, and I still do not understand it.

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.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

>> This will effectively mean that the 'old' Extras will not get any updates.
>> New versions of applications will go to fremantle-1.2 Extras.
>> Extras-devel
>> and Extras-testing will not be changed, as they are expected to run the
>> latest and greatest anyway.
>
>What happens to apps (especially those with Qt dependencies) _currently_ in
>Extras, i.e., how will they get to the fremantle1.2 Extras repo ?

Why not have 2 repos for Extras

1 called Extras Legacy (aka current Extras)
1 called Extras (aka fremantle-1.2 Extras)

The only inconvenience I can think of is users have an addtional repo on the
list, shouldn't do any harm!

Cheers
--
View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626546.html
Sent from the maemo-developers mailing list archive at Nabble.com.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Thomas Tanner wrote:
> Forced upgrades of some components for installation of a new package is
> standard practice for all package management systems (keyword version
> dependencies).
> I think the main problem is that the mp-fremantle-pr packages
> hardcodes the exact version of all PR packages instead of specifying the
> minimum version. If a user could selectively upgrade a core package
> without conflicting with mp-fremantle-pr they would not be forced to
> completely upgrade the firmware for new extras apps.
> (BTW, the broken dependency specification in the PR also makes it
> impossible to remove unnecessary language packs)

I agree with you completely with your first post, however, you touched
on why Maemo doesn't work this way.

For the time being, the proposal Niels suggested is the least messy.
We're not creating a new Maemo 5 sub-version this way.

Maemo/Nokia folks - is there any plans on implementing the brainstorm
idea[1] on open-source packages any time before MeeGo? This would
alleviate some of the update mess. Closed binaries could then be
included into a smaller "Maemo 5" update that can work with the Extras
repo without having to branch it.

[1]
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wednesday 24 February 2010 16:42:16 Michael Cronenworth wrote:
> 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.

Still, that does not address the question of regressions. For example WiFi
(which I use a lot) in 51-1 had a regression that was in my particular case
so bad I had to revert to 42-11 until a fix was introduced with 2-8.

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

Hi,

On Wed, Feb 24, 2010 at 5:06 PM, Attila Csipa <maemo@csipa.in.rs> wrote:
> The complications stem from the way this is handled in Maemo, at least for Qt.
> I just hope this slightly complex PR1.2 Qt transition is not a snowball
> effect of how some Maemoisms were added (hacked :) ) into Qt4.5/4.6 and even
> more that this is not a sign of how these things will be handled in the
> future. Backwards compatibility was something Qt4 was very well known for,
> and desktop environments often bump their Qt versions for backports (hell,
> even LTS versions of Ubuntu did that), without requiring
> repository/application hoop-jumping.
Qt packaging now is managed by Qt team and this will be first official
Qt-supported version of Qt to Maemo platform.
So many two-letter acronyms in one sentence...

Anyway, this is a bit different from desktop case as package
maintainers are changed for Qt delivery (from community volunteers to
Nokia Trolls) and apparently the way to package is changed as well. I
have not compared it with the Debian or other distributions' builds
though.

Whatever is included in Qt build for Maemo is maintained by Trolltech
team. This should leave questions regarding the compatibility
answered, I hope. And actual source code is in qt.gitorious.org.

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

Venomrush wrote:
> Why not have 2 repos for Extras
>
> 1 called Extras Legacy (aka current Extras)
> 1 called Extras (aka fremantle-1.2 Extras)
>
> The only inconvenience I can think of is users have an addtional repo on the
> list, shouldn't do any harm!

They will fragment the Maemo 5 community unless the auto-builder will
build across both repos, as I will not be updating my apps on a "Legacy"
repo if one is created.

The way you propose makes it seem like Nokia is releasing a whole new
Maemo version (Maemo 5 -> Maemo 5.99), which is not what should be
visible to the end-user. Maemo 5 should continue being Maemo 5.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

> -----Original Message-----
> From: maemo-developers-bounces@maemo.org [mailto:maemo-developers-
> bounces@maemo.org] On Behalf Of ext Niels Breet
> Sent: 24 February, 2010 14:19
> To: Attila Csipa
> Cc: maemo-developers@maemo.org
> Subject: Re: Maemo 5 PR1.2 and Extras
>
> > On Wednesday 24 February 2010 12:21:45 Niels Breet wrote:
> >

> > What happens to apps (especially those with Qt dependencies)
> _currently_
> > in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?
> >
> The Qt apps are currently blocked from being promoted to prevent
> issues.
> The fremantle-1.2 repository will probably need to be 'legacy' clean.
> Qt
> 4.5.3 is not available in Extras and will probably not be available on
> any
> repository enabled by default on the device. This means that
> applications
> depending on this, will not work.
>
> Those applications need actual changes to work with Qt4.6 iirc.

Some may and some don't. Some Qt apps compiled against 4.5 will work with 4.6 without any issues. I do not know which part of the ABI has changed, so no idea what would break. Sorry, no statistics on this one, just some small personal tests.

To be safe it would make sense to recompile the Qt apps with the 1.2 SDK when letting them to Fremantle-1.2.

Tero

> >
> > Regards,
> > Attila
> >
>
> --
> Niels Breet
> maemo.org webmaster
>
>
> _______________________________________________
> 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

Hi,

Michael Cronenworth wrote:
> How can you not like this? What is your reasoning? You brought this same
> response to the last Maemo update, and I still do not understand it.

Let's say that there are 10,000 applications in Extras.

Now every N900 owner can get all of those apps.

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

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

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

3. To mitigate 2, we decide that all Extras apps need to be recompiled
with the new SDK, resulting in a number of applications which fit into
both the categories above - some apps stop working until the user
upgrades the firmware, other apps don't build & require changes and an
SDK upgrade from the developer.

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).

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. I
imagine that this is why Graham's not happy about an SDK which isn't
backwards compatible.

Cheers,
Dave.

--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org

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

>>> How will this PR1.2 change be reflected on the maemo.org dowloads
>>> section (i.e. how will it be ensured that the user gets presented the
>>> correct install-this link) ?
>>
>> A different .install file can be offered based on your browser string.
>>
>
> How are you going to make sure you catch all of them ? For MicroB, okay,
> but Firefox, Tear, Midori, whatnot ? Does not really sound like a foolprof
> solution (you also need to sync with Maemo Select, and just hope that
> there are not too many links floating around) :(
>

I see no way to support other browsers if they don't expose the installed
OS version. But I think this is how Ovi checks it too?

Maemo Select links directly to us, so there is no issue with .install
files there.

>>> Second, is there a safety mechanism considered that will disallow
>>> inclusion of 'the other' firmware's repository to prevent potential
>>> version-related breakage ?
>>
>> There is not a lot we can do there. If a user adds the repository on an
>> 'old' device, some applications just won't install because
>> dependencies are missing.
>
> There are a few more troublesome scenarios that can present themselves -
> like if someone adds the old repo, and has a repo-refresh issue with the
> new one afterwards (I often have this problem with extras-testing and
> extras-devel). In both this and the scenario you mention, H-A-M/apt will
> prevent downgrades, luckily, but it's easy to cut off your own upgrade
> path if you DO manage to install something from the wrong repo.

If you break something, you get to keep both pieces. Being able to break
things yourself is a powerful thing. I don't see how we can prevent
installing something from a wrong repo.


>>> What happens to apps (especially those with Qt dependencies)
>>> _currently_
>>> in Extras, i.e., how will they get to the fremantle1.2 Extras repo ?
>>>
>> The Qt apps are currently blocked from being promoted to prevent
>> issues.
>
> It would be helpful if this would be visible from the testing page, too
> (not
> just for 4.6). I have several Qt4.5 dependent packages in the QA queue
> nearing required quarantine delay fulfillment. It's just a waste of
> tester and developer time then.
>

Well, no. They can still end up in fremantle for PR1.1 and lower.

>> The fremantle-1.2 repository will probably need to be 'legacy' clean.
>> Qt
>> 4.5.3 is not available in Extras and will probably not be available on
>> any repository enabled by default on the device. This means that
>> applications depending on this, will not work.
>>
>> Those applications need actual changes to work with Qt4.6 iirc.
>>
>
> Okay, so we basically ditch Qt4.5-compiled applications currently in
> Extras.
> Is the Ovi team aware of this as there are quite a few Qt 4.5 applications
> in Ovi repositories,too ? Will they get their fremantle1.2 repo, too (I
> know, ask them -> wait for a meaningful response so long that it becomes
> moot :) ) or will they hope Qt ABI compatibility gets them through ? And
> if you think Ovi has no bearing on Extras downloads, take into
> consideration Firefox is in Ovi, so if browser string based info is used,
> it will bite you if it's not handled in a timely manner :)

Don't know what Ovi is going to do, but my bet is that Nokia aims at Qt4.6
anyway to in line with Symbian?

Just trying to do the best thing for everybody, easiest would be just to
not care about older OS versions.
>
> Regards,
> Attila
>
>

--
Niels Breet
maemo.org webmaster


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

> They will fragment the Maemo 5 community unless the auto-builder will
> build across both repos, as I will not be updating my apps on a "Legacy"
> repo if one is created.
>
> The way you propose makes it seem like Nokia is releasing a whole new
> Maemo version (Maemo 5 -> Maemo 5.99), which is not what should be
> visible to the end-user. Maemo 5 should continue being Maemo 5.

It's such a big change that we're discussing about it right now.

You do not need to update any apps in Legacy. Apps in Legacy remains the
same and does not get any further development work.

It's there so:
1. Users can browse pre-PR1.2 apps that are already working (apps without
needing to update to work with PR1.2)
2. Apps in Legacy repo not working in PR1.2 gets updated and put into the
new Extras & get removed from Legacy repo too

Post-PR1.2, all development effort should be put into updating apps for the
new Extras.

I hope it's abit clearer now.

Cheers
--
View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626768.html
Sent from the maemo-developers mailing list archive at Nabble.com.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Dave Neary on 02/24/2010 10:01 AM wrote:
> 1. New uploads get compiled with the new SDK, and get downloaded onto
> phones with the old OS, where they don't work.

How? The only way that could happen is if a power-user downloaded the
file manually and attempted to use dpkg manually. This should be frowned
upon.

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

The auto-builder builds our apps. Their builds would fail and never make
it to Extras.

>
> 3. To mitigate 2, we decide that all Extras apps need to be recompiled
> with the new SDK, resulting in a number of applications which fit into
> both the categories above - some apps stop working until the user
> upgrades the firmware, other apps don't build& require changes and an
> SDK upgrade from the developer.
>

It happens all the time in other Linux distributions. Fedora just went
through the Qt4.5 to 4.6 transition itself! I don't see why there is
resistance to this when it is a very minor change. If such resistance is
warranted, let's call this Maemo 5.2 instead of Maemo 5.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wed, Feb 24, 2010 at 6:01 PM, Dave Neary <dneary@maemo.org> wrote:

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

That's their own screwup, I guess (which they notice immediately when
trying to upload).

The group most impacted are the Qt users, which are quite likely to be
eagerly waiting for 4.6.2 anyway (so it won't come as a surprise).

> 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. I

Undoubtedly there will be certain degree of badness. Niels' current
suggestion at least avoids the badness on user end.

Barring regressions, we can probably expect everybody to upgrade to
1.2 in timely manner.

--
Ville M. Vainio
http://tinyurl.com/vainio
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Venomrush wrote:
> You do not need to update any apps in Legacy. Apps in Legacy remains the
> same and does not get any further development work.

That's what Niels is proposing, unless I am mistaken.

fremantle = Legacy
fremantle-1.2 = The new "Extras"
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

> You do not need to update any apps in Legacy. Apps in Legacy remains the
> same and does not get any further development work.

Hmm sorry for the confusion, I should say if apps in Legacy are getting
updates, they'll be move to Extras.

It's not exactly what Niels's proposing, but just my suggestion.
--
View this message in context: http://n2.nabble.com/Maemo-5-PR1-2-and-Extras-tp4625110p4626893.html
Sent from the maemo-developers mailing list archive at Nabble.com.
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wednesday 24 February 2010 17:25:20 Michael Cronenworth wrote:
> Dave Neary on 02/24/2010 10:01 AM wrote:
> > 1. New uploads get compiled with the new SDK, and get downloaded onto
> > phones with the old OS, where they don't work.
>
> How? The only way that could happen is if a power-user downloaded the
> file manually and attempted to use dpkg manually. This should be frowned
> upon.

.install files, which have been increasingly stated as the preferred method of
installing software, also contain repository information. That's how Ovi
works, that's how Maemo Select works, and that's how maemo.org/downloads
works, so it's not unfathomable that users end up with the wrong
repositories.

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

On Wednesday 24 February 2010 15:42:16 Michael Cronenworth wrote:
> Graham Cobb wrote:
> > I can't say I like this. My personal view is that there will be a lot of
> > people running earlier software for quite a long time. How long do Nokia
> > believe it will be before 80% of new devices being sold in retail stores
> > have PR1.2 pre-installed? Can we keep track of stats showing how many
> > people are accessing the old repository?
>
> How can you not like this? What is your reasoning? You brought this same
> response to the last Maemo update, and I still do not understand it.

I am sure we wil have to agree to differ but you asked my reasoning, so here
it is...

I think that many users will never upgrade the OS, and of those who do, their
upgrades will be spread over a period of many months. As a hobbyist
developer I release and support my software because I like to make it
available to people. I don't think the Maemo infrastructure should prevent
me from supporting my users who choose not to upgrade, and nor should it
prevent some new app I create from having access to those users.

Why do I think many people will not upgrade? This device is a phone. I never
upgraded my last phone, I have never upgraded my work-provided Blackberry, I
don't know a single person amongst my friends who has ever upgraded their
phone OS, for any reason. Many people will be very worried about upgrading
the phone OS -- this is an expensive device: "if it ain't broke, don't fix
it". I don't have any data but my guess is that 50% of people who buy an
N900 will never upgrade the OS on it.

We have some very limited data from the earlier Maemo devices. Those were not
phones -- they were much more like computers. I think most people upgraded
them but still some chose not to (even though the first version of the 770
software had a serious data corruption bug). I still support those users and
I would like to be able to continue to support my N900 users who choose not
to upgrade.

More seriously, I believe that there is still no Vodafone UK release of
PR1.1.1 (is there of PR1.1 yet?). The customised software releases are not
released at the same time as the general release -- those users cannot
upgrade until their operator chooses to release the new version (which may be
never!).

> 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.

Sorry, no. I choose not to discount personal preferences.

I'm not expecting you to agree but you asked why. You are free to choose that
you will not support users running on anything other than the latest OS.
Just don't force the same decision on me.

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

On Wednesday 24 February 2010 16:26:44 Ville M. Vainio wrote:
> Barring regressions, we can probably expect everybody to upgrade to
> 1.2 in timely manner.

I disagree, but I may be completely wrong. It will be very interesting to
see. What do you consider "timely"? 3 months? My prediction: in 3 months
time, >50% of N900 devices will still be checking the "fremantle", not
the "fremantle-1.2" repository.

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

On Wed, Feb 24, 2010 at 7:08 PM, Graham Cobb <g+770@cobb.uk.net> wrote:

> On Wednesday 24 February 2010 16:26:44 Ville M. Vainio wrote:
>> Barring regressions, we can probably expect everybody to upgrade to
>> 1.2 in timely manner.
>
> I disagree, but I may be completely wrong.  It will be very interesting to
> see.  What do you consider "timely"?  3 months?  My prediction: in 3 months
> time, >50% of N900 devices will still be checking the "fremantle", not
> the "fremantle-1.2" repository.

My guess would be few weeks. N900 is an "enthusiast" device, for
better or worse.

--
Ville M. Vainio
http://tinyurl.com/vainio
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

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.
If you want to use it as a phone, i.e. without applications from extras
or Ovi, then there is no need to upgrade the firmware.
If you want to use it as a computer by installing applications,
you should upgrade your OS, especially to get security updates for a
Internet-centric device.
Maintaining software and working around bugs for every minor release is
a nightmare. Only for different major releases and devices it is justified.

--
Thomas Tanner ------
email: tanner@gmx.de
GnuPG: 1024/5924D4DD
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wed, Feb 24, 2010 at 7:04 PM, Graham Cobb <g+770@cobb.uk.net> wrote:

> I'm not expecting you to agree but you asked why.  You are free to choose that
> you will not support users running on anything other than the latest OS.
> Just don't force the same decision on me.

Not upgrading (again, barring regressions that are a sad exception) is
a sort of statement about willingness to disconnect from the
mainstream of community (their bugreports are worthless, they won't be
checking out the new Qt apps etc). I don't think it's community's
(here, I mean extras infrastructure) to keep catering for people that
don't want to go where the platform is going.

--
Ville M. Vainio
http://tinyurl.com/vainio
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

On Wednesday 24 February 2010 17:23:19 Ville M. Vainio wrote:
> On Wed, Feb 24, 2010 at 7:04 PM, Graham Cobb <g+770@cobb.uk.net> wrote:
> > I'm not expecting you to agree but you asked why.  You are free to choose
> > that you will not support users running on anything other than the latest
> > OS. Just don't force the same decision on me.
>
> Not upgrading (again, barring regressions that are a sad exception) is
> a sort of statement about willingness to disconnect from the
> mainstream of community (their bugreports are worthless, they won't be
> checking out the new Qt apps etc). I don't think it's community's
> (here, I mean extras infrastructure) to keep catering for people that
> don't want to go where the platform is going.

That is completely different. Maemo Extras is not about community members.
It is about the hundreds of thousands of ordinary users of the device who
don't even know there is a Maemo community -- they just want to enjoy the
apps they can download to their phone.

I don't make my apps available for community members -- most community members
could do that for themselves -- I make them available for the people who are
NOT community members but are just users of the device! These are people who
have never (ever) logged into a forum (yes, I realise that people on this
list under 20 years old won't believe such people actually exist, but they
do!).

They are the ones who won't see any point in upgrading. And the ones I have
in mind when talking about how Extras should work.

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

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".

> Maintaining software and working around bugs for every minor release is
> a nightmare. Only for different major releases and devices it is justified.

You are welcome to your view. Mine is different. And the infrastructure
should not prevent me from supporting users who choose not to upgrade, if I
wish.

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

Graham Cobb wrote:
> My personal view is that there will be a lot of
> people running earlier software for quite a long time. How long do Nokia
> believe it will be before 80% of new devices being sold in retail stores have
> PR1.2 pre-installed?

FYI

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.

I've filed a bug but if this is normal behaviour then I guess a *lot* of devices
will never be upgraded.

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

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