Mailing List Archive

On Mon, Dec 13, 2010 at 14:25, Ville M. Vainio <vivainio@gmail.com> wrote:
>
> Immediately, I'm thinking of two things everyone that expects a
> non-broken QML experience should have:
>
> - libqt4-bearer-hotfix
> - http://gitorious.org/qtquickcompat

Can't these two packages be depended on directly by QML using
applications? With appropriate pages in the Developer Guide etc?

Cheers,

Andrew

--
Andrew Flegg -- mailto:andrew@bleb.org  |  http://www.bleb.org/
Maemo Community Council member
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Mon, Dec 13, 2010 at 4:36 PM, Andrew Flegg <andrew@bleb.org> wrote:

>> - libqt4-bearer-hotfix
>> - http://gitorious.org/qtquickcompat
>
> Can't these two packages be depended on directly by QML using
> applications? With appropriate pages in the Developer Guide etc?

Yes, they can (and currently do). They can also be depended on by
mad-developer, so the devs don't stumble on the issues when getting
started.

However, it would seem much more scalable to have a single metapackage
that has everything that's known to be good for you, instead of
developers discovering piecemeal what is required for their package to
work properly (and listing them all) These packages would not be
features, but just fixes that should really be in a firmware upgrade.

Developer Guides are not widely read, so I'd rather go the "defaults
beat specs" route and slap the service pack wherever I can. Think of
it as a gentle nudge towards a more community-managed default
experience.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

I don't know what the libqt4-bearer-hotfix entails but just saw this thread
few minutes ago on qt devnet:

http://developer.qt.nokia.com/forums/viewthread/2214/P15/

My last comment was exactly about who is/will be in charge of distributing
the qt packages (the community or nokia)?

It would be great if we could, at least, manage the "experimental" packages
(or have nokia update them very often) so developers could always count on
having the last fixes. Most applications would rely on the "official"
packages but any application that is not critical or that depends on a "fix"
after the last release could depend on the experimental packages.

Do we have any restrictions on promoting packages that depend on "qt
experimental"?

Felipe

-----Original Message-----
From: maemo-community-bounces@maemo.org
[mailto:maemo-community-bounces@maemo.org] On Behalf Of Ville M. Vainio
Sent: Monday, December 13, 2010 9:25 AM
To: List for community development
Subject: "Community service pack"

As it appears, there is a wish to deploy various packages to fix known
problems in N900 PR1.3.

Immediately, I'm thinking of two things everyone that expects a
non-broken QML experience should have:

- libqt4-bearer-hotfix
- http://gitorious.org/qtquickcompat

(BTW, explore libqt4-bearer-hotfix package to see how you can use
dpkg-divert to patch things without removing the official PR
metapackages).

Optimally, there would be a PR1.4 providing these, but we are probably
not expecting one in the immediate future ;-).

It would make sense to have a single metapackage
(community-service-pack, or something to that effect) that we would
expect everyone to have installed. Applications that need it could
have it as a dependency, instead of enumerating every
unbreak-my-platform patch ever developed.

This is different from Community SSU in the sense that

1) It would not remove the PR metapackages
2) It would probably be more conservative/boring, shipping little
fixes that can comfortably be done by adding packages, instead of
upgrading the "locked down" ones.
3) It can be easily deployed on people's phones by just having it as a
dependency for your package, instead of making them switch the whole
hog to community ssu.

I would see this metapackage as something that should be moderated by
elected maemo community council.

When the full blown Community SSU gains more foothold, maybe this
won't be needed anymore, but in the mean time a good interim solution
is needed.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

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

On Mon, Dec 13, 2010 at 5:05 PM, Felipe Crochik <felipe@crochik.com> wrote:

> I don't know what the libqt4-bearer-hotfix entails but just saw this thread

The hotfix fixes the problem where qml apps can't load Image's that
have remote url as a source.


> My last comment was exactly about who is/will be in charge of distributing
> the qt packages (the community or nokia)?

Nokia is & probably will be for the official Qt packages (4.7.0). Qt
is such a critical thing for the whole developer experience that I'm
not sure it's a good idea to deviate on that too much.

