Re: 2.6.12 upload

[Bastian Blank]

On Mon, Aug 22, 2005 at 12:58:51PM +0200, Bastian Blank wrote:
> > I think Andres already fixed this, but i will let him comment on this.
> They need to be unique per debian architecture.

Bah, no, it is not fixed, it just generated duplicated package entries.
But it is rather easy fixable.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Sven Luther]

On Mon, Jul 18, 2005 at 03:19:05PM +0200, Thiemo Seufer wrote:
> Andres Salomon wrote:
> > Alright folks, I think the packaging is ready to be beaten on by people. 
> > So, unless anyone has any concerns/problems/etc, I'm going to assume
> > everything's a go for uploading 2.6.12.
> > 
> > The current changes and state of the packaging:
> >   - source package is called linux-2.6
> >   - binary image packages have been renamed from kernel-image-* to
> > linux-image-*.  binary header packages have been renamed from
> > kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> > any comments/concerns/requirements, please be sure to let us know.
> >   - debian/control is generated from debian/templates/control.*.in, and
> > naming/descriptions should be consistent across the various archs.
> >   - config files are generated from the pieces in debian/arch, with
> > management of configs made a lot easier via tools in trunk/scripts
> > (initconfig and split-config).  I will probably tweak settings for
> > the global config a bit more; expect some FTBFS for architectures
> > until we figure out which options are safe for everyone, and which
> > options are suitable only for certain archs.
> >   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> > miscompiling things.  however, if any architectures require gcc-4.0,
> > either let me know, or update svn directly.
> >   - debian/README* and trunks/docs/ has information that kernel team
> > members will find useful to understand the new packaging.
> >   - there are 3 patches that were in 2.6.11 that have been dropped due to
> > lack of interest; sparc, alpha, and powerpc folks should determine
> > their value, at some point.
> 
> FWIW, I gave up on the common kernel package for mips/mipsel for now,
> and will build mips kernels via a linux-patch package which
> build-depends on the source .deb. The reasons which prompted me to
> do so are listed below, vaguely in order of importance.

Would you reconsider after a discussion of your points, and work together to
bring them to a satisfactory point for all instead of going your own lone way ?

A few comments on your problems, in light of the 2.6.12-5 packages and over a
month of development since you wrote this. I believe that all but mips/mipsel
are already in the main linux-2.6 package, so you are the only one having
problems with this.

> Issues of the common kernel package:
> 
> General problems:
> - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
>   are thrown out of the archive, anything which isn't ready until then
>   will lose support.
>   It is IMHO not realistic to expect the rest of the world to wait for
>   some obscure subarchitecture.

Ok, this is a valid point, the current argument from Andres is that we have
one set in unstable and one in testing, and that we keep arches with problems
artificially outside of testing, so the older version remain.

This causes indeed problems with d-i, but this is more a d-i build bug than
anything else, and needs to be checked or adapted.

This whole point may need more thought maybe, but for 2.6.12 is no problem as
there is no 2.6.11 we are removing.

> - Coupling the smallest fix for a subarchitecture to a full upload of
>   the whole arch any package puts pressure on the autobuilder network
>   without much gain, and causes many users to download "new" kernels
>   identical to the old ones because of the version bump. -> E.g.
>   disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.

This can and should be fixed with the so called arch-specific uploads
(-x.0.0.1 or something such), which is a mechanism supposedly documented for
this exact purpose (for example, powerpc could have rebuilt -3 in this way).

Upto recently this was not supported by the infrastructure script, but i
believe either it was fixed for the sarge packages, or it can easily be.

Not sure about the ftp-master/buildd admin side of this however. Any comment
on this are welcome.

> Implementation problems:
> - A generic header package is used, plus architecture-specific header
>   packages which add some bits like configuration defines and process
>   structure offsets. Architecture-specific header patches aren't taken
>   into account, but are needed for patches outside include/asm-$arch.

Well, hppa and m68k already have arch-specific patches, and there is a
post-install hook for headers which allows you to install your own stuff. This
is a false problem that can easily be fixed.

> - Flavour names are assumed to be unique, this doesn't work well for
>   bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
>   bit kernels.

I think Andres already fixed this, but i will let him comment on this.

> - Architecture-specific patches are restricted to a single patch per
>   arch/subarch, with an $arch.* naming. This means to copy an identical
>   patch with different name to 

Re: 2.6.12 upload

[Sven Luther]

On Mon, Aug 22, 2005 at 12:58:51PM +0200, Bastian Blank wrote:
> On Mon, Aug 22, 2005 at 12:24:14PM +0200, Sven Luther wrote:
> > > General problems:
> > > - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
> > >   are thrown out of the archive, anything which isn't ready until then
> > >   will lose support.
> > >   It is IMHO not realistic to expect the rest of the world to wait for
> > >   some obscure subarchitecture.
> > 
> > Ok, this is a valid point, the current argument from Andres is that we have
> > one set in unstable and one in testing, and that we keep arches with 
> > problems
> > artificially outside of testing, so the older version remain.
> 
> You can just disable the build of that images and the old packages will
> remain until dak is fixed to remove such sourceless packages (Okay, the
> headers will be not installable further).

I was under the impression that the older source would stau in such cases. But
this doesn't solve all, since it is nice to have a known working subset of
kernels, maybe we could have a scheme where the two last are always there, and
before the release, we freeze, remove the not wanted from testing, keep it
there, and also as copy in sid until the release, and stay with the two latest
kernels in sid for the next-gen development.

> > > - Coupling the smallest fix for a subarchitecture to a full upload of
> > >   the whole arch any package puts pressure on the autobuilder network
> > >   without much gain, and causes many users to download "new" kernels
> > >   identical to the old ones because of the version bump. -> E.g.
> > >   disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
> > 
> > This can and should be fixed with the so called arch-specific uploads
> > (-x.0.0.1 or something such), which is a mechanism supposedly documented for
> > this exact purpose (for example, powerpc could have rebuilt -3 in this way).
> 
> No, bin-NMUs are only allowed to have a updated changelog.

Ok. Maybe we can discuss to have something else with the buildd/ftp guys, as
our need is specific. This is mostly a buildd admin problem anyway.

> > Not sure about the ftp-master/buildd admin side of this however. Any comment
> > on this are welcome.
> 
> x-y.0.1 is mapped to source x-y.

Ok, so this is fixed, thanks, i can now do local builds more easily yoo :)

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Bastian Blank]

On Mon, Aug 22, 2005 at 12:24:14PM +0200, Sven Luther wrote:
> > General problems:
> > - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
> >   are thrown out of the archive, anything which isn't ready until then
> >   will lose support.
> >   It is IMHO not realistic to expect the rest of the world to wait for
> >   some obscure subarchitecture.
> 
> Ok, this is a valid point, the current argument from Andres is that we have
> one set in unstable and one in testing, and that we keep arches with problems
> artificially outside of testing, so the older version remain.

You can just disable the build of that images and the old packages will
remain until dak is fixed to remove such sourceless packages (Okay, the
headers will be not installable further).

> > - Coupling the smallest fix for a subarchitecture to a full upload of
> >   the whole arch any package puts pressure on the autobuilder network
> >   without much gain, and causes many users to download "new" kernels
> >   identical to the old ones because of the version bump. -> E.g.
> >   disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
> 
> This can and should be fixed with the so called arch-specific uploads
> (-x.0.0.1 or something such), which is a mechanism supposedly documented for
> this exact purpose (for example, powerpc could have rebuilt -3 in this way).

No, bin-NMUs are only allowed to have a updated changelog.

> Not sure about the ftp-master/buildd admin side of this however. Any comment
> on this are welcome.

x-y.0.1 is mapped to source x-y.

> > - Flavour names are assumed to be unique, this doesn't work well for
> >   bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
> >   bit kernels.
> 
> I think Andres already fixed this, but i will let him comment on this.

They need to be unique per debian architecture.

> > - Same goes for the control file generation, some moved away directory
> >   gets searched for control.in files as well, no check for valid arch
> >   names or the resulting duplicate package definitions.
> 
> Also easily fixable, if not fixed already.

Fixed. It now spits if you move the original version away to disable
them.

> > - The resulting control file suggests every available bootloader for
> >   each image, with an [ $arch ] specifier. This is generally ugly and
> >   doesn't help for e.g. mipsel subarches with per-subarch bootloaders
> >   (colo, delo, sibyl).
> 
> Well, i am sure waldi's arch//defines will yield a satisfying resolution
> to this, i belive this is already possible, as -powerpc and -powerpc-smp
> depend on mkvmlinuz, while -powerpc64 does not.

Yes, it does.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0


signature.asc
Description: Digital signature

Re: linux-kernel-di udebs [Was: Re: 2.6.12 upload]

[Sven Luther]

On Thu, Jul 28, 2005 at 06:18:28PM +0200, Goswin von Brederlow wrote:
> Bastian Blank <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote:
> >> I tend to aggree, though I believe Franz Pop, or perhaps some of the
> >> other d-i team members have reason for keeping these images separate.
> >> Perhaps they could reiterate them here.
> >
> > Mostly two reasons:
> > - Changes in the d-i packages don't trigger a complete rebuild.
> > - There are more then 200 different binary packages.
> >
> > Bastian
> 
> At the start changes have been common and modules have been added or
> removed or packages been split or joined.
> 
> But hasn't that settled down now? Aren't the linux-kernel-di udebs
> consistent enough to be handled by kernel-source uploads?
> 
> I've CCed debian-boot to get a broader opinion.

Notice that i believe this is a bogus argument anyway.

The right way to solve this would be for the main kernel package to provide
one .udeb for each individual module, and then the problem of regrouping them
or not and changing sizes goes away all by itself. And we even gain
flexibility at the d-i image build level, and make third-party (particularly
non-free modules) .udeb inclusion easier. We would not be limited to the
actual artificial and sometime bogus grouping and separation of .udebs, and we
would have the possibility to download only those drivers we need.

