[pkg-fso-maint] New 2.6.29 kernel uploaded

[Gaudenz Steinlin]

Hi 

Excerpts from Timo Juhani Lindfors's message of Mon Aug 09 14:56:25 +0200 2010:
> Gaudenz Steinlin <gaudenz at debian.org> writes:
> > I think that all further kernel packaging should be done on a separate
> > branch starting from the branch amied at the official package.
> 
> I think andy-tracking should be seen as a "stable, well tested"
> branch. I am sure it is a good idea to do small incremental bug fixes
> to this branch.

If someone wants to maintain the current kernel package in the pkg-fso
repository I won't oppose per se. Fact is, that this package was
unmaintained for more than a year. I myself have no interest in doing
any kind of work on a package that is not based on the official Debian
kernel package.

> 
> I have tested 2.6.32 and reported bugs [1]. My impression is that
> while it may run d-i it is still behind andy-tracking in terms of
> stability and features. Many of the features are already in SHR but
> are not accepted by git.openmoko.org. Should we start cherry-picking
> these patches from SHR? As I understood it, we won't get things like
> USB host support without these patches.

Instead of creating one more branch the aim should be to send as much
as possible upstream for inclusion into mainline. That way these
patches will also be acceptable for the Debian kernel package.

> 
> Put it another way: I am eager to test and report bugs for a branch
> that aims to provide same features as andy-tracking
> currently. However, if the goal is to run d-i and nothing more then I
> don't have very high motivation for testing.

The short term goal is to get a -s3c24xx flavour into Debian main that
supports at least installation. This is a requirement to get support
for the Freerunner integrated into the official d-i.

> 
> So, is the primary goal to get a kernel finally to Debian or to have a
> 2.6.32 kernel for openmoko that supports mostly the same features as
> andy-tracking did? I can understand both goals very well but they
> should be spelt out clearly.

Of course the goal is to get as many features as possible into the
Debian kernel. The best way to help with this is to find out which
parts are not yet upstream and to see what's needed to send them
upstream.

For those parts that can't be upstreamed (AFAIK only wlan is in this
category), a separate module-xxx package should be provided. As a
short term solution a branch of the official kernel package with
additional patches not yet included upstream is also possible.

Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~