> It would be great if we could, at least, manage the "experimental" packages
> (or have nokia update them very often) so developers could always count on
> having the last fixes. Most applications would rely on the "official"

If we have those "experimental" packages with small fixes, and some
apps end up using them, we run the risk of massive memory bloat (which
manifests as those annoying swappy moments on the device) when two
versions of Qt are loaded up at the same time, for possibly no good
reason. So applications shouldn't use the experimental packages unless
they absolutely need them (i. I'd be more interested in the
experimental packages when Qt 4.8 comes out), and never consider them
"better" than the official version.

That being said, it's easy to have those experimental packages in
extras, co-existing with system Qt packages.

> packages but any application that is not critical or that depends on a "fix"
> after the last release could depend on the experimental packages.
>
> Do we have any restrictions on promoting packages that depend on "qt
> experimental"?

There is no reason to block apps using them from getting promoted. It
was done w/ the old qt4-maemo5 because nokia was going to release Qt
4.6 in pr 1.2 anyway.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Mon, Dec 13, 2010 at 6:36 PM, Ville M. Vainio <vivainio@gmail.com> wrote:

> > Do we have any restrictions on promoting packages that depend on "qt
> > experimental"?
>
> There is no reason to block apps using them from getting promoted. It
> was done w/ the old qt4-maemo5 because nokia was going to release Qt
> 4.6 in pr 1.2 anyway.
>

Waitaminute. There is a lot of history with the -experimental packages. One
of the reasons for naming them so was to make it very clear that these are
not stable libs and stuff using them should also not be treated as stable.
It's seen as the equivalent of 'sid', head, etc. Another thing is that
because of the way the promotion process works, applications promoted to
testing would always bring (parts of) these experimental builds of 4.7
(later 4.8) with them, corrupting the whole testing process and atomicity of
Qt libs. Long story short: keep -experimental in extras-devel and do
controlled releases of specific stable updates if necessary (I would say
memory bloat is still the lesser of two evils compared to a broken Extras).


Best regards,
Attila

My main concern is that qt (and especially mobility) is evolving on much
faster pace then we should expect to see "PR"s.

Between PR1.2 and 1.3 I had my own "mobility" backend within my application
just because the code had been vastly improved and lots of bugs fixed. I
imagine that if each developer takes the same route the problem will be much
worst.

I am less concerned with the proper "extras". I guess as long as we can have
the bleeding edge version of qt as "experimental" and we can have qt
applications that depend on them make all the way to "extras-testing" we
would have enough.

Most users would stick to "tested" applications that will depend on the
"official" qt. Power users and developers will be able to move on with the
development and testing and have everything ready for when "the next pr
comes".

I would like to get to a point that the version on extras-devel of
qt-experimental release every week or couple of weeks. Maemo is probably the
best mobile platform for qt development right now.

Felipe

-----Original Message-----
From: maemo-community-bounces@maemo.org
[mailto:maemo-community-bounces@maemo.org] On Behalf Of Ville M. Vainio
Sent: Monday, December 13, 2010 11:36 AM
To: List for community development
Subject: Re: "Community service pack"

On Mon, Dec 13, 2010 at 5:05 PM, Felipe Crochik <felipe@crochik.com> wrote:

> I don't know what the libqt4-bearer-hotfix entails but just saw this
thread

The hotfix fixes the problem where qml apps can't load Image's that
have remote url as a source.


> My last comment was exactly about who is/will be in charge of distributing
> the qt packages (the community or nokia)?

Nokia is & probably will be for the official Qt packages (4.7.0). Qt
is such a critical thing for the whole developer experience that I'm
not sure it's a good idea to deviate on that too much.

> It would be great if we could, at least, manage the "experimental"
packages
> (or have nokia update them very often) so developers could always count on
> having the last fixes. Most applications would rely on the "official"

If we have those "experimental" packages with small fixes, and some
apps end up using them, we run the risk of massive memory bloat (which
manifests as those annoying swappy moments on the device) when two
versions of Qt are loaded up at the same time, for possibly no good
reason. So applications shouldn't use the experimental packages unless
they absolutely need them (i. I'd be more interested in the
experimental packages when Qt 4.8 comes out), and never consider them
"better" than the official version.