If all other technical aspects are solved (more to this below), this would be
the most clean and elegant solution.

Sadly, it seems that the dpkg/apt/whatever infrastructure will have some
trouble keeping up with the *HUGE* amount of .udebs involved, and this was
probably the reason why this was not done for the sarge timeframe, especially
as we where in the "we will release next month" loop.

But now we are at the start of a new release cycle, and there should be no
major reason not to solve this technical huge-number-of-udebs problem in our
infrastructure.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

linux-kernel-di udebs [Was: Re: 2.6.12 upload]

[Goswin von Brederlow]

Bastian Blank <[EMAIL PROTECTED]> writes:

> On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote:
>> I tend to aggree, though I believe Franz Pop, or perhaps some of the
>> other d-i team members have reason for keeping these images separate.
>> Perhaps they could reiterate them here.
>
> Mostly two reasons:
> - Changes in the d-i packages don't trigger a complete rebuild.
> - There are more then 200 different binary packages.
>
> Bastian

At the start changes have been common and modules have been added or
removed or packages been split or joined.

But hasn't that settled down now? Aren't the linux-kernel-di udebs
consistent enough to be handled by kernel-source uploads?

I've CCed debian-boot to get a broader opinion.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Bastian Blank]

On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote:
> I tend to aggree, though I believe Franz Pop, or perhaps some of the
> other d-i team members have reason for keeping these images separate.
> Perhaps they could reiterate them here.

Mostly two reasons:
- Changes in the d-i packages don't trigger a complete rebuild.
- There are more then 200 different binary packages.

Bastian

-- 
Insufficient facts always invite danger.
-- Spock, "Space Seed", stardate 3141.9


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Colin Watson]

On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> and kernel-image packages without any regards to linux-kernel-di. They
> will become out of sync and end up without source -> GPL violation.

Last I checked, dak was being reeducated so that it could be told about
udebs it needed to keep around due to them being in initrd builds. The
same approach could be used fairly easily to keep kernel source around
until the corresponding udebs have been rebuilt.

The main problem with moving udebs into the kernel build process, I
think, is that the installer team needs to be able to change their
structure relatively frequently; for example, the exact balance of
modules in various udebs affects whether it's possible to build
installer floppies and other media with space restrictions.
Historically, having the udebs be controlled by the d-i team made sense.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Wed, Jul 27, 2005 at 11:20:29PM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > We seem to be running around in circles here. If an image package
> > depends on kernel-tree-x.y.z-N, then kernel-source-x.y.z can be
> > updated and the image can still be rebuilt, verbatim.
> >
> > Let me try and illustrate by example:
> >
> > * kernel-source-2.6.8 version 2.6.8-1 is released
> > * kernel-image-2.6.8-i386 version 2.6.8-1 is released with a dependancy
> >   on kernel-tree-2.6.8-1
> > * kernel-source-2.6.8 version 2.6.8-2 is released
> > * kernel-image-2.6.8-i386 is not updated, but can still be rebuilt
> >   using kernel-source-2.6.8 version 2.6.8-1 or version 2.6.8-2
> >
> > Now, if di could use the kernel-tree dependancies, then
> > kernel-source can be updated and the di images can still be rebuilt.
> >
> > -- 
> > Horms
> 
> But that all went out the window with the linux-2.6 source upload.
> 
> Now it is linux-2.6 version 2.6.12-1 getting replaced by 2.6.13-1 and
> kernel-tree-2.6.12-1 is repalced by kernel-tree-2.6.13-1. No more
> 2.6.12 source for the images.

Yes, that would obviously be a problem, though this might be solvable
by coordinating upgrading the upstream version between the
kernel and d-i teams. Upstream movement is unlikely to occur close
to release, and Franz Pop already mentioned that nightly builds
were acceptable for most other times.

> And D-I does not have a depends or build-depends on the tree anyway as
> it downloads the precompiled debs, unpacks them and repack them
> differently as udebs.
> 
> 
> The best and only solution sofar is to megre the
> linux-kernel-di- udebs into the linux-2.6 package and get them
> build directly when the source is compiled.

I tend to aggree, though I believe Franz Pop, or perhaps some of the
other d-i team members have reason for keeping these images separate.
Perhaps they could reiterate them here.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Horms <[EMAIL PROTECTED]> writes:

> We seem to be running around in circles here. If an image package
> depends on kernel-tree-x.y.z-N, then kernel-source-x.y.z can be
> updated and the image can still be rebuilt, verbatim.
>
> Let me try and illustrate by example:
>
> * kernel-source-2.6.8 version 2.6.8-1 is released
> * kernel-image-2.6.8-i386 version 2.6.8-1 is released with a dependancy
>   on kernel-tree-2.6.8-1
> * kernel-source-2.6.8 version 2.6.8-2 is released
> * kernel-image-2.6.8-i386 is not updated, but can still be rebuilt
>   using kernel-source-2.6.8 version 2.6.8-1 or version 2.6.8-2
>
> Now, if di could use the kernel-tree dependancies, then
> kernel-source can be updated and the di images can still be rebuilt.
>
> -- 
> Horms

But that all went out the window with the linux-2.6 source upload.

Now it is linux-2.6 version 2.6.12-1 getting replaced by 2.6.13-1 and
kernel-tree-2.6.12-1 is repalced by kernel-tree-2.6.13-1. No more
2.6.12 source for the images.

And D-I does not have a depends or build-depends on the tree anyway as
it downloads the precompiled debs, unpacks them and repack them
differently as udebs.


The best and only solution sofar is to megre the
linux-kernel-di- udebs into the linux-2.6 package and get them
build directly when the source is compiled.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Wed, Jul 27, 2005 at 02:22:09PM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Jul 26, 2005 at 06:23:05PM +0200, Goswin von Brederlow wrote:
> >> Horms <[EMAIL PROTECTED]> writes:
> >> 
> >> > On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> >> >> Horms <[EMAIL PROTECTED]> writes:
> >> >> 
> >> >> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> >> >> >> The DI kernel udebs (linux-kernel-di- source) takes the
> >> >> >> kernel-image deb, splits it up into kernel and several groups of
> >> >> >> modules and builds udebs. There is no Depends there and can't be to
> >> >> >> keep the kernel-image debs available.
> >> >> >> 
> >> >> >> 
> >> >> >> kernel-image-di-arch ---source---> linux-kernel-di
> >> >> >>   |
> >> >> >> magic
> >> >> >>   |
> >> >> >>   \/
> >> >> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
> >> >> >>   |
> >> >> >>   \/
> >> >> >>kernel sources
> >> >> >> 
> >> >> >> 
> >> >> >> The 'magic' part is the problem.
> >> >> >
> >> >> > I don't follow why there is a problem with linux-kernel-di 
> >> >> > depending on kernel-tree-X.Y.Z-N.
> >> >> >
> >> >> > -- 
> >> >> > Horms
> >> >> 
> >> >> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> >> >> and kernel-image packages without any regards to linux-kernel-di. They
> >> >> will become out of sync and end up without source -> GPL violation.
> >> >> 
> >> >> In the old setup kernel-source-2.6.8 will remain until removed manualy
> >> >> and linux-kernel-di has that as source.
> >> >
> >> > But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
> >> > Surely this resolves the problem some people percieve with regards
> >> > to the GPL.
> >> 
> >> No. Since linux-2.6 source means kernel-tree-x.y.(z+1)-1 will replace
> >> kernel-tree-x.y.z-n now.
> >> 
> >> You would have to provide 1 <= z <= Z, 1 <= n <= N for it to still
> >> work.
> >
> > Ok, understood. Is there a reason that the dependancy can't be on 
> > kernel-tree-x.y.x-N?
> >
> > -- 
> > Horms
> 
> Haeh?
> 
> The dependency is on the exact source used to build the binary.

We seem to be running around in circles here. If an image package
depends on kernel-tree-x.y.z-N, then kernel-source-x.y.z can be
updated and the image can still be rebuilt, verbatim.

Let me try and illustrate by example:

* kernel-source-2.6.8 version 2.6.8-1 is released
* kernel-image-2.6.8-i386 version 2.6.8-1 is released with a dependancy
  on kernel-tree-2.6.8-1
* kernel-source-2.6.8 version 2.6.8-2 is released
* kernel-image-2.6.8-i386 is not updated, but can still be rebuilt
  using kernel-source-2.6.8 version 2.6.8-1 or version 2.6.8-2

Now, if di could use the kernel-tree dependancies, then
kernel-source can be updated and the di images can still be rebuilt.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Horms <[EMAIL PROTECTED]> writes:

> On Tue, Jul 26, 2005 at 06:23:05PM +0200, Goswin von Brederlow wrote:
>> Horms <[EMAIL PROTECTED]> writes:
>> 
>> > On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
>> >> Horms <[EMAIL PROTECTED]> writes:
>> >> 
>> >> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
>> >> >> The DI kernel udebs (linux-kernel-di- source) takes the
>> >> >> kernel-image deb, splits it up into kernel and several groups of
>> >> >> modules and builds udebs. There is no Depends there and can't be to
>> >> >> keep the kernel-image debs available.
>> >> >> 
>> >> >> 
>> >> >> kernel-image-di-arch ---source---> linux-kernel-di
>> >> >>   |
>> >> >> magic
>> >> >>   |
>> >> >>   \/
>> >> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
>> >> >>   |
>> >> >>   \/
>> >> >>kernel sources
>> >> >> 
>> >> >> 
>> >> >> The 'magic' part is the problem.
>> >> >
>> >> > I don't follow why there is a problem with linux-kernel-di 
>> >> > depending on kernel-tree-X.Y.Z-N.
>> >> >
>> >> > -- 
>> >> > Horms
>> >> 
>> >> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
>> >> and kernel-image packages without any regards to linux-kernel-di. They
>> >> will become out of sync and end up without source -> GPL violation.
>> >> 
>> >> In the old setup kernel-source-2.6.8 will remain until removed manualy
>> >> and linux-kernel-di has that as source.
>> >
>> > But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
>> > Surely this resolves the problem some people percieve with regards
>> > to the GPL.
>> 
>> No. Since linux-2.6 source means kernel-tree-x.y.(z+1)-1 will replace
>> kernel-tree-x.y.z-n now.
>> 
>> You would have to provide 1 <= z <= Z, 1 <= n <= N for it to still
>> work.
>
> Ok, understood. Is there a reason that the dependancy can't be on 
> kernel-tree-x.y.x-N?
>
> -- 
> Horms

