2.6.25-2 testing sync

[maximilian attems-9]

hello

now that d-i released last beta that 2.6.25 state in unstable
is fine, we'd want that backup option for the upcoming release
in testing.

please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
linux-modules-extra-2.6 2.6.25-5

thanks

--
maks


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daniel Baumann-4]

maximilian attems wrote:
> please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
> linux-modules-extra-2.6 2.6.25-5

linux-modules-nonfree-2.6 can go too.

--
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann@...
Internet:       http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Otavio Salvador]

maximilian attems <max@...> writes:

> hello
>
> now that d-i released last beta that 2.6.25 state in unstable
> is fine, we'd want that backup option for the upcoming release
> in testing.
>
> please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
> linux-modules-extra-2.6 2.6.25-5

Please wait few more days until we get it properly done on sid (d-i
migrates to it).

--
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@...      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[maximilian attems-9]

On Thu, Jul 03, 2008 at 02:20:58PM -0300, Otavio Salvador wrote:

> maximilian attems <max@...> writes:
>
> > hello
> >
> > now that d-i released last beta that 2.6.25 state in unstable
> > is fine, we'd want that backup option for the upcoming release
> > in testing.
> >
> > please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
> > linux-modules-extra-2.6 2.6.25-5
>
> Please wait few more days until we get it properly done on sid (d-i
> migrates to it).

2.6.26 is meant to come out soon.
and it is about time to have 2.6.25 in testing.

--
maks


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

(adding d-kernel and d-release)

On Monday 07 July 2008, Otavio Salvador wrote:

> Frans Pop <elendil@...> writes:
> > On Thursday 03 July 2008, Otavio Salvador wrote:
> >> > please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
> >> > linux-modules-extra-2.6 2.6.25-5
> >>
> >> Please wait few more days until we get it properly done on sid (d-i
> >> migrates to it).
> >
> > Why? We have never blocked migration of a new kernel when that wasn't
> > needed because of a D-I release. Uploading udebs and switching to a
> > kernel is not dependant on the migration. A new kernel can basically
> > migrate (from a D-I PoV) as soon as a release is out.
>
> Except that kernel team wants it to upload 2.6.26 to sid when it's
> released (probably this week)

OK, then _that_ should be discussed, not the migration to testing. The two
are completely separate issues.

In fact, having 2.6.25 in testing would possibly make it easier for the
kernel team to do a final (?) 2.6.25 upload with latest stable updates.

There are valid arguments to be found for staying with 2.6.25 a bit
longer, but "D-I has not yet converted to it" is NOT one of them.

A much more important argument is that .25 has seen and will almost
certainly continue to get a lot more stabilization effort upstream than
is "normal" for upstream kernel releases because long term releases for
at least two important other distros are based on it. I doubt .26 will
get the same upstream attention.
Given the lack of capacity in Debian to do any real stabilization (cherry
picking/backporting of fixes from later releases) ourselves, that could
IMO be an important consideration for staying with .25 for Lenny.

.26 also includes at least one change I know of that is somewhat risky:
PAT support for x86 (which could be disabled).

Se IMO we should take a real good look at .25 and .26 and check what's
new, what's important for Lenny and what's risky, and maybe check if some
things we do want could be backported.

Delaying the upload of .26 to unstable could give us time, as a
distribution, to stay up to date with .25, see how things are going
with .26 and make a more informed decision.

However, if the kernel team (together with maybe the release team) has
already decided on .26 for Lenny, then it would be better to get it into
unstable ASAP and for D-I to basically skip .25.

> and we have not yet got all architectures tested with 2.6.25 on d-i.

So what? That's largely our own damned fault...

Cheers,
FJP

[maximilian attems-9]

On Mon, Jul 07, 2008 at 05:30:09PM +0200, Frans Pop wrote:

> (adding d-kernel and d-release)
>
> On Monday 07 July 2008, Otavio Salvador wrote:
> > Frans Pop <elendil@...> writes:
> > > On Thursday 03 July 2008, Otavio Salvador wrote:
> > >> > please hint linux-2.6 2.6.25-6, linux-kbuild-2.6 2.6.25-2,
> > >> > linux-modules-extra-2.6 2.6.25-5
> > >>
> > >> Please wait few more days until we get it properly done on sid (d-i
> > >> migrates to it).
> > >
> > > Why? We have never blocked migration of a new kernel when that wasn't
> > > needed because of a D-I release. Uploading udebs and switching to a
> > > kernel is not dependant on the migration. A new kernel can basically
> > > migrate (from a D-I PoV) as soon as a release is out.
> >
> > Except that kernel team wants it to upload 2.6.26 to sid when it's
> > released (probably this week)
>
> OK, then _that_ should be discussed, not the migration to testing. The two
> are completely separate issues.
>
> In fact, having 2.6.25 in testing would possibly make it easier for the
> kernel team to do a final (?) 2.6.25 upload with latest stable updates.
>
> There are valid arguments to be found for staying with 2.6.25 a bit
> longer, but "D-I has not yet converted to it" is NOT one of them.

testing users are currently on an unsupported kernel.
 
> A much more important argument is that .25 has seen and will almost
> certainly continue to get a lot more stabilization effort upstream than
> is "normal" for upstream kernel releases because long term releases for
> at least two important other distros are based on it. I doubt .26 will
> get the same upstream attention.
> Given the lack of capacity in Debian to do any real stabilization (cherry
> picking/backporting of fixes from later releases) ourselves, that could
> IMO be an important consideration for staying with .25 for Lenny.

that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
biest you'll notice the RH men force boot behind their backporting
machine.
 
> .26 also includes at least one change I know of that is somewhat risky:
> PAT support for x86 (which could be disabled).

disabled.

> Se IMO we should take a real good look at .25 and .26 and check what's
> new, what's important for Lenny and what's risky, and maybe check if some
> things we do want could be backported.
>
> Delaying the upload of .26 to unstable could give us time, as a
> distribution, to stay up to date with .25, see how things are going
> with .26 and make a more informed decision.
>
> However, if the kernel team (together with maybe the release team) has
> already decided on .26 for Lenny, then it would be better to get it into
> unstable ASAP and for D-I to basically skip .25.

.26 is the release kernel.
so i'm happy with push on it.
.25 is a possible backup.
 
--
maks


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Frans Pop a écrit :
> Se IMO we should take a real good look at .25 and .26 and check what's
> new, what's important for Lenny and what's risky, and maybe check if some
> things we do want could be backported.

As the release team is Cc:ed, I just want to make sure it is aware that
switching to 2.6.26 possibly means changes to userland, and thus freeze
exceptions. A few examples:

- The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to
removed headers. Change have been needed in various packages including
glibc.
- The switch to linux-libc-dev 2.6.25 is the reason why glibc currently
FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know
yet which change causes the problem, I am down to a 600 lines diff.
- I have recently uploaded a new version of lm-sensors needed to support
2.6.26 kernels.

That said I neither opposed nor in favor of a switch to 2.6.26, I just
want to emphasize that it can have a bigger impact than expected on the
release planning.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pierre Habouzit-2]

On Mon, Jul 07, 2008 at 04:19:01PM +0000, Aurelien Jarno wrote:

> Frans Pop a écrit :
> > Se IMO we should take a real good look at .25 and .26 and check what's
> > new, what's important for Lenny and what's risky, and maybe check if some
> > things we do want could be backported.
>
> As the release team is Cc:ed, I just want to make sure it is aware that
> switching to 2.6.26 possibly means changes to userland, and thus freeze
> exceptions. A few examples:
>
> - The switch to linux-libc-dev 2.6.25 has caused a lot of FTBFS due to
> removed headers. Change have been needed in various packages including
> glibc.
> - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently
> FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know
> yet which change causes the problem, I am down to a 600 lines diff.
> - I have recently uploaded a new version of lm-sensors needed to support
> 2.6.26 kernels.
>
> That said I neither opposed nor in favor of a switch to 2.6.26, I just
> want to emphasize that it can have a bigger impact than expected on the
> release planning.

Changing kernel at this point of the release would be too destructive,
so unless there is a big fat problem in the .25 that the .26 should fix
and is unbackportable (does such a beast even exist ?) I'm rather
opposed to it. Note that the asm/page.h mess is still not fixed thanks
to hppa.

Disclaimer: it's my own opinion, I did not check what other Release Team
member think about this.