That being said, it's easy to have those experimental packages in
extras, co-existing with system Qt packages.

> packages but any application that is not critical or that depends on a
"fix"
> after the last release could depend on the experimental packages.
>
> Do we have any restrictions on promoting packages that depend on "qt
> experimental"?

There is no reason to block apps using them from getting promoted. It
was done w/ the old qt4-maemo5 because nokia was going to release Qt
4.6 in pr 1.2 anyway.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

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

On Mon, Dec 13, 2010 at 6:09 PM, Attila Csipa <maemo@csipa.in.rs> wrote:

> Qt libs. Long story short: keep -experimental in extras-devel and do
> controlled releases of specific stable updates if necessary (I would say
> memory bloat is still the lesser of two evils compared to a broken Extras).

Extras would only be broken for the apps that use the -experimental
libs, if there is a fumbled release. So, it's a "life they have
chosen". I'd expect the releases in -experimental to be rather
mechanical merges instead of proper quality assured releases. With
patch releases, it might work ok - however: the old qt-maemo5, while
experimental, was developed and tracked by full time employees; I
don't think 4.7.x has that luxury on maemo side. Chances are, we don't
get lucky and it will suck.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Mon, Dec 13, 2010 at 6:41 PM, Felipe Crochik <felipe@crochik.com> wrote:

> My main concern is that qt (and especially mobility) is evolving on much
> faster pace then we should expect to see "PR"s.

There has already been some internal discussions about pushing Qt
mobility 1.1 (and perhaps even 1.2?) experimental libs through extras.
New releases of mobility are *much* more interesting than Qt 4.7.1
experimental (an experimental stabilization release is a recipe for
confusion and failure).

> "official" qt. Power users and developers will be able to move on with the
> development and testing and have everything ready for when "the next pr
> comes".

"The next pr" is probably not something to optimize our plans around ;-).

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Mon, Dec 13, 2010 at 9:04 PM, Ville M. Vainio <vivainio@gmail.com> wrote:

> Extras would only be broken for the apps that use the -experimental
> libs, if there is a fumbled release. So, it's a "life they have
>

What I was trying to say is that there is a good chance every release will
be fumbled with the current process :) as it is really not meant for heavily
interdependent multipackage projects (as seen from some Python binding
growing pains).


> chosen". I'd expect the releases in -experimental to be rather
> mechanical merges instead of proper quality assured releases. With
>

Yeah, but that still leaves the question of extras-testing open. Changing
underlying versions of Qt in the middle of testing can break things (we
really don't want t-downs on unsuspecting apps because a certain Qt build is
broken), and chances are that there is sufficient overlap that there is not
a moment when no package in testing is affected.

Niels, any comments on the whole thing ? As I understand it, this is quite
different form what/how it is happening now, but have no insight how
easy/difficult it would be to implement.

> "The next pr" is probably not something to optimize our plans around ;-).

One more reason why is so important to keep the qt/mobility updates more
"flexible".

I believe the maemo "after life" is close related to how up-to-date
qt/mobility is on the platform. I agree that Qt is (and even less was) the
most important development platform for maemo but if we are to benefit from
future applications it will be.

Having the experimental packages break from time to time is a small price to
pay for being able to develop with the latest and greatest. Any user willing
to TEST the applications under extras-devel/extras-testing should also be OK
with a surprise now and then. It also should benefit the Trolls to have
people playing with the unstable releases and reporting bugs earlier in the
process.

Who is in charge of the qt experimental? What is the current "schedule" for
it? How much the council and community in general can be involved?

Last but not least: Anything I can do to help?


--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

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

On Mon, Dec 13, 2010 at 9:54 PM, Felipe Crochik <felipe@crochik.com> wrote:

> Having the experimental packages break from time to time is a small price
> to
> pay for being able to develop with the latest and greatest. Any user
> willing
> to TEST the applications under extras-devel/extras-testing should also be
> OK
> with a surprise now and then. It also should benefit the Trolls to have
>

I agree for extras-devel completely, but testing is a bit of a mystery to me
in this context. You push to testing, people test, get it tested and... then
what ? Extras should by definition not contain/force on people untested
stuff with known breakage potential. That is not mean that we cannot change
definitions, just saying that we have to be clear about that :)