Haeh?

The dependency is on the exact source used to build the binary.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Tue, Jul 26, 2005 at 06:23:05PM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> >> Horms <[EMAIL PROTECTED]> writes:
> >> 
> >> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> >> >> The DI kernel udebs (linux-kernel-di- source) takes the
> >> >> kernel-image deb, splits it up into kernel and several groups of
> >> >> modules and builds udebs. There is no Depends there and can't be to
> >> >> keep the kernel-image debs available.
> >> >> 
> >> >> 
> >> >> kernel-image-di-arch ---source---> linux-kernel-di
> >> >>   |
> >> >> magic
> >> >>   |
> >> >>   \/
> >> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
> >> >>   |
> >> >>   \/
> >> >>kernel sources
> >> >> 
> >> >> 
> >> >> The 'magic' part is the problem.
> >> >
> >> > I don't follow why there is a problem with linux-kernel-di 
> >> > depending on kernel-tree-X.Y.Z-N.
> >> >
> >> > -- 
> >> > Horms
> >> 
> >> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> >> and kernel-image packages without any regards to linux-kernel-di. They
> >> will become out of sync and end up without source -> GPL violation.
> >> 
> >> In the old setup kernel-source-2.6.8 will remain until removed manualy
> >> and linux-kernel-di has that as source.
> >
> > But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
> > Surely this resolves the problem some people percieve with regards
> > to the GPL.
> 
> No. Since linux-2.6 source means kernel-tree-x.y.(z+1)-1 will replace
> kernel-tree-x.y.z-n now.
> 
> You would have to provide 1 <= z <= Z, 1 <= n <= N for it to still
> work.

Ok, understood. Is there a reason that the dependancy can't be on 
kernel-tree-x.y.x-N?

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Frans Pop]

On Tuesday 26 July 2005 20:00, Stephen R Marenka wrote:
> daily builds aren't that big of a deal. If one fails because of a
> kernel change, you update the config and build it manually or the next
> day. This is already what happens with a change in the build-deps (at
> least, if you're not watching closely enough).

Right. The main concern is breaking the latest Beta or RC release by 
kernel changes. Daily builds are, almost by definition, not a problem.


pgpQAxu965JER.pgp
Description: PGP signature

Re: 2.6.12 upload

[Goswin von Brederlow]

Stephen R Marenka <[EMAIL PROTECTED]> writes:

> On Tue, Jul 26, 2005 at 06:24:43PM +0200, Goswin von Brederlow wrote:
>> Stephen R Marenka <[EMAIL PROTECTED]> writes:
>
>> > Really it's just creating udebs with the kernel and specific modules.
>> 
>> That would solve a lot of problems, including the GPL one.  The debs
>> and udebs would update at the same time each time.
>> 
>> On the other hand it would mean D-I has to change the version more
>> often but that should grep the Packages file to find the current
>> version for daily builds imho.
>
> daily builds aren't that big of a deal. If one fails because of a kernel
> change, you update the config and build it manually or the next day. This 
> is already what happens with a change in the build-deps (at least, if 
> you're not watching closely enough). 

But why bother? Just add KERNEL_VERSION=$(grep-dctrl -P
linux-kernel-di-$(ARCH) -n -s Version Packages) and let it figure it
out automatically. :)

Or something to the same effect.

Mfg
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Stephen R Marenka]

On Tue, Jul 26, 2005 at 06:24:43PM +0200, Goswin von Brederlow wrote:
> Stephen R Marenka <[EMAIL PROTECTED]> writes:

> > Really it's just creating udebs with the kernel and specific modules.
> 
> That would solve a lot of problems, including the GPL one.  The debs
> and udebs would update at the same time each time.
> 
> On the other hand it would mean D-I has to change the version more
> often but that should grep the Packages file to find the current
> version for daily builds imho.

daily builds aren't that big of a deal. If one fails because of a kernel
change, you update the config and build it manually or the next day. This 
is already what happens with a change in the build-deps (at least, if 
you're not watching closely enough). 

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Goswin von Brederlow]

Stephen R Marenka <[EMAIL PROTECTED]> writes:

> On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
>> Horms <[EMAIL PROTECTED]> writes:
>> 
>> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
>> >> The DI kernel udebs (linux-kernel-di- source) takes the
>> >> kernel-image deb, splits it up into kernel and several groups of
>> >> modules and builds udebs. There is no Depends there and can't be to
>> >> keep the kernel-image debs available.
>> >> 
>> >> 
>> >> kernel-image-di-arch ---source---> linux-kernel-di
>> >>   |
>> >> magic
>> >>   |
>> >>   \/
>> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
>> >>   |
>> >>   \/
>> >>kernel sources
>> >> 
>> >> 
>> >> The 'magic' part is the problem.
>> >
>> > I don't follow why there is a problem with linux-kernel-di 
>> > depending on kernel-tree-X.Y.Z-N.
>> >
>> > -- 
>> > Horms
>> 
>> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
>> and kernel-image packages without any regards to linux-kernel-di. They
>> will become out of sync and end up without source -> GPL violation.
>> 
>> In the old setup kernel-source-2.6.8 will remain until removed manualy
>> and linux-kernel-di has that as source.
>
> I'd like to see the magic moved into the kernel packaging. Right now the 
> magic is performed using the kernel-wedge package and config files from
> .
>
> Really it's just creating udebs with the kernel and specific modules.

That would solve a lot of problems, including the GPL one.  The debs
and udebs would update at the same time each time.

On the other hand it would mean D-I has to change the version more
often but that should grep the Packages file to find the current
version for daily builds imho.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Horms <[EMAIL PROTECTED]> writes:

> On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
>> Horms <[EMAIL PROTECTED]> writes:
>> 
>> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
>> >> The DI kernel udebs (linux-kernel-di- source) takes the
>> >> kernel-image deb, splits it up into kernel and several groups of
>> >> modules and builds udebs. There is no Depends there and can't be to
>> >> keep the kernel-image debs available.
>> >> 
>> >> 
>> >> kernel-image-di-arch ---source---> linux-kernel-di
>> >>   |
>> >> magic
>> >>   |
>> >>   \/
>> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
>> >>   |
>> >>   \/
>> >>kernel sources
>> >> 
>> >> 
>> >> The 'magic' part is the problem.
>> >
>> > I don't follow why there is a problem with linux-kernel-di 
>> > depending on kernel-tree-X.Y.Z-N.
>> >
>> > -- 
>> > Horms
>> 
>> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
>> and kernel-image packages without any regards to linux-kernel-di. They
>> will become out of sync and end up without source -> GPL violation.
>> 
>> In the old setup kernel-source-2.6.8 will remain until removed manualy
>> and linux-kernel-di has that as source.
>
> But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
> Surely this resolves the problem some people percieve with regards
> to the GPL.

No. Since linux-2.6 source means kernel-tree-x.y.(z+1)-1 will replace
kernel-tree-x.y.z-n now.

You would have to provide 1 <= z <= Z, 1 <= n <= N for it to still
work.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Stephen R Marenka]

On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> >> The DI kernel udebs (linux-kernel-di- source) takes the
> >> kernel-image deb, splits it up into kernel and several groups of
> >> modules and builds udebs. There is no Depends there and can't be to
> >> keep the kernel-image debs available.
> >> 
> >> 
> >> kernel-image-di-arch ---source---> linux-kernel-di
> >>   |
> >> magic
> >>   |
> >>   \/
> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
> >>   |
> >>   \/
> >>kernel sources
> >> 
> >> 
> >> The 'magic' part is the problem.
> >
> > I don't follow why there is a problem with linux-kernel-di 
> > depending on kernel-tree-X.Y.Z-N.
> >
> > -- 
> > Horms
> 
> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> and kernel-image packages without any regards to linux-kernel-di. They
> will become out of sync and end up without source -> GPL violation.
> 
> In the old setup kernel-source-2.6.8 will remain until removed manualy
> and linux-kernel-di has that as source.

I'd like to see the magic moved into the kernel packaging. Right now the 
magic is performed using the kernel-wedge package and config files from
.

Really it's just creating udebs with the kernel and specific modules.

-- 
Stephen R. Marenka If life's not fun, you're not doing it right!
<[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Horms]

On Tue, Jul 26, 2005 at 03:26:04PM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> >> The DI kernel udebs (linux-kernel-di- source) takes the
> >> kernel-image deb, splits it up into kernel and several groups of
> >> modules and builds udebs. There is no Depends there and can't be to
> >> keep the kernel-image debs available.
> >> 
> >> 
> >> kernel-image-di-arch ---source---> linux-kernel-di
> >>   |
> >> magic
> >>   |
> >>   \/
> >> kernel-tree-X.Y.Z-N <---depends--- kernel-image
> >>   |
> >>   \/
> >>kernel sources
> >> 
> >> 
> >> The 'magic' part is the problem.
> >
> > I don't follow why there is a problem with linux-kernel-di 
> > depending on kernel-tree-X.Y.Z-N.
> >
> > -- 
> > Horms
> 
> The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
> and kernel-image packages without any regards to linux-kernel-di. They
> will become out of sync and end up without source -> GPL violation.
> 
> In the old setup kernel-source-2.6.8 will remain until removed manualy
> and linux-kernel-di has that as source.