--
·O·  Pierre Habouzit
··O                                                madcoder@...
OOO                                                http://www.madism.org

[Andreas Barth]

* Pierre Habouzit (madcoder@...) [080707 19:48]:
> Changing kernel at this point of the release would be too destructive,
> so unless there is a big fat problem in the .25 that the .26 should fix
> and is unbackportable (does such a beast even exist ?) I'm rather
> opposed to it. Note that the asm/page.h mess is still not fixed thanks
> to hppa.
>
> Disclaimer: it's my own opinion, I did not check what other Release Team
> member think about this.

I agree with you, at least with my current informations.


Cheers,
Andi
--
  http://home.arcor.de/andreas-barth/


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Martin Michlmayr]

* Frans Pop <elendil@...> [2008-07-07 17:30]:
> In fact, having 2.6.25 in testing would possibly make it easier for
> the kernel team to do a final (?) 2.6.25 upload with latest stable
> updates.

FWIW, I fully agree.  In the past, we never waited for all arches in
d-i to move to a new kernel udebs before allowing the deb of that
version to move to testing.  In fact, not having 2.6.25 in testing now
that some arches have updated d-i to 2.6.25 _hurts_ our testing
efforts.  Some Orion devices work perfectly fine in d-i now that we've
moved to 2.6.25, but installations fail because no kernel is in
testing... which means people cannot test it.

So, please migrate the 2.6.25 debs to testing.
--
Martin Michlmayr
http://www.cyrius.com/


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Otavio Salvador]

maximilian attems <max@...> writes:

> .26 is the release kernel.
> so i'm happy with push on it.
> .25 is a possible backup.

I'd like to get an official statement from RM team about that so we
can move it further.

--
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@...      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Otavio Salvador]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Michlmayr <tbm@...> writes:

> * Frans Pop <elendil@...> [2008-07-07 17:30]:
>> In fact, having 2.6.25 in testing would possibly make it easier for
>> the kernel team to do a final (?) 2.6.25 upload with latest stable
>> updates.
>
> FWIW, I fully agree.  In the past, we never waited for all arches in
> d-i to move to a new kernel udebs before allowing the deb of that
> version to move to testing.  In fact, not having 2.6.25 in testing now
> that some arches have updated d-i to 2.6.25 _hurts_ our testing
> efforts.  Some Orion devices work perfectly fine in d-i now that we've
> moved to 2.6.25, but installations fail because no kernel is in
> testing... which means people cannot test it.
>
> So, please migrate the 2.6.25 debs to testing.

No objection in allowing 2.6.25 to go to testing but please hold on
about uploading 2.6.26 until RM team acks on it.

- --
        O T A V I O    S A L V A D O R
- ---------------------------------------------
 E-mail: otavio@...      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- ---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iEYEARECAAYFAkhyZJAACgkQLqiZQEml+FUgZwCfUX/L+aGf7m4sk0rsAua3M3Eo
4SAAoJFrBJQgdwpJ4y+FHgUPEdAUFkTF
=i8PB
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

On Monday 07 July 2008, maximilian attems wrote:
> > There are valid arguments to be found for staying with 2.6.25 a bit
> > longer, but "D-I has not yet converted to it" is NOT one of them.
>
> testing users are currently on an unsupported kernel.

Eh, how does that follow my last para which I assume you are commenting
on, but which has nothing to do with testing?

A side-note to your comment though...

IMO testing kernel support is the weakest point in the current upload
strategy by the kernel team. By uploading the next upstream release to
unstable basically as soon as it's available upstream, Debian users (both
unstable and testing) are frequently missing out on at least one or two
upstream stable updates for the previous stable ("stable -1") release.

We worked around this for .24 by doing an upstream stable update through
t-p-u.

Upstream does seem to recognize the fact that a new release will need at
least a few updates before it is actually "stable and usable", and will
therefore do at least a few stable updates (for both "new stable"
and "stable -1" in parallel). This basically happens in parallel to the
new merge window (say the time to -rc2) and some upstream releases get
"longer term" upstream stable support (.18, .22, .25).

My personal opinion is that it would be better to delay the upload of new
upstream releases to unstable until the .2 or maybe even .3 upstream
stable update has become available. This would mean a bit more work for
the kernel team, but I would expect that to be solvable.