> Who is in charge of the qt experimental? What is the current "schedule" for
> it? How much the council and community in general can be involved?
> Last but not least: Anything I can do to help?
>
>
Try talking to harryF on #qt-maemo, he was looking for a maintainer.
Currently there is a slight vacuum - unlike the previous jump with QML, 4.7
updates are not significantly different from the one in the PR to warrant
anyone from linking to it, and the the to-be-4.8 has no high-profile new
features available for devs yet. As for what happens in extras(-devel) with
the new versions, it's certainly a community coordinated effort and AIUI the
Council has a large (pretty much final) word on that. As you yourself said
it, it's in everybody's interest to have the latest & greatest Qt stuff
available not just as gitoriousware, but in an easily testable dev-friendly
binary form, too.

On Mon, Dec 13, 2010 at 8:54 PM, Felipe Crochik <felipe@crochik.com> wrote:

> I believe the maemo "after life" is close related to how up-to-date
> qt/mobility is on the platform. I agree that Qt is (and even less was) the
> most important development platform for maemo but if we are to benefit from
> future applications it will be.

Right. Critical stepping stone next year is getting Qt Quick
Components working well on maemo5, after that maemo5 supports most
projects that are expected to work both on MeeGo and Symbian (and a
good deal of projects targeting MeeGo-only).

> Last but not least: Anything I can do to help?

Qt Mobility 1.1 extras-devel effort could be a good place to start,
with more bang for the buck than qt 4.7.1.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

Hi Ville and List,

2010/12/13 Ville M. Vainio <vivainio@gmail.com>:
> On Mon, Dec 13, 2010 at 6:41 PM, Felipe Crochik <felipe@crochik.com> wrote:
>> "official" qt. Power users and developers will be able to move on with the
>> development and testing and have everything ready for when "the next pr
>> comes".
>
> "The next pr" is probably not something to optimize our plans around ;-).

Wasn't one of the advantages of the SSU to be able to update single
packages from official repositories if need be? Would it be possible
to provide updated (and fixed) packages of Qt 4.7 and Qt Mobility
through the official channels as a single-package SSU, as opposed to
doing a PR1.4 (which probably requires building of new images as
well)? This way, users and developers just need to update through the
application manager once they have installed PR1.3 (either
re-flashed).

It's sad that even in the Brave New Qt World, we "invent" even more
workarounds (dpkg-divert for the win?) and pseudo-meta-packages and
dependencies on them and what not. If Nokia is really not interested
in releasing any updates for Maemo 5, we should better focus on
empowering the Fremantle Community SSU and releasing fixed Qt packages
through that channel, and make sure that everyone uses the Community
SSU. This would be more sane, cleaner and less confusing than the
current "oh, we don't tell you we don't support Maemo 5 anymore, and
you don't even get any updates to the buggy Qt that shipped with PR1.3
- come on, let's create some hack-ish workarounds".

As Qt and Qt Mobility should ideally be the only developer-visible
APIs in the long term, having up-to-date Qt libraries provided by the
vendor can go a long way in preventing "fragmentation". The situation
is the same for Symbian^3 at the moment - there's only Qt 4.6, and no
official way for end users to get 4.7. There are developer packages,
but they should not be deployed on end users' devices. So no QML apps
for Symbian^3 users until Nokia cares to bring out an update. Great!
(not..)

Please, no more dirty workarounds and hacks. Just push Qt + Qt
Mobility updates through the official SSU channel (or even just the
bearer fix - which is really a bug!). If that's not an option, that's
a signal that there is no more official support from Nokia for Maemo
5, in which case the Community SSU should be pushed forward and
promoted.


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

Beautifully put, Thomas. ;)

Randy