But kernel-source-x.y.z.N provides kernel-tree-x.y.z-n for 1 <= n <= N
Surely this resolves the problem some people percieve with regards
to the GPL.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Horms <[EMAIL PROTECTED]> writes:

> On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
>> The DI kernel udebs (linux-kernel-di- source) takes the
>> kernel-image deb, splits it up into kernel and several groups of
>> modules and builds udebs. There is no Depends there and can't be to
>> keep the kernel-image debs available.
>> 
>> 
>> kernel-image-di-arch ---source---> linux-kernel-di
>>   |
>> magic
>>   |
>>   \/
>> kernel-tree-X.Y.Z-N <---depends--- kernel-image
>>   |
>>   \/
>>kernel sources
>> 
>> 
>> The 'magic' part is the problem.
>
> I don't follow why there is a problem with linux-kernel-di 
> depending on kernel-tree-X.Y.Z-N.
>
> -- 
> Horms

The problem is that the DAK will update linux-2.6, kernel-tree-x.y.z-n
and kernel-image packages without any regards to linux-kernel-di. They
will become out of sync and end up without source -> GPL violation.

In the old setup kernel-source-2.6.8 will remain until removed manualy
and linux-kernel-di has that as source.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Thu, Jul 21, 2005 at 11:04:07AM +0200, Goswin von Brederlow wrote:
> Horms <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote:
> >> Thiemo Seufer <[EMAIL PROTECTED]> writes:
> >> 
> >> > Andres Salomon wrote:
> >> > [snip]
> >> >> >   It is IMHO not realistic to expect the rest of the world to wait for
> >> >> >   some obscure subarchitecture.
> >> >> 
> >> >> Who said we're going to wait for some obscure subarchitecture?  We're
> >> >> going to keep working on kernels until we freeze for etch, at which 
> >> >> point
> >> >> the subarchitectures have a limit amount of time to catch up.
> >> >
> >> > The problem is the ongoing development in unstable. It is e.g. not
> >> > possible to build debian-installer for that subarch and upload it
> >> > if its kernel isn't already/still in unstable.
> >> >
> >> >
> >> > Thiemo
> >> 
> >> Actualy there are 2 problems:
> >> 
> >> 1. Slow archs will keep the kernel-source from migrating to
> >> testing. That is if those archs are still testing blockers.
> >> 
> >> I think this can seriously harm the amount of testing the kernel gets.
> >
> > Suelry this is a broader problem realating to buildds in general,
> > if they aren't fast enough, they need more resources. We can help
> > this to some extent by trying to cut down on the number of flavours
> > floating around, especially on slower arches. However, the kernel
> > is by no means the largest package in Debian (I believe OpenOffice.Org
> > builds in arm take a full week) and this doesn't seem to be a major
> > problem in Debian at large.
> 
> No. I don't mean that m68k will take so long to compile. Well, it
> does, but it will get there in time for medium or low
> uploads. Critical uploads might stress it though. But an extra day
> delay isn't too bad.
> 
> But what if the kernel FTBFS on mips? It needs to be looked into, the
> mips patch needs to be updated, tested, merged and a new source needs
> to be uploaded. If the looking into and fixing takes 3 month then that
> will be 3 month without a new kernel in etch.

Yes, that is a problematic scenario. But if such a problem occurs,
and it really is holding up the kernel for all arches, surely
some time can be found to fix patch at the time.

> >> 2. Each kernel-image-di- source needs the right kernel-image
> >> version and source for its architecture to be present in the archive
> >> to be GPL compliant.
> >> 
> >> This is only a problem for the archive software to keep track
> >> of. Someone has to write code for this.
> >> 
> >> The D-I build should be using only the linux-kernel-di udebs if I'm
> >> not mistaken. As long as they are available D-I should keep building.
> >> 
> >> 
> >> Or did I miss something and the linux-kernel-di packages will
> >> disapear into the main kernel-source package?
> >
> > Firstly, I don't agree that this is neccessary for GPL compliance
> > in any way whatsoever, however I do accept that some people believe that
> > it is. To keep those people happy, kernel-images should depend on
> > kernel-tree-X.Y.Z-N and everything works just fine - that is, the
> > kernel-image can be reproduced verbatim ecen if the kernel source
> > package increases N.
> 
> You've got the wrong packages.
> 
> The DI kernel udebs (linux-kernel-di- source) takes the
> kernel-image deb, splits it up into kernel and several groups of
> modules and builds udebs. There is no Depends there and can't be to
> keep the kernel-image debs available.
> 
> 
> kernel-image-di-arch ---source---> linux-kernel-di
>   |
> magic
>   |
>   \/
> kernel-tree-X.Y.Z-N <---depends--- kernel-image
>   |
>   \/
>kernel sources
> 
> 
> The 'magic' part is the problem.

I don't follow why there is a problem with linux-kernel-di 
depending on kernel-tree-X.Y.Z-N.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Sven Luther]

On Mon, Jul 18, 2005 at 09:03:39PM +0200, Thiemo Seufer wrote:
> Andres Salomon wrote:
> [snip]
> > >> - Dependencies with arch spec for one-arch packages.
> > > 
> > > Right, the control file is full of the packages with control fields like 
> > > this:
> > > 
> > > Architecture: powerpc
> > > Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
> > > module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo 
> > > [hppa], 
> > > mkvmlinuz [powerpc]
> > > 
> > > The non-powerpc dependencies will probably not break anything, but 
> > > introduce a lot of additional clutter. I understand that it's easier that 
> > > way, but having only relevant dependencies listed would be cleaner. And, 
> > > to improve readability, it would be nice to have all the control file 
> > > generation logic moved to a separate script, which may be called from the
> > > the rules file.
> > 
> > I disagree.  I did it this way because I prefer to see exactly what
> > architectures are using for their boot loaders, etc.  That's just my
> > preference.
> 
> The bootloader dependencies need to be per flavour. It makes no sense
> to depend on N bootloaders for an architecture where N-1 are unusable
> for the specific flavour's kernel image.

We could also have a common bootloader package, which would depend on the
right thing for each arch, and then use some trick like the mkvmlinuz debconf
question to let the user select the bootloader. not sure if we can then have
the debconf questions download and install the bootloader, or if we could ask
the apt/dpkg/whatever folk to add per-subarch dependencies.

Maybe we could simply have a per flavour entry that is appended to the depends
though, so we can set it by hand for each linux-image.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Sven Luther]

On Tue, Jul 19, 2005 at 01:08:59AM +0200, Horms wrote:
> On Mon, Jul 18, 2005 at 12:20:31PM -0400, Andres Salomon wrote:
> > On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote:
> > 
> > > On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> > [...]
> > >>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> > >> miscompiling things.  however, if any architectures require gcc-4.0,
> > >> either let me know, or update svn directly.
> > > 
> > > How are you planing to do that.
> > > I need to do something about the fact that users go and
> > > grab kernel-source-2.4.27 and it doesn't compile with the
> > > default gcc any more. Here are three solutions I have thought.
> > > 
> > > 1. Document this somewhere
> > > 2. Change the makefile to default to gcc-3.3
> > > 3. Change the makefile to print out a nice error if gcc version >=4.0
> > > 
> > > In all cases it seems it would be good to recommend gcc-3.3.
> > > 
> > 
> > Actually, enough people on IRC have said that gcc-4.0 works for that, that
> > I'm not convinced gcc-3.3 is necessary.  I'm on the fence, I could go
> > either way.
> 
> I for one haven't been able to compile 2.4.27 (from sarge) with gcc-4.0,
> it dies horribly, and as I understand there is no interest uptream in
> making 2.4 friendly to gcc-4.0. Sure it might work for some
> configurations, but I'm pretty sure its broken for enough that its a
> problem, the 686 config in sarge for starters.

2.4 on x86 is supposed to go away for etch anyway though.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Horms <[EMAIL PROTECTED]> writes:

> On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote:
>> Thiemo Seufer <[EMAIL PROTECTED]> writes:
>> 
>> > Andres Salomon wrote:
>> > [snip]
>> >> >   It is IMHO not realistic to expect the rest of the world to wait for
>> >> >   some obscure subarchitecture.
>> >> 
>> >> Who said we're going to wait for some obscure subarchitecture?  We're
>> >> going to keep working on kernels until we freeze for etch, at which point
>> >> the subarchitectures have a limit amount of time to catch up.
>> >
>> > The problem is the ongoing development in unstable. It is e.g. not
>> > possible to build debian-installer for that subarch and upload it
>> > if its kernel isn't already/still in unstable.
>> >
>> >
>> > Thiemo
>> 
>> Actualy there are 2 problems:
>> 
>> 1. Slow archs will keep the kernel-source from migrating to
>> testing. That is if those archs are still testing blockers.
>> 
>> I think this can seriously harm the amount of testing the kernel gets.
>
> Suelry this is a broader problem realating to buildds in general,
> if they aren't fast enough, they need more resources. We can help
> this to some extent by trying to cut down on the number of flavours
> floating around, especially on slower arches. However, the kernel
> is by no means the largest package in Debian (I believe OpenOffice.Org
> builds in arm take a full week) and this doesn't seem to be a major
> problem in Debian at large.

No. I don't mean that m68k will take so long to compile. Well, it
does, but it will get there in time for medium or low
uploads. Critical uploads might stress it though. But an extra day
delay isn't too bad.