That would also give more time for initial arch-specific and l-m-e issues
for the new upstream to be worked out (e.g. in experimental) without
breaking unstable too much. IMO a new kernel version should only be
uploaded to unstable if kernel meta packages can be updated at roughly
the same time.

It would also allow to upload a few more stable updates for "stable -1"
and to migrate those to testing, giving testing users on average better
support and it would give D-I some more "breathing space" to do releases.

When a new stable *is* uploaded, D-I should be able to switch faster too
(at least, if there's someone willing to do the initial kernel-wedge
work) as the main criterium for D-I to switch to a new kernel version is:
does the new version look about to be ready to migrate to testing, which
current early uploads of the kernel to unstable effectively never are.

> > A much more important argument is that .25 has seen and will almost
> > certainly continue to get a lot more stabilization effort upstream
> > than is "normal" for upstream kernel releases because long term
> > releases for at least two important other distros are based on it. I
> > doubt .26 will get the same upstream attention.
> > Given the lack of capacity in Debian to do any real stabilization
> > (cherry picking/backporting of fixes from later releases) ourselves,
> > that could IMO be an important consideration for staying with .25 for
> > Lenny.
>
> that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
> biest you'll notice the RH men force boot behind their backporting
> machine.

I'm having serious trouble parsing what you're trying to say here. Could
you rephrase?

Cheers,
FJP

[Luk Claes]

Otavio Salvador wrote:

> Martin Michlmayr <tbm@...> writes:
>
>> * Frans Pop <elendil@...> [2008-07-07 17:30]:
>>> In fact, having 2.6.25 in testing would possibly make it easier for
>>> the kernel team to do a final (?) 2.6.25 upload with latest stable
>>> updates.
>> FWIW, I fully agree.  In the past, we never waited for all arches in
>> d-i to move to a new kernel udebs before allowing the deb of that
>> version to move to testing.  In fact, not having 2.6.25 in testing now
>> that some arches have updated d-i to 2.6.25 _hurts_ our testing
>> efforts.  Some Orion devices work perfectly fine in d-i now that we've
>> moved to 2.6.25, but installations fail because no kernel is in
>> testing... which means people cannot test it.
>
>> So, please migrate the 2.6.25 debs to testing.
>
> No objection in allowing 2.6.25 to go to testing but please hold on
> about uploading 2.6.26 until RM team acks on it.

hint added.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

On Monday 07 July 2008, Frans Pop wrote:
> .26 also includes at least one change I know of that is somewhat risky:
> PAT support for x86 (which could be disabled).

#d-uk just gave me this tidbit:
<...> am I missing something or will the move to .26, with libata binding
before most of the IDE stuff, cause a lot of pain unless the distro
manages the move from hd* to sd*?

Which is basically the "why don't we have persistent device naming" issue
(on which I won't comment).

There's two things to say about this (assuming status quo otherwise):
- this will probably reduce the pain on reboots for new installations
  as module loading order should become more predictable between different
  boots
- this may increase the pain for people upgrading from Etch to Lenny,
  or not, or ...


Other related issue/question.

Early in lenny, when libata first stuck up its head, we made some effort
to disable drivers or remove duplicate PCI IDs so that existing users
using the "old" IDE drivers would not suddenly be confronted with a
hda->sda switch.

I have not really followed Debian kernels regarding this, but currently I
think we basically just have both IDE and ATA drivers enabled. Correct?

Are any of those early "avoid duplicate PCI ID" patches still active?

Do we have any idea yet how this is going to be handled/documented for
upgrades?

[maximilian attems-9]

On Mon, Jul 07, 2008 at 07:54:44PM +0200, Andreas Barth wrote:

> * Pierre Habouzit (madcoder@...) [080707 19:48]:
> > Changing kernel at this point of the release would be too destructive,
> > so unless there is a big fat problem in the .25 that the .26 should fix
> > and is unbackportable (does such a beast even exist ?) I'm rather
> > opposed to it. Note that the asm/page.h mess is still not fixed thanks
> > to hppa.
> >
> > Disclaimer: it's my own opinion, I did not check what other Release Team
> > member think about this.
>
> I agree with you, at least with my current informations.

please read the changelog trunk on all the 2.6.26 fixes.

we have allways stated that .26 will be the release kernel.
i don't understand why this would come as a surprise.

.26 is to be released in a week, which is early enough to
prepare all stuff including testing migration.

--
maks


--
To UNSUBSCRIBE, email to debian-release-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[maximilian attems-9]

On Mon, Jul 07, 2008 at 10:09:43PM +0200, Frans Pop wrote:

> On Monday 07 July 2008, maximilian attems wrote:
> > > There are valid arguments to be found for staying with 2.6.25 a bit
> > > longer, but "D-I has not yet converted to it" is NOT one of them.
> >
> > testing users are currently on an unsupported kernel.
>
> Eh, how does that follow my last para which I assume you are commenting
> on, but which has nothing to do with testing?
>
> A side-note to your comment though...
>
> IMO testing kernel support is the weakest point in the current upload
> strategy by the kernel team. By uploading the next upstream release to
> unstable basically as soon as it's available upstream, Debian users (both
> unstable and testing) are frequently missing out on at least one or two
> upstream stable updates for the previous stable ("stable -1") release.