> ----- Original message -----
> From: "Thomas Perl‎" <th.perl@gmail.com>
> To: "List for community development‎" <maemo-community@maemo.org>
> Subject: Re: "Community service pack"
> Date: Tue, 14 Dec 2010 15:47:55 +0100
>
>
>Hi Ville and List,
>
> 2010/12/13 Ville M. Vainio <vivainio@gmail.com>:
> > On Mon, Dec 13, 2010 at 6:41 PM, Felipe Crochik <felipe@crochik.com> wrote:
> >> "official" qt. Power users and developers will be able to move on with the
> >> development and testing and have everything ready for when "the next pr
> >> comes".
> >
> > "The next pr" is probably not something to optimize our plans around ;-).
>
> Wasn't one of the advantages of the SSU to be able to update single
> packages from official repositories if need be? Would it be possible
> to provide updated (and fixed) packages of Qt 4.7 and Qt Mobility
> through the official channels as a single-package SSU, as opposed to
> doing a PR1.4 (which probably requires building of new images as
> well)? This way, users and developers just need to update through the
> application manager once they have installed PR1.3 (either
> re-flashed).
>
> It's sad that even in the Brave New Qt World, we "invent" even more
> workarounds (dpkg-divert for the win?) and pseudo-meta-packages and
> dependencies on them and what not. If Nokia is really not interested
> in releasing any updates for Maemo 5, we should better focus on
> empowering the Fremantle Community SSU and releasing fixed Qt packages
> through that channel, and make sure that everyone uses the Community
> SSU. This would be more sane, cleaner and less confusing than the
> current "oh, we don't tell you we don't support Maemo 5 anymore, and
> you don't even get any updates to the buggy Qt that shipped with PR1.3
> - come on, let's create some hack-ish workarounds".
>
> As Qt and Qt Mobility should ideally be the only developer-visible
> APIs in the long term, having up-to-date Qt libraries provided by the
> vendor can go a long way in preventing "fragmentation". The situation
> is the same for Symbian^3 at the moment - there's only Qt 4.6, and no
> official way for end users to get 4.7. There are developer packages,
> but they should not be deployed on end users' devices. So no QML apps
> for Symbian^3 users until Nokia cares to bring out an update. Great!
> (not..)
>
> Please, no more dirty workarounds and hacks. Just push Qt + Qt
> Mobility updates through the official SSU channel (or even just the
> bearer fix - which is really a bug!). If that's not an option, that's
> a signal that there is no more official support from Nokia for Maemo
> 5, in which case the Community SSU should be pushed forward and
> promoted.
>
>
> Thomas
> _______________________________________________
> maemo-community mailing list
> maemo-community@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-community
>

--------------------------------------------------------------
Ovi Mail: Making email access easy
http://mail.ovi.com

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

On Tue, Dec 14, 2010 at 3:47 PM, Thomas Perl <th.perl@gmail.com> wrote:
>
> Wasn't one of the advantages of the SSU to be able to update single
> packages from official repositories if need be? Would it be possible
> to provide updated (and fixed) packages of Qt 4.7 and Qt Mobility
> through the official channels as a single-package SSU, as opposed to
> doing a PR1.4 (which probably requires building of new images as
> well)? This way, users and developers just need to update through the
> application manager once they have installed PR1.3 (either
> re-flashed).
>

qtm can be updated separately. The thing we have to remember is that
Ovi also uses the same repository, so things need to be coordinated.

I've asked the SDK team what the plans are wrt updating qtm.

Let's wait for a response, before we start coming up with all kinds of
hacks on our side. It is also in Nokia's interest to keep Qt and qtm
in line with MeeGo.

[snip]

> Please, no more dirty workarounds and hacks. Just push Qt + Qt
> Mobility updates through the official SSU channel (or even just the
> bearer fix - which is really a bug!). If that's not an option, that's
> a signal that there is no more official support from Nokia for Maemo
> 5, in which case the Community SSU should be pushed forward and
> promoted.

I second this. Let's first see if there are official plans, if there
aren't then we can go and try to fix things ourselves.

>
> Thomas


--
Niels Breet
maemo.org webmaster
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On 14 December 2010 16:51, Niels Breet <niels@maemo.org> wrote:

> > Please, no more dirty workarounds and hacks. Just push Qt + Qt
> > Mobility updates through the official SSU channel (or even just the
> > bearer fix - which is really a bug!). If that's not an option, that's
> > a signal that there is no more official support from Nokia for Maemo
> > 5, in which case the Community SSU should be pushed forward and
> > promoted.
>
> I second this. Let's first see if there are official plans, if there
> aren't then we can go and try to fix things ourselves.