But what if the kernel FTBFS on mips? It needs to be looked into, the
mips patch needs to be updated, tested, merged and a new source needs
to be uploaded. If the looking into and fixing takes 3 month then that
will be 3 month without a new kernel in etch.

>> 2. Each kernel-image-di- source needs the right kernel-image
>> version and source for its architecture to be present in the archive
>> to be GPL compliant.
>> 
>> This is only a problem for the archive software to keep track
>> of. Someone has to write code for this.
>> 
>> The D-I build should be using only the linux-kernel-di udebs if I'm
>> not mistaken. As long as they are available D-I should keep building.
>> 
>> 
>> Or did I miss something and the linux-kernel-di packages will
>> disapear into the main kernel-source package?
>
> Firstly, I don't agree that this is neccessary for GPL compliance
> in any way whatsoever, however I do accept that some people believe that
> it is. To keep those people happy, kernel-images should depend on
> kernel-tree-X.Y.Z-N and everything works just fine - that is, the
> kernel-image can be reproduced verbatim ecen if the kernel source
> package increases N.

You've got the wrong packages.

The DI kernel udebs (linux-kernel-di- source) takes the
kernel-image deb, splits it up into kernel and several groups of
modules and builds udebs. There is no Depends there and can't be to
keep the kernel-image debs available.


kernel-image-di-arch ---source---> linux-kernel-di
  |
magic
  |
  \/
kernel-tree-X.Y.Z-N <---depends--- kernel-image
  |
  \/
   kernel sources


The 'magic' part is the problem.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Tue, Jul 19, 2005 at 09:56:01AM -0400, Andres Salomon wrote:
> On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote:
> 
> [...]
> 
> > I need to do something about the fact that users go and
> > grab kernel-source-2.4.27 and it doesn't compile with the
> > default gcc any more. Here are three solutions I have thought.
> > 
> > 1. Document this somewhere
> > 2. Change the makefile to default to gcc-3.3
> > 3. Change the makefile to print out a nice error if gcc version >=4.0
> 
> 
> #3 would be my preference; however, you still have the problem that people
> may attempt to compile a vanilla 2.4 kernel w/ gcc-3.3.  IMO, this is
> something that should be checked for by kernel-package; only allow certain
> kernel versions to be compiled w/ certain versions of gcc, or even
> override the version of gcc that it's compiling w/.  That is, if 2.4.27 is
> being compiled, kernel-package internally sets CC=gcc-3.3.


That still doesn't prevent users from falling into the trap of
uncompiling the source, running configure, and then being presented with
some entirely non-obvious errors becaus they are running the default
GCC. I think it might be better to buld this logic into the Makefule
of each kernel version, could you give some specific gcc/kernel version
combinations that you are thinking about. Also, do you know if this
varies from arch to arch?

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Wed, Jul 20, 2005 at 10:17:00AM +0200, Goswin von Brederlow wrote:
> Thiemo Seufer <[EMAIL PROTECTED]> writes:
> 
> > Andres Salomon wrote:
> > [snip]
> >> >   It is IMHO not realistic to expect the rest of the world to wait for
> >> >   some obscure subarchitecture.
> >> 
> >> Who said we're going to wait for some obscure subarchitecture?  We're
> >> going to keep working on kernels until we freeze for etch, at which point
> >> the subarchitectures have a limit amount of time to catch up.
> >
> > The problem is the ongoing development in unstable. It is e.g. not
> > possible to build debian-installer for that subarch and upload it
> > if its kernel isn't already/still in unstable.
> >
> >
> > Thiemo
> 
> Actualy there are 2 problems:
> 
> 1. Slow archs will keep the kernel-source from migrating to
> testing. That is if those archs are still testing blockers.
> 
> I think this can seriously harm the amount of testing the kernel gets.

Suelry this is a broader problem realating to buildds in general,
if they aren't fast enough, they need more resources. We can help
this to some extent by trying to cut down on the number of flavours
floating around, especially on slower arches. However, the kernel
is by no means the largest package in Debian (I believe OpenOffice.Org
builds in arm take a full week) and this doesn't seem to be a major
problem in Debian at large.

> 2. Each kernel-image-di- source needs the right kernel-image
> version and source for its architecture to be present in the archive
> to be GPL compliant.
> 
> This is only a problem for the archive software to keep track
> of. Someone has to write code for this.
> 
> The D-I build should be using only the linux-kernel-di udebs if I'm
> not mistaken. As long as they are available D-I should keep building.
> 
> 
> Or did I miss something and the linux-kernel-di packages will
> disapear into the main kernel-source package?

Firstly, I don't agree that this is neccessary for GPL compliance
in any way whatsoever, however I do accept that some people believe that
it is. To keep those people happy, kernel-images should depend on
kernel-tree-X.Y.Z-N and everything works just fine - that is, the
kernel-image can be reproduced verbatim ecen if the kernel source
package increases N.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Thiemo Seufer <[EMAIL PROTECTED]> writes:

> Andres Salomon wrote:
> [snip]
>> >   It is IMHO not realistic to expect the rest of the world to wait for
>> >   some obscure subarchitecture.
>> 
>> Who said we're going to wait for some obscure subarchitecture?  We're
>> going to keep working on kernels until we freeze for etch, at which point
>> the subarchitectures have a limit amount of time to catch up.
>
> The problem is the ongoing development in unstable. It is e.g. not
> possible to build debian-installer for that subarch and upload it
> if its kernel isn't already/still in unstable.
>
>
> Thiemo

Actualy there are 2 problems:

1. Slow archs will keep the kernel-source from migrating to
testing. That is if those archs are still testing blockers.

I think this can seriously harm the amount of testing the kernel gets.


2. Each kernel-image-di- source needs the right kernel-image
version and source for its architecture to be present in the archive
to be GPL compliant.

This is only a problem for the archive software to keep track
of. Someone has to write code for this.

The D-I build should be using only the linux-kernel-di udebs if I'm
not mistaken. As long as they are available D-I should keep building.


Or did I miss something and the linux-kernel-di packages will
disapear into the main kernel-source package?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Andres Salomon <[EMAIL PROTECTED]> writes:

> On Mon, 18 Jul 2005 21:03:39 +0200, Thiemo Seufer wrote:
>> The bootloader dependencies need to be per flavour. It makes no sense
>> to depend on N bootloaders for an architecture where N-1 are unusable
>> for the specific flavour's kernel image.
>> 
>> 
>
> I'm assuming this is a mips-specific thing, because I haven't heard of the
> case w/ any other archs where each flavour requires a different bootloader.
>
> Anyways, if that is the case, then yes; we'll need to make this
> per-flavour (gah).  

m68k needs one per subarch, powerpc too. Alpha springs to mind as
well.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Sun, 17 Jul 2005 00:36:38 -0400, Jurij Smakov wrote:

> On Sun, 17 Jul 2005, Bastian Blank wrote:
> 
>> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
>>> Hm, anything I'm forgetting?
>>
>> - The scripts dir in the linux-headers package must match the flavour.
> 
> The problem here is that some architectures (s390, powerpc and mips) are 
> using two different ELF formats, depending on the options in kernel config 
> file. So, building different flavours for s390, for example, will produce 
> two different (incompatible) sets of executables in scripts/ subdir. As we 
> are currently including scripts/ directory only in the arch-common headers 
> package, that will be broken on the architectures. A simple solution: 
> include scripts/ subdirectory into the flavour-specific headers package. 
> Probably, it makes sense to do it only for architectures which actually 
> need that. I'll check what I can cook up.

This should be fixed in SVN; I'm just waiting for the final test to build.
 The scripts directory is now in each flavour's linux-headers package.



> 
>> - The descriptions are wrong for non-i386.
> 
> I am not too happy with how the decscription stuff turned out. I think 
> that the boilerplate descriptions should be generated only if the custom 
> descriptions are not provided, and there should be a Makefile.inc variable 
> controlling it. I suggest that support for custom descriptions be 
> restored.
> 

>From my last svn commit:

+ Add some description files for flavours. Basically, for each flavour, if
+ 'class' is set, then in the description, "@class@ class systems" will be
+ described; if class is not set, then the flavour name will be used. 
+ Ie, if there's no desc.386, then "this kernel is for 386 class systems"
+ will show up in the description.
+
+ There's also @desc@ (see the s390 stuff for an example) that will be
+ appended to the description.
+
+ I haven't actually implemented this yet; please fill in what you need
+ for your pet architecture, and I'll do it tomorrow.

Pretty self-explanatory, I hope...

>> - Dependencies with arch spec for one-arch packages.
> 
> Right, the control file is full of the packages with control fields like 
> this:
> 
> Architecture: powerpc
> Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
> module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], 
> mkvmlinuz [powerpc]
> 
> The non-powerpc dependencies will probably not break anything, but 
> introduce a lot of additional clutter. I understand that it's easier that 
> way, but having only relevant dependencies listed would be cleaner. And, 
> to improve readability, it would be nice to have all the control file 
> generation logic moved to a separate script, which may be called from the
> the rules file.


As I mentioned before, I prefer each arch's bootloaders to show up in this
list; however, mips requires us to not do this.  So, I'll redo this bit
after 2.6.12-1, when we try to get mips/mipsel in.


> 
>> - linux-headers-.*-all is no dummy package.
> 
> As Bastian pointed out, currently this package does not build. I can
> implement it and adjust the description.
> 

I've gone ahead and removed the -all package for now; I'm still not happy
w/ the name, and they're really just sugar for module build-deps anyways;
certainly not crucial.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote:

[...]

> I need to do something about the fact that users go and
> grab kernel-source-2.4.27 and it doesn't compile with the
> default gcc any more. Here are three solutions I have thought.
> 
> 1. Document this somewhere
> 2. Change the makefile to default to gcc-3.3
> 3. Change the makefile to print out a nice error if gcc version >=4.0