agreed on the week point, but not to your conclusions.
it often happens that d-i is blocking on older release.
like the beta that happened to want to stick to 2.6.22
which was a pure catastrophe, half a year too old, without
support for e1000e and newer intel boards..
 
> We worked around this for .24 by doing an upstream stable update through
> t-p-u.

dannf did and he is from the kernel team.
it was not a workaround, but again a stick to previous instead of
working forward.
 
> Upstream does seem to recognize the fact that a new release will need at
> least a few updates before it is actually "stable and usable", and will
> therefore do at least a few stable updates (for both "new stable"
> and "stable -1" in parallel). This basically happens in parallel to the
> new merge window (say the time to -rc2) and some upstream releases get
> "longer term" upstream stable support (.18, .22, .25).

.22 didn't stay long with us. this was said back then for .16 and
didn't matter on the long run.
 
> My personal opinion is that it would be better to delay the upload of new
> upstream releases to unstable until the .2 or maybe even .3 upstream
> stable update has become available. This would mean a bit more work for
> the kernel team, but I would expect that to be solvable.

don't see any point on that.
it wouldn't accelerate the meta package sort.

 
> That would also give more time for initial arch-specific and l-m-e issues
> for the new upstream to be worked out (e.g. in experimental) without
> breaking unstable too much. IMO a new kernel version should only be
> uploaded to unstable if kernel meta packages can be updated at roughly
> the same time.

this is a currently a week point, but unstable is the place to sort
such.
 
> It would also allow to upload a few more stable updates for "stable -1"
> and to migrate those to testing, giving testing users on average better
> support and it would give D-I some more "breathing space" to do releases.
>
> When a new stable *is* uploaded, D-I should be able to switch faster too
> (at least, if there's someone willing to do the initial kernel-wedge
> work) as the main criterium for D-I to switch to a new kernel version is:
> does the new version look about to be ready to migrate to testing, which
> current early uploads of the kernel to unstable effectively never are.

<sarcastic mode on>
never seen that, d-i has always been dragging.
<sarcastic mode off>

would wish that kmuto be an official d-i member. he even
tracks rc snapshot releases when necessary.
 

> > > A much more important argument is that .25 has seen and will almost
> > > certainly continue to get a lot more stabilization effort upstream
> > > than is "normal" for upstream kernel releases because long term
> > > releases for at least two important other distros are based on it. I
> > > doubt .26 will get the same upstream attention.
> > > Given the lack of capacity in Debian to do any real stabilization
> > > (cherry picking/backporting of fixes from later releases) ourselves,
> > > that could IMO be an important consideration for staying with .25 for
> > > Lenny.
> >
> > that doesn't matter a lot, if you look into our 2.6.18 or the RH patch
> > biest you'll notice the RH men force boot behind their backporting
> > machine.
>
> I'm having serious trouble parsing what you're trying to say here. Could
> you rephrase?

you never checked the rh kernel. they do a *lot* of backporting and
have a big team working on that. so you'll notice that none of those
patches landed in ours. so your argument sounds nice, but doesn't
help in practise.

.26 got a *lot* upstream attention and solves a number of .25 regressions.
it is wanted for read-only bind mounts,