FYI, there is currently an open-source version of the media player in
the works, with first milestone targetted around mid-to-end January
2011. This would probably be packaged in a way to fully replace the
current Media Player.

-S.

--
question = ( to ) ? be : ! be;
      -- Wm. Shakespeare
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Tue, Dec 14, 2010 at 4:47 PM, Thomas Perl <th.perl@gmail.com> wrote:

> Wasn't one of the advantages of the SSU to be able to update single
> packages from official repositories if need be? Would it be possible
> to provide updated (and fixed) packages of Qt 4.7 and Qt Mobility
> through the official channels as a single-package SSU, as opposed to
> doing a PR1.4 (which probably requires building of new images as
> well)? This way, users and developers just need to update through the

QtM yes, Qt no (because Qt is part of the core set of applications).

The only way to update Qt currently would be to make yet another
"hotfix" hack that does dpkg-divert for all the libs. Or, install a
new Qt alongside the system Qt (as done by various -experimental
packages).

> dependencies on them and what not. If Nokia is really not interested
> in releasing any updates for Maemo 5, we should better focus on
> empowering the Fremantle Community SSU and releasing fixed Qt packages
> through that channel, and make sure that everyone uses the Community
> SSU. This would be more sane, cleaner and less confusing than the

Problem with community SSU is, does it have enough resources for
testing and development? We still got tons of "normal" N900 users
(those probably are not reading maemo-community) that are not
interested in switching to a community ssu - and risk breaking
elementary stuff. IIUC it's still a pretty small effort, without so
much as a mailing list.

A "service pack" would be a safe thing for developers to depend on, as
it would keep the device mostly on the beaten path. Not much
development work would go into it, just bare essentials needed for
tolerable operation.

Such a service pack can only get us so far, so a full blown community
SSU is needed eventually - going forward, I would be surprised if we
didn't have most of the meego stack & applications working on maemo5
(but still have hildon-home etc).

> Please, no more dirty workarounds and hacks. Just push Qt + Qt

Dirty workarounds and hacks are what can be done right now.

> bearer fix - which is really a bug!). If that's not an option, that's
> a signal that there is no more official support from Nokia for Maemo
> 5, in which case the Community SSU should be pushed forward and
> promoted.

Community SSU should be pushed forward and promoted in any case,
regardless of any interpretation of hypothetical signals Nokia may be
giving out some day or not. Waiting for Nokia to communicate something
about PR1.4 officially won't help get anything done.

--
Ville M. Vainio @@ Forum Nokia
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Wed, Dec 15, 2010 at 19:11, Ville M. Vainio <vivainio@gmail.com> wrote:
>
> A "service pack" would be a safe thing for developers to depend on, as
> it would keep the device mostly on the beaten path. Not much
> development work would go into it, just bare essentials needed for
> tolerable operation.

Is there a proposal for who would maintain it; or what kind of
"(volunteer) job spec" the Council needs to advertise to get someone
to step up? Have we already got a volunteer?

Certainly the Council can advertise that developers should rely on it
(and/or get X-Fade to add warnings/blocks to the promotion process for
QML applications if they don't have it as a dependency [how could
these packages be identified?]); but I don't think the Council wants
to be the maintainer of the package itself.

Cheers,

Andrew

--
Andrew Flegg -- mailto:andrew@bleb.org  |  http://www.bleb.org/
Maemo Community Council member
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On 12/15/2010 09:11 PM, Ville M. Vainio wrote:
> On Tue, Dec 14, 2010 at 4:47 PM, Thomas Perl <th.perl@gmail.com>
> wrote:
>
> > Wasn't one of the advantages of the SSU to be able to update
> > single packages from official repositories if need be? Would it be
> > possible to provide updated (and fixed) packages of Qt 4.7 and Qt
> > Mobility through the official channels as a single-package SSU, as
> > opposed to doing a PR1.4 (which probably requires building of new
> > images as well)? This way, users and developers just need to
> > update through the
>
> QtM yes, Qt no (because Qt is part of the core set of applications).
>
> The only way to update Qt currently would be to make yet another
> "hotfix" hack that does dpkg-divert for all the libs. Or, install a
> new Qt alongside the system Qt (as done by various -experimental
> packages).
>