#3 would be my preference; however, you still have the problem that people
may attempt to compile a vanilla 2.4 kernel w/ gcc-3.3.  IMO, this is
something that should be checked for by kernel-package; only allow certain
kernel versions to be compiled w/ certain versions of gcc, or even
override the version of gcc that it's compiling w/.  That is, if 2.4.27 is
being compiled, kernel-package internally sets CC=gcc-3.3.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Christian T. Steigies]

On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> Alright folks, I think the packaging is ready to be beaten on by people. 
> So, unless anyone has any concerns/problems/etc, I'm going to assume
> everything's a go for uploading 2.6.12.
> 
> The current changes and state of the packaging:
>   - source package is called linux-2.6
>   - binary image packages have been renamed from kernel-image-* to
> linux-image-*.  binary header packages have been renamed from
> kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> any comments/concerns/requirements, please be sure to let us know.
>   - debian/control is generated from debian/templates/control.*.in, and
> naming/descriptions should be consistent across the various archs.
>   - config files are generated from the pieces in debian/arch, with
> management of configs made a lot easier via tools in trunk/scripts
> (initconfig and split-config).  I will probably tweak settings for
> the global config a bit more; expect some FTBFS for architectures
> until we figure out which options are safe for everyone, and which
> options are suitable only for certain archs.
>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> miscompiling things.  however, if any architectures require gcc-4.0,
> either let me know, or update svn directly.
>   - debian/README* and trunks/docs/ has information that kernel team
> members will find useful to understand the new packaging.

It's been a week since I read a bit of that and tried to add m68k support.
The biggest problem right now is, how do I cross-compile? I have built cross
gcc 2.95 and 3.3 compilers and would like to build the m68k images with
them, at least for testing the new packaging. I had no serious trouble to
get that going by adding --arch m68k --cross_compile m68k-linux to the
make-kpkg call. Is it possible to use this also with the new linux-2.6
packaging or at least add it when I build m68k images? I guess it should be
made optional, otherwise every arch would try to cross compile m68k images,
but if I can not use cross compiling at all, it would be very hard to add
m68k to the common linux source, since it takes me about 6 hours to compile
one image. Even the time required to build just one image is too long, when
I am still testing the new source.

My box at home is unreachable right now, IIRC the problem might actually
have been in kernel-package, it would not pick up an m68k config but a
default config from the build system instead, which obviously can not be
used for building an m68k kernel. Has anybody done cross-compiling for the
new source package and has hints on how to add it to the debian/rules and
debian/config?

m68k will not use gcc-4.0 for a while for kernels I guess, there are too
many new internal compiler errors. gcc-3.3 should be fine.

Christian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Sun, Jul 17, 2005 at 12:29:47AM +0200, Sven Luther wrote:
> On Sat, Jul 16, 2005 at 04:55:42PM +0300, Horms wrote:
> > On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> > > Alright folks, I think the packaging is ready to be beaten on by people. 
> > > So, unless anyone has any concerns/problems/etc, I'm going to assume
> > > everything's a go for uploading 2.6.12.
> > 
> > Excellent
> > 
> > > The current changes and state of the packaging:
> > >   - source package is called linux-2.6
> > >   - binary image packages have been renamed from kernel-image-* to
> > > linux-image-*.  binary header packages have been renamed from
> > > kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> > > any comments/concerns/requirements, please be sure to let us know.
> > >   - debian/control is generated from debian/templates/control.*.in, and
> > > naming/descriptions should be consistent across the various archs.
> > >   - config files are generated from the pieces in debian/arch, with
> > > management of configs made a lot easier via tools in trunk/scripts
> > > (initconfig and split-config).  I will probably tweak settings for
> > > the global config a bit more; expect some FTBFS for architectures
> > > until we figure out which options are safe for everyone, and which
> > > options are suitable only for certain archs.
> > >   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> > > miscompiling things.  however, if any architectures require gcc-4.0,
> > > either let me know, or update svn directly.
> > 
> > How are you planing to do that.
> > I need to do something about the fact that users go and
> > grab kernel-source-2.4.27 and it doesn't compile with the
> > default gcc any more. Here are three solutions I have thought.
> > 
> > 1. Document this somewhere
> > 2. Change the makefile to default to gcc-3.3
> > 3. Change the makefile to print out a nice error if gcc version >=4.0
>   4. ask for removal of 2.4.27 from etch/sid :)

Yes, sorry I forgot that one, its currently my prefered option.
But perhaps one of the other three is more appropruiate for the
short-term.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Mon, Jul 18, 2005 at 12:20:31PM -0400, Andres Salomon wrote:
> On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote:
> 
> > On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> [...]
> >>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> >> miscompiling things.  however, if any architectures require gcc-4.0,
> >> either let me know, or update svn directly.
> > 
> > How are you planing to do that.
> > I need to do something about the fact that users go and
> > grab kernel-source-2.4.27 and it doesn't compile with the
> > default gcc any more. Here are three solutions I have thought.
> > 
> > 1. Document this somewhere
> > 2. Change the makefile to default to gcc-3.3
> > 3. Change the makefile to print out a nice error if gcc version >=4.0
> > 
> > In all cases it seems it would be good to recommend gcc-3.3.
> > 
> 
> Actually, enough people on IRC have said that gcc-4.0 works for that, that
> I'm not convinced gcc-3.3 is necessary.  I'm on the fence, I could go
> either way.

I for one haven't been able to compile 2.4.27 (from sarge) with gcc-4.0,
it dies horribly, and as I understand there is no interest uptream in
making 2.4 friendly to gcc-4.0. Sure it might work for some
configurations, but I'm pretty sure its broken for enough that its a
problem, the 686 config in sarge for starters.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Thiemo Seufer]

Andres Salomon wrote:
[snip]
> >> - Dependencies with arch spec for one-arch packages.
> > 
> > Right, the control file is full of the packages with control fields like 
> > this:
> > 
> > Architecture: powerpc
> > Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
> > module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], 
> > mkvmlinuz [powerpc]
> > 
> > The non-powerpc dependencies will probably not break anything, but 
> > introduce a lot of additional clutter. I understand that it's easier that 
> > way, but having only relevant dependencies listed would be cleaner. And, 
> > to improve readability, it would be nice to have all the control file 
> > generation logic moved to a separate script, which may be called from the
> > the rules file.
> 
> I disagree.  I did it this way because I prefer to see exactly what
> architectures are using for their boot loaders, etc.  That's just my
> preference.

The bootloader dependencies need to be per flavour. It makes no sense
to depend on N bootloaders for an architecture where N-1 are unusable
for the specific flavour's kernel image.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Thiemo Seufer]

Andres Salomon wrote:
[snip]
> >   It is IMHO not realistic to expect the rest of the world to wait for
> >   some obscure subarchitecture.
> 
> Who said we're going to wait for some obscure subarchitecture?  We're
> going to keep working on kernels until we freeze for etch, at which point
> the subarchitectures have a limit amount of time to catch up.

The problem is the ongoing development in unstable. It is e.g. not
possible to build debian-installer for that subarch and upload it
if its kernel isn't already/still in unstable.


Thiemo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Mon, 18 Jul 2005 21:03:39 +0200, Thiemo Seufer wrote:

> Andres Salomon wrote:
> [snip]
>> >> - Dependencies with arch spec for one-arch packages.
>> > 
>> > Right, the control file is full of the packages with control fields like 
>> > this:
>> > 
>> > Architecture: powerpc
>> > Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
>> > module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], 
>> > mkvmlinuz [powerpc]
>> > 
>> > The non-powerpc dependencies will probably not break anything, but 
>> > introduce a lot of additional clutter. I understand that it's easier that 
>> > way, but having only relevant dependencies listed would be cleaner. And, 
>> > to improve readability, it would be nice to have all the control file 
>> > generation logic moved to a separate script, which may be called from the
>> > the rules file.
>> 
>> I disagree.  I did it this way because I prefer to see exactly what
>> architectures are using for their boot loaders, etc.  That's just my
>> preference.
> 
> The bootloader dependencies need to be per flavour. It makes no sense
> to depend on N bootloaders for an architecture where N-1 are unusable
> for the specific flavour's kernel image.
> 
> 

I'm assuming this is a mips-specific thing, because I haven't heard of the
case w/ any other archs where each flavour requires a different bootloader.

Anyways, if that is the case, then yes; we'll need to make this
per-flavour (gah).  





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Mon, 18 Jul 2005 15:19:05 +0200, Thiemo Seufer wrote:

> Andres Salomon wrote:
>> Alright folks, I think the packaging is ready to be beaten on by people. 
>> So, unless anyone has any concerns/problems/etc, I'm going to assume
>> everything's a go for uploading 2.6.12.
>> 
>> The current changes and state of the packaging:
>>   - source package is called linux-2.6
>>   - binary image packages have been renamed from kernel-image-* to
>> linux-image-*.  binary header packages have been renamed from
>> kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
>> any comments/concerns/requirements, please be sure to let us know.
>>   - debian/control is generated from debian/templates/control.*.in, and
>> naming/descriptions should be consistent across the various archs.
>>   - config files are generated from the pieces in debian/arch, with
>> management of configs made a lot easier via tools in trunk/scripts
>> (initconfig and split-config).  I will probably tweak settings for
>> the global config a bit more; expect some FTBFS for architectures
>> until we figure out which options are safe for everyone, and which
>> options are suitable only for certain archs.
>>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
>> miscompiling things.  however, if any architectures require gcc-4.0,
>> either let me know, or update svn directly.
>>   - debian/README* and trunks/docs/ has information that kernel team
>> members will find useful to understand the new packaging.
>>   - there are 3 patches that were in 2.6.11 that have been dropped due to
>> lack of interest; sparc, alpha, and powerpc folks should determine
>> their value, at some point.
> 
> FWIW, I gave up on the common kernel package for mips/mipsel for now,
> and will build mips kernels via a linux-patch package which
> build-depends on the source .deb. The reasons which prompted me to
> do so are listed below, vaguely in order of importance.
> 
> 
> Thiemo
> 
> 
> Issues of the common kernel package:
> 
> General problems:
> - The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
>   are thrown out of the archive, anything which isn't ready until then
>   will lose support.

That's correct.  This is why we'll end up w/ two different kernel
versions in unstable and testing.  This is a feature, not a bug; we don't
want to carry around 20 different kernel versions because an architecture
can't get its act together.


>   It is IMHO not realistic to expect the rest of the world to wait for
>   some obscure subarchitecture.

Who said we're going to wait for some obscure subarchitecture?  We're
going to keep working on kernels until we freeze for etch, at which point
the subarchitectures have a limit amount of time to catch up.  I'd hope
they'd be able to keep up all along, but I'm not sure whether that'll be
the case.  Regardless, if architectures can all catch up at some point, we
can get a kernel in testing that supports most everything; come freeze
time, it becomes real easy to stabilize.  We'll still need to organize and
figure out what we'll be able to offer, and what sub/niche-archs we'll
have to drop.  I suspect working from the same source package will force
us to communicate a bit more often, as well.  :)



> - Coupling the smallest fix for a subarchitecture to a full upload of
>   the whole arch any package puts pressure on the autobuilder network
>   without much gain, and causes many users to download "new" kernels
>   identical to the old ones because of the version bump. -> E.g.
>   disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
>  

I don't think this will be an issue; we have enough development happening
at a given time that we can probably just do regularly scheduled releases,
w/ various architectures doing updates at the same time.  We also have
enough security updates happening that we'll need to release pretty
regularly.. (blah).




Bah, the long list below makes my head hurt.  I'll ignore a bunch of stuff
that I consider problems we can defer until some other time..  ;p


> Implementation problems:
> - A generic header package is used, plus architecture-specific header
>   packages which add some bits like configuration defines and process
>   structure offsets. Architecture-specific header patches aren't taken
>   into account, but are needed for patches outside include/asm-$arch.

Architecture-specific patches will be handled by subarch stuff.  However,
given that nothing else is using the subarch stuff yet, and it's pretty
untested, I'll repeat what I said on IRC for the people playing along at
home; we'll skip mips/mipsel for now, and try to get it into the linux-2.6
package in the near future.  



> - Flavour names are assumed to be unique, this doesn't work well for
>   bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
>   bit kernels.

If subarches are to be used, then I assume each will have a 

Re: 2.6.12 upload

[Andres Salomon]

On Sun, 17 Jul 2005 04:15:39 +0200, Bastian Blank wrote:

> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
>> Hm, anything I'm forgetting?
[...]
> - The shell-code is unreadable.

So fix it? :)

I'm still planning on using cdbs2 for packaging in the long term, anyways.
The single-source packaging framework is mostly a reimplementation of
things jbailey and I have already done for cdbs2.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Sun, 17 Jul 2005 00:36:38 -0400, Jurij Smakov wrote:

> On Sun, 17 Jul 2005, Bastian Blank wrote:
> 
>> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
>>> Hm, anything I'm forgetting?
>>
>> - The scripts dir in the linux-headers package must match the flavour.
> 
> The problem here is that some architectures (s390, powerpc and mips) are 
> using two different ELF formats, depending on the options in kernel config 
> file. So, building different flavours for s390, for example, will produce 


*Ew*

> two different (incompatible) sets of executables in scripts/ subdir. As we 
> are currently including scripts/ directory only in the arch-common headers 
> package, that will be broken on the architectures. A simple solution: 
> include scripts/ subdirectory into the flavour-specific headers package. 
> Probably, it makes sense to do it only for architectures which actually 
> need that. I'll check what I can cook up.
> 
>> - The descriptions are wrong for non-i386.
> 
> I am not too happy with how the decscription stuff turned out. I think 
> that the boilerplate descriptions should be generated only if the custom 
> descriptions are not provided, and there should be a Makefile.inc variable 
> controlling it. I suggest that support for custom descriptions be 
> restored.
> 

This is not something I consider to be a major problem.  We can either
figure out a way to make descriptions overridable on a per-{sub,}arch
basis, or revert to the per-arch control.in templates; I think the value
of having them all generated from the same template file is valuable,
however.  Just looking at the number of archs that lacked ABINAMEs, or had
things hardcoded, or just skewed from convention made me think that it
would be better in the long run to force archs to all be the same wrt
package names and descriptions.  For each arch/flavour, we really only
want to override small bits of each; if s390 is really that radically
different wrt description, we can even hardcode something in debian/rules
for now that does something special for s390's variable replacement.


>> - Dependencies with arch spec for one-arch packages.
> 
> Right, the control file is full of the packages with control fields like 
> this:
> 
> Architecture: powerpc
> Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
> module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], 
> mkvmlinuz [powerpc]
> 
> The non-powerpc dependencies will probably not break anything, but 
> introduce a lot of additional clutter. I understand that it's easier that 
> way, but having only relevant dependencies listed would be cleaner. And, 
> to improve readability, it would be nice to have all the control file 
> generation logic moved to a separate script, which may be called from the
> the rules file.

I disagree.  I did it this way because I prefer to see exactly what
architectures are using for their boot loaders, etc.  That's just my
preference.

> 
>> - linux-headers-.*-all is no dummy package.
> 
> As Bastian pointed out, currently this package does not build. I can 
> implement it and adjust the description.
> 

I'm not sure what is meant by this, but I'll look closer..


> Best regards,
> 
> Jurij Smakov[EMAIL PROTECTED]
> Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Andres Salomon]

On Sat, 16 Jul 2005 16:55:42 +0300, Horms wrote:

> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
[...]
>>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
>> miscompiling things.  however, if any architectures require gcc-4.0,
>> either let me know, or update svn directly.
> 
> How are you planing to do that.
> I need to do something about the fact that users go and
> grab kernel-source-2.4.27 and it doesn't compile with the
> default gcc any more. Here are three solutions I have thought.
> 
> 1. Document this somewhere
> 2. Change the makefile to default to gcc-3.3
> 3. Change the makefile to print out a nice error if gcc version >=4.0
> 
> In all cases it seems it would be good to recommend gcc-3.3.
> 

Actually, enough people on IRC have said that gcc-4.0 works for that, that
I'm not convinced gcc-3.3 is necessary.  I'm on the fence, I could go
either way.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Thiemo Seufer]

Andres Salomon wrote:
> Alright folks, I think the packaging is ready to be beaten on by people. 
> So, unless anyone has any concerns/problems/etc, I'm going to assume
> everything's a go for uploading 2.6.12.
> 
> The current changes and state of the packaging:
>   - source package is called linux-2.6
>   - binary image packages have been renamed from kernel-image-* to
> linux-image-*.  binary header packages have been renamed from
> kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> any comments/concerns/requirements, please be sure to let us know.
>   - debian/control is generated from debian/templates/control.*.in, and
> naming/descriptions should be consistent across the various archs.
>   - config files are generated from the pieces in debian/arch, with
> management of configs made a lot easier via tools in trunk/scripts
> (initconfig and split-config).  I will probably tweak settings for
> the global config a bit more; expect some FTBFS for architectures
> until we figure out which options are safe for everyone, and which
> options are suitable only for certain archs.
>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> miscompiling things.  however, if any architectures require gcc-4.0,
> either let me know, or update svn directly.
>   - debian/README* and trunks/docs/ has information that kernel team
> members will find useful to understand the new packaging.
>   - there are 3 patches that were in 2.6.11 that have been dropped due to
> lack of interest; sparc, alpha, and powerpc folks should determine
> their value, at some point.

FWIW, I gave up on the common kernel package for mips/mipsel for now,
and will build mips kernels via a linux-patch package which
build-depends on the source .deb. The reasons which prompted me to
do so are listed below, vaguely in order of importance.


Thiemo


Issues of the common kernel package:

General problems:
- The 2.6 (instead of 2.6.12 etc.) versioning means previous versions
  are thrown out of the archive, anything which isn't ready until then
  will lose support.
  It is IMHO not realistic to expect the rest of the world to wait for
  some obscure subarchitecture.
- Coupling the smallest fix for a subarchitecture to a full upload of
  the whole arch any package puts pressure on the autobuilder network
  without much gain, and causes many users to download "new" kernels
  identical to the old ones because of the version bump. -> E.g.
  disable CONFIG_PREEMPT for ia64 and let everyone upgrade their kernel.
 
Implementation problems:
- A generic header package is used, plus architecture-specific header
  packages which add some bits like configuration defines and process
  structure offsets. Architecture-specific header patches aren't taken
  into account, but are needed for patches outside include/asm-$arch.
- Flavour names are assumed to be unique, this doesn't work well for
  bi-endian machines (e.g. sb1-swarm-bn for mips/mipsel) and 32/64
  bit kernels.
- Architecture-specific patches are restricted to a single patch per
  arch/subarch, with an $arch.* naming. This means to copy an identical
  patch with different name to support mips/mipsel, it also means all
  patches which may break some other architecture have to go into a
  single file, which is ridiculous form a maintenance POV.
- Architecture-specific patches have no series mechanism, IOW they
  aren't really updateable. Even if they had, it is not feasible to
  keep multiple 2MB mips patches around for the whole duration of the
  2.6 kernel series.
- The current patch system breaks easily down. If one of the patches
  has a conflict, it is neither possible to unpatch the already applied
  patches nor does a patch replay help (because the first already
  applied patch conflicts now). So it's either rm -rf or to work around
  the patch system.
- Only -p1 patches are accepted -> no CVS diff patches, originally
  psted patches can't be used easily.