The SSU is able to upgrade system packages, that's the whole point of it,
and QtM can indeed be upgraded through extras(-devel).

> > dependencies on them and what not. If Nokia is really not
> > interested in releasing any updates for Maemo 5, we should better
> > focus on empowering the Fremantle Community SSU and releasing fixed
> > Qt packages through that channel, and make sure that everyone uses
> > the Community SSU. This would be more sane, cleaner and less
> > confusing than the
>
> Problem with community SSU is, does it have enough resources for
> testing and development? We still got tons of "normal" N900 users
> (those probably are not reading maemo-community) that are not
> interested in switching to a community ssu - and risk breaking
> elementary stuff. IIUC it's still a pretty small effort, without so
> much as a mailing list.
>
> A "service pack" would be a safe thing for developers to depend on,
> as it would keep the device mostly on the beaten path. Not much
> development work would go into it, just bare essentials needed for
> tolerable operation.
>
> Such a service pack can only get us so far, so a full blown
> community SSU is needed eventually - going forward, I would be
> surprised if we didn't have most of the meego stack & applications
> working on maemo5 (but still have hildon-home etc).
>
> > Please, no more dirty workarounds and hacks. Just push Qt + Qt
>
> Dirty workarounds and hacks are what can be done right now.

Not really, a working SSU is what should be done right now.
If any dirty workarounds have to be done, I would've removed Nokia's
repositories from the trusted list in HAM's configuration file and announced
the SSU long ago.
Sadly, no one's offering to help with it, might as well start reading all of
HAM's source to see what goes where and why.

Regards,
Mohammad Abu-Garbeyyeh

On Wed, Dec 15, 2010 at 19:30, Mohammad Abu-Garbeyyeh
<mohammad7410@gmail.com> wrote:
>
> If any dirty workarounds have to be done, I would've removed Nokia's
> repositories from the trusted list in HAM's configuration file and
> announced the SSU long ago.

Well, that's still an approach open to us if it's all or nothing.

> Sadly, no one's offering to help with it, might as well start reading
> all of HAM's source to see what goes where and why.

Could you bring the list (or, perhaps, maemo-developers) up to speed on:

a) Where you're at.
b) What the problems are.
c) What approaches you've tried/discounted.

I'm sure we can crack it by shining some more light on it.

Thanks in advance,

Andrew

--
Andrew Flegg -- mailto:andrew@bleb.org  |  http://www.bleb.org/
Maemo Community Council member
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Wed, Dec 15, 2010 at 9:34 PM, Andrew Flegg <andrew@bleb.org> wrote:

> On Wed, Dec 15, 2010 at 19:30, Mohammad Abu-Garbeyyeh
> <mohammad7410@gmail.com> wrote:
> >
> > If any dirty workarounds have to be done, I would've removed Nokia's
> > repositories from the trusted list in HAM's configuration file and
> > announced the SSU long ago.
>
> Well, that's still an approach open to us if it's all or nothing.
>
> > Sadly, no one's offering to help with it, might as well start reading
> > all of HAM's source to see what goes where and why.
>
> Could you bring the list (or, perhaps, maemo-developers) up to speed on:
>
> a) Where you're at.
> b) What the problems are.
> c) What approaches you've tried/discounted.
>

I'm sure I sent an email about that last month ;)
Anyway, the SSU is all set up and can in fact be used on devices, however,
it will only work with apt, and HAM will ignore packages from the repo.
Niels also set up a builder, so we can distribute packages with their
sources.

The postinst file currently adds the GPG key with apt-key, so that's apt-get
working fine with packages being authorised and all.

It also adds the fingerprint of the key to HAM's config file, and with the
latest
package, it also adds <certified/> to the config, as is done with the
official
SSU repos, the trust level is also set to 650, higher than all other repos,
yet HAM still ignores the packages.

Another problem at hand is that we're replacing Nokia's meta packages with
our own ones (locales aren't depended on, so one package should work on
all firmwares (002, 003 etc...)), however, to do this, apt and HAM should
not
be running, and a terminal window has to be launched from the postinst
(which, for some reason, works when installing with dpkg, but not with apt).