- If $EDITOR leaves a ~ backup file in the series directory, the patch
  system doesn't check if the series name is valid and tries to apply
  the copy as well.
- Same goes for the control file generation, some moved away directory
  gets searched for control.in files as well, no check for valid arch
  names or the resulting duplicate package definitions.
- The resulting control file suggests every available bootloader for
  each image, with an [ $arch ] specifier. This is generally ugly and
  doesn't help for e.g. mipsel subarches with per-subarch bootloaders
  (colo, delo, sibyl).
- The shell-snippets-disguised-as-makerules generally fails to catch
  errors.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Sven Luther]

On Sun, Jul 17, 2005 at 12:36:38AM -0400, Jurij Smakov wrote:
> On Sun, 17 Jul 2005, Bastian Blank wrote:
> >- The descriptions are wrong for non-i386.
> 
> I am not too happy with how the decscription stuff turned out. I think 
> that the boilerplate descriptions should be generated only if the custom 
> descriptions are not provided, and there should be a Makefile.inc variable 
> controlling it. I suggest that support for custom descriptions be 
> restored.

The idea was to have each flavour provide a arch/subarch/flavour specific
entry, which would be cat'ed to the global description, as well as a variable
in the short description being substituted.

This is not implemented yet, but i agree with Andres, this can be clarified
and fixed afterward.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Jurij Smakov]

On Sun, 17 Jul 2005, Bastian Blank wrote:


On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:

Hm, anything I'm forgetting?


- The scripts dir in the linux-headers package must match the flavour.


The problem here is that some architectures (s390, powerpc and mips) are 
using two different ELF formats, depending on the options in kernel config 
file. So, building different flavours for s390, for example, will produce 
two different (incompatible) sets of executables in scripts/ subdir. As we 
are currently including scripts/ directory only in the arch-common headers 
package, that will be broken on the architectures. A simple solution: 
include scripts/ subdirectory into the flavour-specific headers package. 
Probably, it makes sense to do it only for architectures which actually 
need that. I'll check what I can cook up.



- The descriptions are wrong for non-i386.


I am not too happy with how the decscription stuff turned out. I think 
that the boilerplate descriptions should be generated only if the custom 
descriptions are not provided, and there should be a Makefile.inc variable 
controlling it. I suggest that support for custom descriptions be 
restored.



- Dependencies with arch spec for one-arch packages.


Right, the control file is full of the packages with control fields like 
this:


Architecture: powerpc
Depends: initrd-tools (>= 0.1.78), coreutils | fileutils (>= 4.0), 
module-init-tools (>= 0.9.13), e2fsprogs (>= 1.35-7) [amd64], palo [hppa], 
mkvmlinuz [powerpc]


The non-powerpc dependencies will probably not break anything, but 
introduce a lot of additional clutter. I understand that it's easier that 
way, but having only relevant dependencies listed would be cleaner. And, 
to improve readability, it would be nice to have all the control file 
generation logic moved to a separate script, which may be called from the

the rules file.


- linux-headers-.*-all is no dummy package.


As Bastian pointed out, currently this package does not build. I can 
implement it and adjust the description.


Best regards,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Bastian Blank]

On Sun, Jul 17, 2005 at 04:15:39AM +0200, Bastian Blank wrote:
> - linux-headers-.*-all is no dummy package.

Bah, this package is not built anyway.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Bastian Blank]

On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> Hm, anything I'm forgetting?

- The scripts dir in the linux-headers package must match the flavour.
- The descriptions are wrong for non-i386.
- Dependencies with arch spec for one-arch packages.
- linux-headers-.*-all is no dummy package.
- The shell-code is unreadable.

Bastian

-- 
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Sven Luther]

On Sat, Jul 16, 2005 at 04:55:42PM +0300, Horms wrote:
> On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> > Alright folks, I think the packaging is ready to be beaten on by people. 
> > So, unless anyone has any concerns/problems/etc, I'm going to assume
> > everything's a go for uploading 2.6.12.
> 
> Excellent
> 
> > The current changes and state of the packaging:
> >   - source package is called linux-2.6
> >   - binary image packages have been renamed from kernel-image-* to
> > linux-image-*.  binary header packages have been renamed from
> > kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> > any comments/concerns/requirements, please be sure to let us know.
> >   - debian/control is generated from debian/templates/control.*.in, and
> > naming/descriptions should be consistent across the various archs.
> >   - config files are generated from the pieces in debian/arch, with
> > management of configs made a lot easier via tools in trunk/scripts
> > (initconfig and split-config).  I will probably tweak settings for
> > the global config a bit more; expect some FTBFS for architectures
> > until we figure out which options are safe for everyone, and which
> > options are suitable only for certain archs.
> >   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> > miscompiling things.  however, if any architectures require gcc-4.0,
> > either let me know, or update svn directly.
> 
> How are you planing to do that.
> I need to do something about the fact that users go and
> grab kernel-source-2.4.27 and it doesn't compile with the
> default gcc any more. Here are three solutions I have thought.
> 
> 1. Document this somewhere
> 2. Change the makefile to default to gcc-3.3
> 3. Change the makefile to print out a nice error if gcc version >=4.0
  4. ask for removal of 2.4.27 from etch/sid :)

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Norbert Tretkowski]

* Andres Salomon wrote:
> - there are 3 patches that were in 2.6.11 that have been dropped due to
>   lack of interest; sparc, alpha, and powerpc folks should determine
>   their value, at some point.

The dropped alpha patch is no longer required with 2.6.12, at least on
my systems the kernel works fine without it.

Norbert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Goswin von Brederlow]

Frederik Schueler <[EMAIL PROTECTED]> writes:

> Hello,
>
> On Sat, Jul 16, 2005 at 03:53:12PM +0200, Goswin von Brederlow wrote:
>> Was amd64 support merged in or do we still do a seperate amd64 image
>> package?
>
> Amd64 support is part of this package since the very beginning. :-)
>
> Best regards
> Frederik Schueler
>
> -- 
> ENOSIG

Perfect. Lets rock'n'roll. Maybe udev will start working again then.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Horms]

On Sat, Jul 16, 2005 at 12:39:55PM +0300, Andres Salomon wrote:
> Alright folks, I think the packaging is ready to be beaten on by people. 
> So, unless anyone has any concerns/problems/etc, I'm going to assume
> everything's a go for uploading 2.6.12.

Excellent

> The current changes and state of the packaging:
>   - source package is called linux-2.6
>   - binary image packages have been renamed from kernel-image-* to
> linux-image-*.  binary header packages have been renamed from
> kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
> any comments/concerns/requirements, please be sure to let us know.
>   - debian/control is generated from debian/templates/control.*.in, and
> naming/descriptions should be consistent across the various archs.
>   - config files are generated from the pieces in debian/arch, with
> management of configs made a lot easier via tools in trunk/scripts
> (initconfig and split-config).  I will probably tweak settings for
> the global config a bit more; expect some FTBFS for architectures
> until we figure out which options are safe for everyone, and which
> options are suitable only for certain archs.
>   - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
> miscompiling things.  however, if any architectures require gcc-4.0,
> either let me know, or update svn directly.

How are you planing to do that.
I need to do something about the fact that users go and
grab kernel-source-2.4.27 and it doesn't compile with the
default gcc any more. Here are three solutions I have thought.

1. Document this somewhere
2. Change the makefile to default to gcc-3.3
3. Change the makefile to print out a nice error if gcc version >=4.0

In all cases it seems it would be good to recommend gcc-3.3.

>   - debian/README* and trunks/docs/ has information that kernel team
> members will find useful to understand the new packaging.
>   - there are 3 patches that were in 2.6.11 that have been dropped due to
> lack of interest; sparc, alpha, and powerpc folks should determine
> their value, at some point.
> 
> Hm, anything I'm forgetting?
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 upload

[Frederik Schueler]

Hello,

On Sat, Jul 16, 2005 at 03:53:12PM +0200, Goswin von Brederlow wrote:
> Was amd64 support merged in or do we still do a seperate amd64 image
> package?

Amd64 support is part of this package since the very beginning. :-)

Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: 2.6.12 upload

[Goswin von Brederlow]

Andres Salomon <[EMAIL PROTECTED]> writes:

> Alright folks, I think the packaging is ready to be beaten on by people. 
> So, unless anyone has any concerns/problems/etc, I'm going to assume
> everything's a go for uploading 2.6.12.

Was amd64 support merged in or do we still do a seperate amd64 image
package?

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

2.6.12 upload

[Andres Salomon]

Alright folks, I think the packaging is ready to be beaten on by people. 
So, unless anyone has any concerns/problems/etc, I'm going to assume
everything's a go for uploading 2.6.12.

The current changes and state of the packaging:
  - source package is called linux-2.6
  - binary image packages have been renamed from kernel-image-* to
linux-image-*.  binary header packages have been renamed from
kernel-headers-* to linux-headers-*.  kfreebsd/hurd folks, if you have
any comments/concerns/requirements, please be sure to let us know.
  - debian/control is generated from debian/templates/control.*.in, and
naming/descriptions should be consistent across the various archs.
  - config files are generated from the pieces in debian/arch, with
management of configs made a lot easier via tools in trunk/scripts
(initconfig and split-config).  I will probably tweak settings for
the global config a bit more; expect some FTBFS for architectures
until we figure out which options are safe for everyone, and which
options are suitable only for certain archs.
  - i'm leaning towards using gcc-3.3, as i'm afraid of gcc-4.0
miscompiling things.  however, if any architectures require gcc-4.0,
either let me know, or update svn directly.
  - debian/README* and trunks/docs/ has information that kernel team
members will find useful to understand the new packaging.
  - there are 3 patches that were in 2.6.11 that have been dropped due to
lack of interest; sparc, alpha, and powerpc folks should determine
their value, at some point.

Hm, anything I'm forgetting?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]