The last problem isn't something to worry about, I guess we can make a quick
GUI to enable and/or disable the community SSU, which the user clicks after
installation, it's a one-time process for the user.

So the only major problem right now is HAM ignoring packages from the
repository,
or the "wrong domain" as logs show.

Regards,
Mohammad Abu-Garbeyyeh

On Wednesday 15 December 2010 21:20:11 you wrote:
> Is there a proposal for who would maintain it; or what kind of
> "(volunteer) job spec" the Council needs to advertise to get someone
> to step up? Have we already got a volunteer?

o/ (not as Council member, just as a Maemo guy with some backing from FN :)

> Certainly the Council can advertise that developers should rely on it
> (and/or get X-Fade to add warnings/blocks to the promotion process for
> QML applications if they don't have it as a dependency [how could
> these packages be identified?]); but I don't think the Council wants
> to be the maintainer of the package itself.

I guess a dependency on libqt4-declarative or qt4-qmlviewer is a giveaway :)

PS. Are we OK with the name ? We can use csp or community-sp or whatever for
testing, but once it goes public, it will be very difficult to change due to HAM
behavior.

Best regards,
Attila Csipa
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Thu, Dec 16, 2010 at 11:48, Attila Csipa <maemo@csipa.in.rs> wrote:
> On Wednesday 15 December 2010 21:20:11 you wrote:
>> Is there a proposal for who would maintain it; or what kind of
>> "(volunteer) job spec" the Council needs to advertise to get someone
>> to step up? Have we already got a volunteer?
>
> o/ (not as Council member, just as a Maemo guy with some backing from FN :)

Excellent, ta :-)

> I guess a dependency on libqt4-declarative or qt4-qmlviewer is a giveaway :)

Yup. A block for packages without the appropriate fixpack seems appropriate.

> PS. Are we OK with the name ? We can use csp or community-sp or whatever for
> testing, but once it goes public, it will be very difficult to change due to HAM
> behavior.

Let's focus this on the Qt side; I see two options:

1) A meta-package, as Ville describes, which depends on the two packages.
This might live in 'user/' (TBD) and be called something like
"qt-community-fixes-1". I don't think this should be a general
"community hotfixes", because then it makes no sense for QML apps
to depend on it in general. However, the SSU could depend on it to
pull it in more widely.

2) A change to Packages which just checks for the appropriate hotfix
packages; i.e. instead of depending on one metapackage, instead
QML projects have to depend on both fix packages.

Given the problems with HAM & meta-packages in the past, I'd like to
know we were confident in the behaviour if we took option #1.

Cheers,

A.

--
Andrew Flegg -- mailto:andrew@bleb.org  |  http://www.bleb.org/
Maemo Community Council member
_______________________________________________
maemo-community mailing list
maemo-community@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-community

On Thu, Dec 16, 2010 at 2:47 PM, Andrew Flegg <andrew@bleb.org> wrote:

> 1) A meta-package, as Ville describes, which depends on the two packages.
> This might live in 'user/' (TBD) and be called something like
> "qt-community-fixes-1". I don't think this should be a general
> "community hotfixes", because then it makes no sense for QML apps
> to depend on it in general. However, the SSU could depend on it to
> pull it in more widely.
>
> 2) A change to Packages which just checks for the appropriate hotfix
> packages; i.e. instead of depending on one metapackage, instead
> QML projects have to depend on both fix packages.
>
> Given the problems with HAM & meta-packages in the past, I'd like to
> know we were confident in the behaviour if we took option #1.
>
>
IMO #2 is a no-go actually (which makes #1 the only way :), as if we allow
per-hotfix dependencies, we will have a mix of hotfixes that HAM will never
allow to nicely upgrade (if you have fix A as part of the hotfix
metapackage, and then with the next iteration a B hotfix comes, HAM will
actually refuse to install an app requiring hotfix B because that would
require updating A, but that was part of another app -> you get a 'problems'
tab). Some PyQt users might find this scenario familiar, so I suggest we
actually encourage to serve the fixes in bundles - that would also make
testing easier, etc).