Re: Kernel 6.5 from Experimental working

[Luna Jernberg]

Also updated this to 6.5.1 today and still works

Den tors 7 sep. 2023 kl 08:37 skrev Luna Jernberg :
>
> Hey!
>
> Just installed Kernel 6.5 from experimental during Debcamp 2023 on my
> ThinkPad Edge 0217A16 and it works as intended on this laptop :)
>
> //Luna bittin Jernberg 

Re: Kernel building question (Is -j8 safe and correct?)

[Ben Hutchings]

On Sun, 2021-06-13 at 15:07 +0200, Philipp Hahn wrote:
[...]
> > 3. If both of the above are true, why isn't something like that suggested 
> > on [1]?
> 
> Debian does not know your specifics and thus does not use parallel build 
> by default.
> 

Debian *does* use parallel builds by default.  But that default
behaviour is implemented in dpkg-buildpackage, so doesn't apply in this
case.

>  You must give permissions first:
> 
>  > export DEB_BUILD_OPTIONS="parallel=$(nproc)"
> 
> See 
> .
> 

That has no effect in this case.  The makefile being used is
debian/rules.gen, not debian/rules.


Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


signature.asc
Description: This is a digitally signed message part

Re: Kernel building question (Is -j8 safe and correct?)

[Ben Hutchings]

On Fri, 2021-06-11 at 19:34 -0600, Antonio Russo wrote:
> Hello,
> 
> I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
> irrelevant).
> I'm following [1], and the critical command
> 
> $ fakeroot make -f debian/rules.gen binary-arch_i386_none_real
> 
> does not suggest using -j8 (or -jnumber_of_cores).
> 
> 1. Is it safe to add -j8 ?

Yes.

> 2. Will this indeed give me the speed up I want and expect on my multi-core 
> processor?

Yes.

> 3. If both of the above are true, why isn't something like that suggested on 
> [1]?

Because no-one thought to add them yet.

Please report this as a bug in the "kernel-handbook" package (which is
the source for this web site).  If you can provide a patch, that would
be even better.

Ben.

> Best,
> Antonio
> 
> [1] 
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
> 

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus


signature.asc
Description: This is a digitally signed message part

Re: Kernel building question (Is -j8 safe and correct?)

[Philipp Hahn]

Hello Anionio,

Am 12.06.21 um 03:34 schrieb Antonio Russo:

I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
irrelevant).
I'm following [1], and the critical command

$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real

does not suggest using -j8 (or -jnumber_of_cores).

1. Is it safe to add -j8 ?


That depends on many factors, most importantly how many CPU cores your 
build host has and how many of them you want to use:
- if this is a single-user system and you're the only user and you don't 
want to do much in parallel: yes
- using all CPU cores on a multi-user system might get you complaints 
from the other users.
- watching videos while waiting for the compile to finish might be 
problematic.



2. Will this indeed give me the speed up I want and expect on my multi-core 
processor?


Probably yes, but see above. It also depends on how much RAM you have 
and how fast your disk/SSD is.



3. If both of the above are true, why isn't something like that suggested on 
[1]?


Debian does not know your specifics and thus does not use parallel build 
by default. You must give permissions first:


> export DEB_BUILD_OPTIONS="parallel=$(nproc)"

See 
.


For example the VMs and hosts of Debians build system are dedicated to 
building packages. They are controlled by the Debian admins and parallel 
building is enabled there by default - if applicable.
If you have to build many packages it might be more effective to build 
multiple source packages in parallel, as there are still packages which 
can only use one CPU. Mixing both strategies is also an option, but 
heavily depends on your usage scenario.


Philipp

Re: Kernel parameters protecting fifos and regular files

[Craig Small]

On Thu, 30 Jan 2020 at 05:26, Moritz Mühlenhoff  wrote:

> I'm in favour of setting both to 1. From a quick search Ubuntu carried a
> patch
> in their systemd package to set this as well (LP 1845637).
>
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so I'd say that src:linux should be patched as well, this
> changes
> the default at the deepest level and the /etc/sysctl.conf kicks in for
> anyone running custom built kernels.
>
OK, I'll make them both 1 rather than 2 so there is some consistency.  I
note the concern some have brought up about procps is not installed in some
minimal installations but that's not the problem we're trying to solve
here. They'll be in the next release.

Thanks all for the input.

 - Craig

Re: Kernel parameters protecting fifos and regular files

[Ben Hutchings]

On Wed, 2020-01-29 at 10:13 -0800, Moritz Mühlenhoff wrote:
> Craig Small  schrieb:
> > --4806c5059d3edeb1
> > Content-Type: text/plain; charset="UTF-8"
> > 
> > Hi,
> >   About 2 years ago the procps package added protection for hard and soft
> > symlinks. The bug report was 889098 and has seemed to work fine.
> > 
> > There is also now bug #914859 which would extend this same protection for
> > other files, as mentioned in [1]
> 
> I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
> in their systemd package to set this as well (LP 1845637).
> 
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so I'd say that src:linux should be patched as well, this changes
> the default at the deepest level and the /etc/sysctl.conf kicks in for
> anyone running custom built kernels.

There was discussion around this issue on #debian-kernel recently. 
Changing the default in src:linux doesn't help people that get their
kernel from somewhere else.  Changing it in procps also doesn't cover
minimal installations since it's only Priority: important.

Is there a higher priority package, independent of init system, that
would be suitable for carrying the Debian sysctl policy?

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




signature.asc
Description: This is a digitally signed message part

Re: Kernel parameters protecting fifos and regular files

[Moritz Mühlenhoff]

Craig Small  schrieb:
> --4806c5059d3edeb1
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>   About 2 years ago the procps package added protection for hard and soft
> symlinks. The bug report was 889098 and has seemed to work fine.
>
> There is also now bug #914859 which would extend this same protection for
> other files, as mentioned in [1]

I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
in their systemd package to set this as well (LP 1845637).

protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
by default, so I'd say that src:linux should be patched as well, this changes
the default at the deepest level and the /etc/sysctl.conf kicks in for
anyone running custom built kernels.

Cheers,
Moritz

Re: Kernel parameters protecting fifos and regular files

[Richard Laager]

On 1/28/20 9:23 PM, Craig Small wrote:
> My personal preference is to lock them down by default, by setting both
> to mode 2.
FWIW: I agree. Unless massive breakage is expected, the default should
be the most secure option. If you default to secure and that breaks
something, people will be motivated to fix it (either the root issue or
by changing the setting). If you default to compatible, very few people
will find the option and tweak it, so most people will lose out on the
security. If there is massive breakage, you can back it off, of course.

-- 
Richard



signature.asc
Description: OpenPGP digital signature

Re: kernel nvidia dkms rebuild after upgrade?

[Boyan Penkov]

Hello Dan — thanks kindly, I had indeed not noticed….

I guess I’ll have a chance to test if the libelf-dev issue is really the fix 
when the patches do roll out.

In that vein, I would like to note that 
https://security-tracker.debian.org/tracker/CVE-2017-5754 
  makes no mention 
of bpo kernels in backports.  Is this by design?

Cheers!
--
Boyan Penkov
www.boyanpenkov.com

> On Jan 7, 2018, at 18:44, Daniel Reichelt  wrote:
> 
> On 01/07/2018 07:47 PM, Boyan Penkov wrote:
>> and a backport (4.14.0-bpo2) -- in light of meltdown --
> 
> To avoid a false sense of security: according to [1], [2], [3], the
> current stretch-bpo kernel (linux-image-4.14.0-0.bpo.2-$arch) does *NOT*
> yet include any mitigations against meltdown.
> 
> Daniel
> 
> 
> 
> [1] https://security-tracker.debian.org/tracker/CVE-2017-5753
> [2] https://security-tracker.debian.org/tracker/CVE-2017-5754
> [3] https://security-tracker.debian.org/tracker/CVE-2017-5715
> 

Re: kernel nvidia dkms rebuild after upgrade?

[Boyan Penkov]

Thanks, Yao —  in messing around with this, I did end up finding a thread that 
suggested installing libelf-dev — I did so, but I guess the order in which I 
did it make me recompile my dkms modules manually.

Thanks for the note!
--
Boyan Penkov
www.boyanpenkov.com

> On Jan 7, 2018, at 18:31, Yao Wei  wrote:
> 
> It is caused by a missing dependency libelf-dev.
> It is already reported against linux-headers-4.14.0-3-amd64:
> https://bugs.debian.org/886474 
> 
> I have the same symptom of broadcom-sta-dkms
> 
> On Mon, 8 Jan 2018 at 02:47 Boyan Penkov  > wrote:
> Hello,
> 
> After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
> light of meltdown -- my nvidia drivers failed to load.
> 
> Rebulding the modules manually --
> https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
>  
> 
> -- did fix it.
> 
> Did I miss something?
> 
> Cheers!
> 
> --
> Boyan Penkov
> 

Re: kernel nvidia dkms rebuild after upgrade?

[Daniel Reichelt]

On 01/07/2018 07:47 PM, Boyan Penkov wrote:
> and a backport (4.14.0-bpo2) -- in light of meltdown --

To avoid a false sense of security: according to [1], [2], [3], the
current stretch-bpo kernel (linux-image-4.14.0-0.bpo.2-$arch) does *NOT*
yet include any mitigations against meltdown.

Daniel



[1] https://security-tracker.debian.org/tracker/CVE-2017-5753
[2] https://security-tracker.debian.org/tracker/CVE-2017-5754
[3] https://security-tracker.debian.org/tracker/CVE-2017-5715



signature.asc
Description: OpenPGP digital signature

Re: kernel nvidia dkms rebuild after upgrade?

[Yao Wei]

It is caused by a missing dependency libelf-dev.
It is already reported against linux-headers-4.14.0-3-amd64:
https://bugs.debian.org/886474

I have the same symptom of broadcom-sta-dkms

On Mon, 8 Jan 2018 at 02:47 Boyan Penkov  wrote:

> Hello,
>
> After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
> light of meltdown -- my nvidia drivers failed to load.
>
> Rebulding the modules manually --
>
> https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
> -- did fix it.
>
> Did I miss something?
>
> Cheers!
>
> --
> Boyan Penkov
>
>

Re: kernel module i915 - 3d-acceleration missing after update

[Cyril Brulebois]

Hi.

Hans-J. Ullrich hans.ullr...@loop.de (18/06/2011):
 /usr/lib/i386-linux-gnu/dri/i915_dri.so 
 /usr/lib/i386-linux-gnu/dri/swrast_dri.so
 
 Solution:
 As apt-file search i386-linux-gnu did not show any package with this 
 content, 
 I added the directories manually and created some symlinks to i915_dri.so and 
 swrast_dri.so pointing to the files /usr/lib/dri/i915_dri.so and 
 /usr/lib/dri/swrast_dri.so.

Don't do that.

 I think, this a bug, but I do not know, which package is responsible for 
 this. 
 Maybe someone, who knows better, might be able to fix it or file a bugreport.

Clearly you didn't search for i915_dri.so or swrast_dri.so, which would
have given the answer trivially. (And cFWIW, we have bugs for that
already.) That's a matter which has been communicated upon [1,2]. And
well, when it comes to X, [3] applies (instead of mailing dd@…).

 1. http://blog.mraw.org/2011/06/14/mesa_a_disturbance_in_the_Force/
 2. http://blog.mraw.org/2011/06/18/mesa_a_disturbance_in_the_Force/
 3. http://pkg-xorg.alioth.debian.org/howto/report-bugs.html

Hope this helps.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kernel module i915 - 3d-acceleration missing after update

[Hans-J. Ullrich]

 
 Clearly you didn't search for i915_dri.so or swrast_dri.so, which would
 have given the answer trivially. (And cFWIW, we have bugs for that
 already.) That's a matter which has been communicated upon [1,2]. And
 well, when it comes to X, [3] applies (instead of mailing dd@…).
 
  1. http://blog.mraw.org/2011/06/14/mesa_a_disturbance_in_the_Force/
  2. http://blog.mraw.org/2011/06/18/mesa_a_disturbance_in_the_Force/
  3. http://pkg-xorg.alioth.debian.org/howto/report-bugs.html
 
 Hope this helps.
 
 Mraw,
 KiBi.

Well, I thought the problem is not related to i915, as this is part of the 
kernel, and I did not change the kernel. It was xserver-xorg-core, which was 
updated. Additionally I was unsure, if this was really a bug, so I just 
intended to remark this strange behaviour, targeted to developers, as IMO they 
are the only ones which know, what they changed.

The further discussion will be continued at debian-user or debian-eeepc.

Best regards

Hans


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201106181119.29025.hans.ullr...@loop.de

Re: kernel module i915 - 3d-acceleration missing after update

[Cyril Brulebois]

Hans-J. Ullrich hans.ullr...@loop.de (18/06/2011):
 Well, I thought the problem is not related to i915, as this is part of
 the kernel, and I did not change the kernel.

Just to clarify: You mentioned a .so, not a .ko; there are i915 bits in
the kernel, and in userspace; in this case, this is about userspace.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kernel module i915 - 3d-acceleration missing after update

[Hans-J. Ullrich]

Am Samstag, 18. Juni 2011 schrieb Cyril Brulebois:
 Hans-J. Ullrich hans.ullr...@loop.de (18/06/2011):
  Well, I thought the problem is not related to i915, as this is part of
  the kernel, and I did not change the kernel.
 
 Just to clarify: You mentioned a .so, not a .ko; there are i915 bits in
 the kernel, and in userspace; in this case, this is about userspace.
 
 Mraw,
 KiBi.
Yes, it is userspace. Pity I don't have the logs any more (Xorg.log.0), where 
the error was shown. It showed me, that the *_dri.so could not found (so GLX 
could not be started). They originally reside below /usr/lib/dri/, but the 
driver search them below /usr/lib/i386-linux-gnu/dri/, which was not existent.

So, there is either a problem with the kernel-module, or some other thing 
accidently deleted (or did not create!) i386-linux-gnu/dri below /usr/lib.

Hope, this makes it clearer. :)

Hans


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201106181138.26394.hans.ullr...@loop.de

Re: kernel module i915 - 3d-acceleration missing after update

[Cyril Brulebois]

Hans-J. Ullrich hans.ullr...@loop.de (18/06/2011):
 Yes, it is userspace. Pity I don't have the logs any more (Xorg.log.0), where 
 the error was shown. It showed me, that the *_dri.so could not found (so GLX 
 could not be started). They originally reside below /usr/lib/dri/, but the 
 driver search them below /usr/lib/i386-linux-gnu/dri/, which was not existent.

Sorry for insisting, but you really should read what I linked you to,
that explains what happened, why, etc.

 So, there is either a problem with the kernel-module, or some other thing 
 accidently deleted (or did not create!) i386-linux-gnu/dri below /usr/lib.

No, this has nothing to do with kernel modules. This is about userspace
shared objects. Libraries, if you prefer.

 Hope, this makes it clearer. :)

That you didn't read, yes. :(

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: kernel module i915 - 3d-acceleration missing after update

[Hans-J. Ullrich]

 That you didn't read, yes. :(
 
 Mraw,
 KiBi.

I read, I read. And I will wait, what will happen.
And watch. And next time write to another list. :)

Thanky for your help anyway!

Have fun

Hans


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201106181156.40789.hans.ullr...@loop.de

Re: Kernel

[Darren Salt]

I demand that Adrian von Bidder may or may not have written...

[snip]
 As Paul has said, there is a patch to include the Debian logo at boot. As
 far as I know, the kernel still displays the traditional penguin at boot if
 a framebuffer is used, but note that on recent systems framebuffer has been
 replaced by kms which is loaded a bit later in the boot process and doesn't
 display any logo (either tux or the swirl with the patch.)

KMS still uses framebuffers, but they're provided by different modules
(radeon instead of radeonfb, for example). You still get the penguin(s) if
the relevant module is built into the kernel image or (I assume) is loaded
early enough.

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Toon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | back!
| + Lobby friends, family, business, government.WE'RE KILLING THE PLANET.

The coast was clear.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51ab0c8f30%li...@youmustbejoking.demon.co.uk

Re: Kernel

[Paul Wise]

[presumably you are not subscribed, CCing you]

On Wed, Feb 9, 2011 at 5:57 AM, Pontus Andersson
pont.anders...@gmail.com wrote:
 Hi. I like to make a request regarding the Debian Linux kernel.
 I think the tux boot should be compiled with the Debian logo..
 With tux boot I mean that some distros e.g. Arch and slackware boots with
 the logo while displaying the boot process.

Sounds like you want to look at the linux-patch-debianlogo. You will
need to recompile your kernel.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin5rb43b5orqbpq9f0vrmvjs7mfvo849le4b...@mail.gmail.com

Re: Kernel

[Adrian von Bidder]

Heyho!

On Tuesday 08 February 2011 22.57:51 Pontus Andersson wrote:
 Hi. I like to make a request regarding the Debian Linux kernel.
 I think the tux boot should be compiled with the Debian logo..
 With tux boot I mean that some distros e.g. Arch and slackware boots with
 the logo
 while displaying the boot process.

As Paul has said, there is a patch to include the Debian logo at boot. As 
far as I know, the kernel still displays the traditional penguin at boot if 
a framebuffer is used, but note that on recent systems framebuffer has been 
replaced by kms which is loaded a bit later in the boot process and doesn't 
display any logo (either tux or the swirl with the patch.)

-- vbi

-- 
Fuyez un ennemi qui sait votre défaut.
-+- Pierre Corneille, Polyeucte -+-


signature.asc
Description: This is a digitally signed message part.

Re: Kernel

[Andreas Marschke]

Hi! 

Note that there is another way to display a Debian logo at boot. 

Plymouth: http://wiki.debian.org/plymouth

Though it wont show you the logs unless you type Alt+F1, you will have
a debian logo at boot time. 

Besides that: Anyone thought about doing a loading screen from the
Debian Swirl going from the inside of the swirl curling out
along to the outer end of the swirl as the bootprocess progresses?
Just a thought for future theming/branding of the debian distro when
installing a Desktop. 

-- 
Cheers,

Andreas Marschke


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110209071116.GA14378@andres.andreas

Re: kernel-wedge does not work as expected.

[Luk Claes]

On 01/23/2011 03:06 PM, Magicloud Magiclouds wrote:
 Hi,
   I am trying to make a custom debian-installer cd. I have done this
 before, things worked fine. But this time, I got a problem.
   My running kernel installed from
 linux-image-2.6.36.3i686_bfs363.reiser4_i386.deb. It contains a naming
 mistake. So I make-kpkg a new one named
 linux-image-2.6.36.3-686_bfs363.reiser4_i386.deb and installed, not
 running.
   Then I have linux-kernel-di-i386-2.6-1.99/kernel-version as i386
  2.6.36.3 686   2.6.36.3-686 -
 linux-image-2.6.36.3-686_bfs363.reiser4.
   Here is the problem, `kernel-wedge build-arch i386` always tell me:
 dpkg-source: warning: can't parse dependency
 linux-image-2.6.36.3i686_bfs363.reiser4  [i386]
 dpkg-source: error: error occurred while parsing Build-Depends
   According to http://wiki.debian.org/DebianInstaller/Modify/CustomKernel,
 kernel-wedge could handle kernel package that were not running. Why
 here it insists on running kernel?

The problem is that a package name cannot contain an underscore. A
package name must consist only of lower case letters (a-z), digits
(0-9), plus (+) and minus (-) signs, and periods (.).

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3c4bbf.1080...@debian.org

Re: Kernel legacy

[Russ Allbery]

Klaus Ethgen kl...@ethgen.de writes:

 Background: The glibc in lenny is compiled to be incompatible with
 kernels lower than 2.6. I do not know if there are options to use newer
 glibc with older kernels.

There is other software in lenny that isn't built to be compatible with
older kernels as well.  For example, slapd is built to use epoll, which
won't work with 2.4 kernels.  I suspect you will discover others that the
package maintainer may not even be aware of.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Kernel legacy

[Luk Claes]

Klaus Ethgen wrote:
 Just to bring that back to discussion:
 
 With lenny the provided glibc seems to be incompatible to kernel 2.4.
 There are many systems out there still running with kernel 2.4 cause
 stability. (My servers which needs to be stable all run Kernel 2.4.)

s/lenny/etch/

 Is there any scenario what happens to such systems when lenny gets
 stable?

etch is already stable

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Kernel legacy

[Bastian Blank]

On Sun, Feb 01, 2009 at 05:26:30PM +0100, Klaus Ethgen wrote:
 With lenny the provided glibc seems to be incompatible to kernel 2.4.

The Linux 2.4 support ended with the Etch release. Even for Etch it is
only supported for upgrades.

 Is there any scenario what happens to such systems when lenny gets
 stable?

Fix the kernel support in newer versions.

Bastian

-- 
Suffocating together ... would create heroic camaraderie.
-- Khan Noonian Singh, Space Seed, stardate 3142.8


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Kernel legacy

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am So den  1. Feb 2009 um 18:57 schrieb Luk Claes:
  With lenny the provided glibc seems to be incompatible to kernel 2.4.
  There are many systems out there still running with kernel 2.4 cause
  stability. (My servers which needs to be stable all run Kernel 2.4.)
 
 s/lenny/etch/

? lenny is still correct. etch runs fine with kernel 2.4 (and lower by
the way).

  Is there any scenario what happens to such systems when lenny gets
  stable?
 
 etch is already stable

Yes, etch is but not lenny.

Gruß
   Klaus
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBSYYiqJ+OKpjRpO3lAQr4Hwf+O7kXdJzp5t6k2Y+kkfFYIYsY7RCqzMcn
cc1QYigdx51Nmy7XNOAXMECsaS1/Z+1egaTzxzKSvN2M02uimJn47zcnZYM/FQJF
/u8fMzaGmayVDwLh+pt1kxcP1vA4zr9TZDiBBg3cbWvkSWPZVM7oyyd95y2wTAf2
7cvClfpb53MvXwgCNYWpwuILYPFBL2Y9elHYhuSujex/Ug1Nf0F0Ie1ZrROByXBW
SUCoh2TSxR1A/h89xeuiWqKpKamFYu3zUXLCB96mrEeZVA1V0pzrpza92cmbqA8l
+zKNBSqNXG1GTdjnLVIpt8uSy1PvpD6Tzm9wbLBBKiPAwjvp+7uLZg==
=N0+s
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Kernel legacy

[Ben Hutchings]

On Sun, 2009-02-01 at 23:31 +0100, Klaus Ethgen wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Am So den  1. Feb 2009 um 18:57 schrieb Luk Claes:
   With lenny the provided glibc seems to be incompatible to kernel 2.4.
   There are many systems out there still running with kernel 2.4 cause
   stability. (My servers which needs to be stable all run Kernel 2.4.)

Since 2.4 is not supported by Debian and is barely supported by a few
kernel developers, it is hardly the stable option.  If you are aware of
specific unfixed bugs in Linux 2.6, I suggest you report them.

  s/lenny/etch/
 
 ? lenny is still correct. etch runs fine with kernel 2.4 (and lower by
 the way).

Maybe it works for you, but it is not supported.  This was made fairly
clear in the release notes:
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#s-newkernel,
 
http://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#s-incompatible-2.4.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.


signature.asc
Description: This is a digitally signed message part

debian-kernel (Re: kernel 2.6.27 in lenny?)

[Filipus Klutiero]

For kernel-related discussions, ask on debian-kernel.


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

Re: kernel 2.6.27 in lenny?

[Yves-Alexis Perez]

On mar, 2008-10-14 at 07:59 +0200, Peter Jordan wrote:
 wouldn't it
 be a good idea to take kernel 2.6.27 as the stable kernel in lenny?

If we want to release lenny before 2.6.27 is not supported anymore,
maybe it's not?

-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[James Vega]

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
 Hi.
 
 While testing some updates to my gtkpod/libgpod packages I noticed that
 I couldn't actually play any songs anymore from my iPod. Which worked
 fine some weeks ago.
 
 I traced the error back to a change in kernel 2.6.25: Apparently vfat
 file system can now become case sensitive in some cases
 (FAT: utf8 is not a recommended IO charset for FAT filesystems,
 filesystem will be case sensitive!)

Are you sure this is a kernel change and not just a change in your
kernel config?  I brought up what seems to be the same (or at least
closely related) problem 4 years ago on lkml[0].

[0] - http://lkml.org/lkml/2004/4/5/209
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[Frank Lichtenheld]

On Fri, Jul 11, 2008 at 09:11:57PM -0400, James Vega wrote:
 On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
  Hi.
  
  While testing some updates to my gtkpod/libgpod packages I noticed that
  I couldn't actually play any songs anymore from my iPod. Which worked
  fine some weeks ago.
  
  I traced the error back to a change in kernel 2.6.25: Apparently vfat
  file system can now become case sensitive in some cases
  (FAT: utf8 is not a recommended IO charset for FAT filesystems,
  filesystem will be case sensitive!)
 
 Are you sure this is a kernel change and not just a change in your
 kernel config?  I brought up what seems to be the same (or at least
 closely related) problem 4 years ago on lkml[0].

To be precise the upgrade from the current (i.e. today) 2.6.24 testing
kernel to the current 2.6.25 unstable kernel causes the problem.

So yeah, both code and config changed I guess.

Gruesse,
-- 
Frank Lichtenheld [EMAIL PROTECTED]
www: http://www.djpig.de/


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

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[Steve Langasek]

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:

 While testing some updates to my gtkpod/libgpod packages I noticed that
 I couldn't actually play any songs anymore from my iPod. Which worked
 fine some weeks ago.

 I traced the error back to a change in kernel 2.6.25: Apparently vfat
 file system can now become case sensitive in some cases
 (FAT: utf8 is not a recommended IO charset for FAT filesystems,
 filesystem will be case sensitive!) which the mentioned applications
 are totally not prepared for. They try to access files with their name
 in upper case, but since the default for vfat is shortname=lower this
 doesn't actually work anymore for files and directories that have no
 long name saved on the file system.

vfat has never supported case-insensitivity when using utf8.  You have to
pick either case-insensitivity, or unicode.  If the kernel has changed the
behavior of vfat when using iocharset=utf8, this merely makes the problems
more explicit; it was already broken in various subtle ways before this.

 So my question now is where to file the bug and I would be grateful
 for recommendations:

 - kernel: I find it unlikely that the mentioned change was done without
   a good reason given its obvious behavioural change. So I guess the
   chances that it can be reversed are slim. But I might be wrong?

I don't think this will do any good.  As James mentions, there have been
known problems with vfat+utf8 for years, that have gone unaddressed; I don't
think one more bug report will change things.

 - hal/util-linux: Maybe it would be a good idea to mount case sensitive
   vfat filesystems with shortname=winnt in the hope that would disturb
   fewer users. It would have fixed the problem at least in my case,
   but I'm not so sure it would be the right solution for most cases?

I don't think there's any way to detect at mount time whether a filesystem
*is* case-sensitive or not; if shortname=winnt will work around this
behavior, then we should instead probably use this as a default any time
utf8 is being used as the iocharset.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: Kernel selection in the installation system

[Frans Pop]

On Monday 26 March 2007 17:24, Christoph Pleger wrote:
 Can anybody tell me how the installer decides which kernel to be
 installed? Or tell me where I can find the source code of the selection
 process?

It is done from the /var/lib/dpkg/base-installer.postinst script, which 
calls an architecture dependent script for which the source is at:
http://svn.debian.org/wsvn/d-i/trunk/packages/base-installer/kernel/

Note that the Etch version of the scripts is a bit different; that version 
is available at:
http://svn.debian.org/wsvn/d-i/branches/d-i/etch/packages/base-installer/kernel/

The postinst can be found in ../debian from those locations.

Cheers,
FJP


pgpMZulIFv99h.pgp
Description: PGP signature

Re: Kernel selection in the installation system

[Lawrence Williams]

IIRC, the kernel udeb in the installer image runs the installer kernel during 
installation and the installer checks for the CPU type.

You can use the 'expert' install option to be given the opportunity to 
manually select which kernel is installed during installation.

- Lawrence


On March 26, 2007 12:54:50 pm Christoph Pleger wrote:
 Hello,

 when installing a Debian etch machine, the installation system
 automatically selects the kernel which is most appropriate for the CPU
 and installs the corresponding kernel package on the harddisk of the
 machine.

 Can anybody tell me how the installer decides which kernel to be
 installed? Or tell me where I can find the source code of the selection
 process?


 Please send your answers not only to the list (I have not subscribed it)
 but also to my private email address.

 Regards
   Christoph Pleger



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

Re: Kernel 2.6.17 and 2.6.18-3-K7 network problem

[Hendrik Sattler]

Am Mittwoch 03 Januar 2007 09:53 schrieb Antonio Laterza:
 :( ). If I choose the kernel 2.6.18 X is OK but I am not

 able to reache many sites. I can navigate very few sites
 example: www.google.com and www.mozilla.org. Using ethereal
 seems that the HTTP request go out (i.e. GET / ) but
 the ACK packet does not ask the next packet number  in
 other words seems that the GET request never reched the
 final site.

TCP windows scaling comes to mind:
http://lwn.net/Articles/92727/

HS


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

Re: Kernel 2.6.17 and 2.6.18-3-K7 network problem [SOLVED]

[Antonio Laterza]

--- Hendrik Sattler [EMAIL PROTECTED] ha scritto:

 Am Mittwoch 03 Januar 2007 09:53 schrieb Antonio Laterza:
  :( ). If I choose the kernel 2.6.18 X is OK but I am
 not
 
  able to reache many sites. I can navigate very few
 sites
  example: www.google.com and www.mozilla.org. Using
 ethereal
  seems that the HTTP request go out (i.e. GET / )
 but
  the ACK packet does not ask the next packet number 
 in
  other words seems that the GET request never reched the
  final site.
 
 TCP windows scaling comes to mind:
 http://lwn.net/Articles/92727/
 
 HS
Wow!!! Best regards Hendrik!!!
Most probabily the provider's router is buggy but it solved
the problem.
The solution was that reported by article pointed by you:

In the mean time, anybody running a current kernel who is
having trouble connecting to a needed site can work around
the problem with a command like:

echo 0  /proc/sys/net/ipv4/tcp_default_win_scale 

or by adding a line like:

net.ipv4.tcp_default_win_scale = 0

to /etc/sysctl.conf.



anlater
http://studioinglaterza.blogspot.com/


__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 


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

Re: Kernel 2.6.17 and 2.6.18-3-K7 network problem [SOLVED]

[Antonio Laterza]

--- Antonio Laterza [EMAIL PROTECTED] ha scritto:

 Hi all, I posted the question below to debian-user ...
 maybe nobody experienced my same issue. How can I
 contribute to eventually solve? Which other information
 are
 necessary in order to focalize the problem?
 
 
 I want to ask if somebody experienced the same
 problem I have with etch installation and in general with
 kernel 2.6.17 and 2.6.18 on AMD K7. The computer where I
 tried has 2 network cards, I connect only 1 card and it
 receives the IP address.

Hi all, just to report the solution was suggested by
Hendrik Sattler on debian-devel list.
 TCP windows scaling comes to mind:
 http://lwn.net/Articles/92727/
 
 HS
Wow!!! Best regards Hendrik!!!
Most probabily the provider's router is buggy but it solved
the problem.
The solution was that reported by article pointed by you:

In the mean time, anybody running a current kernel who is
having trouble connecting to a needed site can work around
the problem with a command like:

echo 0  /proc/sys/net/ipv4/tcp_default_win_scale 

or by adding a line like:

net.ipv4.tcp_default_win_scale = 0

to /etc/sysctl.conf.



anlater
http://studioinglaterza.blogspot.com/


__
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto 
spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 


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

Re: kernel panic: pivot_root help me

[enerv]

Maybe if you boot using live cd and after that mount your partition and 
edit /sbin/init

and change dev/console for /dev/console.

Ozgur Karatas escreveu:

Hello,
We buy a IBM Blade Server. I choose 2.6 kernel and Grub on Debian 3.1 Sarge 
Setup. But Debian says me Kernel Panic
pivot_root: No such file or directory

 /sbin/init : 432: cannot open dev/console: No such file

 Kernel panic : Attempted to kill init

How to pass it?

--
 ,''`.  Ozgur Karatas
: :' :  [EMAIL PROTECTED]
`. `'   http://www.ozgurkaratas.com
  `-Powered By Debian GNU\Linux


  



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

Re: kernel modules postinst script

[Kel Modderman]

Hi,

Bernd wrote:
 #!/bin/sh
 set -e

 SYSTEMMAP=/boot/System.map-_KVERS_

 if [ -f $SYSTEMMAP ] ; then
 depmod -ae -F $SYSTEMMAP _KVERS_
 elif [ `uname -r` = _KVERS_ ] ; then
 depmod -a 
 fi

As of debhelper 5.0.37, dh_installmodules uses the System.map for the 
target kernel as per template, iirc. No maintainer provided script 
templates are required for this purpose if dh_installmodules is used.


Thanks, Kel.


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

Re: kernel modules postinst script

[Eduard Bloch]

#include hallo.h
* Bernd Schubert [Sat, Jul 22 2006, 03:55:03PM]:
 Hi,
 
 while I just build some kernel module packages for our clients and
 installing them, I think I found a bug applying to almost all kernel module
 packages.
 
 Most packages have a file like postinst.modules.in with something like
 
 #!/bin/sh
 set -e
 
 if [ `uname -r` = _KVERS_ ] ; then
depmod -a 
 fi
 
 Now imagine you are installing the package on a fileserver in a chroot and
 the file servers kernel version is different from _KVERS_. Furthermore, all
 clients mount their root directory read-only from the server.
 So /lib/modules/modules.dep will never be updated.
 
 Why is not something like this used?

Because someone was too stupid, most likely me while creating bad
examples for others. Time for mass-bugfiling, IMO.

Eduard.

 #!/bin/sh
 set -e
 
 SYSTEMMAP=/boot/System.map-_KVERS_
 
 if [ -f $SYSTEMMAP ] ; then
 depmod -ae -F $SYSTEMMAP _KVERS_
 elif [ `uname -r` = _KVERS_ ] ; then
 depmod -a 
 fi
 
 Thanks,
 Bernd
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 

-- 


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

Re: Kernel bootsplash without recompiling

[Jérôme Warnier]

Le mercredi 14 juin 2006 à 13:41 +0200, Paul van der Vlis a écrit :
 Hello,
 
 I don't like the fact that I need to recompile the kernel to get a
 bootsplash. I don't ask for a bootsplash by default, but I would like a
 way to enable it with a standard kernel.
 
 For many many people all these boot-messages are confusing. For me this
 is really an important point in using Debian for normal people.
 
 Is there a good reason not to include the bootsplash?
 
 Who is making the dicision in questions like this?
Linus Torvalds, most probably.
I imagine the code is not judged portable or clean enough to be included
by default in the kernel.

 How can I ask for such a dicision?
Linus Torvalds himself, or the other core kernel hackers.
This is not really a Debian stuff.

Hope it helps

 With regards,
 Paul van der Vlis.
-- 
Jérôme Warnier [EMAIL PROTECTED]
BeezNest

Re: Kernel bootsplash without recompiling

[Paul Wise]

On Wed, 2006-06-14 at 13:41 +0200, Paul van der Vlis wrote:

 I don't like the fact that I need to recompile the kernel to get a
 bootsplash. I don't ask for a bootsplash by default, but I would like a
 way to enable it with a standard kernel.

splashy is a better alternative to the kernel-patch:

http://splashy.alioth.debian.org

It is only in experimental, but it works nicely.

Your other questions were answered by Jérôme Warnier.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Kernel bootsplash without recompiling

[Paul Wise]

On Wed, 2006-06-14 at 19:55 +0800, Paul Wise wrote:

 Your other questions were answered by Jérôme Warnier.

I forgot the following pages related to boot splashscreens:

http://packages.debian.org/unstable/graphics/kernel-patch-bootsplash
http://packages.debian.org/experimental/graphics/splashy
http://packages.debian.org/experimental/graphics/splashy-themes
http://bugs.debian.org/297579
http://bugs.debian.org/356193
http://bugs.debian.org/368828
http://bugs.debian.org/368826
http://bugs.debian.org/188439
http://bugs.debian.org/188440

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Kernel bootsplash without recompiling

[Miriam Ruiz]

gensplash and fbsplash might be an option to consider too:

http://gentoo-wiki.com/HOWTO_fbsplash

Miry


 --- Paul Wise [EMAIL PROTECTED] escribió:

 On Wed, 2006-06-14 at 13:41 +0200, Paul van der Vlis wrote:
 
  I don't like the fact that I need to recompile the kernel to get a
  bootsplash. I don't ask for a bootsplash by default, but I would like a
  way to enable it with a standard kernel.
 
 splashy is a better alternative to the kernel-patch:
 
 http://splashy.alioth.debian.org
 
 It is only in experimental, but it works nicely.
 
 Your other questions were answered by Jérôme Warnier.


__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 


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

Re: Kernel bootsplash without recompiling

[Paul van der Vlis]

Jérôme Warnier schreef:
 Le mercredi 14 juin 2006 à 13:41 +0200, Paul van der Vlis a écrit :
 
Hello,

I don't like the fact that I need to recompile the kernel to get a
bootsplash. I don't ask for a bootsplash by default, but I would like a
way to enable it with a standard kernel.

For many many people all these boot-messages are confusing. For me this
is really an important point in using Debian for normal people.

Is there a good reason not to include the bootsplash?

Who is making the dicision in questions like this?
 
 Linus Torvalds, most probably.

Linux makes dicisions about the kernel, not about the Debian kernel.

Or does Debian have completely no patches to the kernel.org-kernel?

With regards,
Paul van der Vlis.


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

Re: Kernel bootsplash without recompiling

[Paul van der Vlis]

Paul Wise schreef:
 On Wed, 2006-06-14 at 13:41 +0200, Paul van der Vlis wrote:
 
 
I don't like the fact that I need to recompile the kernel to get a
bootsplash. I don't ask for a bootsplash by default, but I would like a
way to enable it with a standard kernel.
 
 
 splashy is a better alternative to the kernel-patch:
 
 http://splashy.alioth.debian.org
 
 It is only in experimental, but it works nicely.

Interesting. This looks like a real user-space splash screen ;-)


With regards,
Paul van der Vlis.


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

Re: Kernel bootsplash without recompiling

[Paul van der Vlis]

Miriam Ruiz schreef:
 gensplash and fbsplash might be an option to consider too:
 
 http://gentoo-wiki.com/HOWTO_fbsplash

Interesting...

From the site: http://dev.gentoo.org/~spock/projects/gensplash/

---
This means that if you don't care about having an image in the
background of your system consoles and all you really want is a progress
bar and a nice picture while (re-)booting the system, you can just use
splashutils and skip everything related to fbsplash, thus making
gensplash a 100% userspace solution. No kernel patches are required in
this case.
---

I think Debian needs something like Splashutils or Splashy..


Thanks,
Paul.


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

Re: Kernel bootsplash without recompiling

[Loïc Minier]

On Wed, Jun 14, 2006, Paul van der Vlis wrote:
 I don't like the fact that I need to recompile the kernel to get a
 bootsplash. I don't ask for a bootsplash by default, but I would like a
 way to enable it with a standard kernel.

 Ubuntu starts Linux with a framebuffer atop of the VGA16 video driver
 and uses usplash in initrd and during system boot to display a boot
 splash screen.  This doesn't need any kernel patch, but might require
 CONFIG_VGA16 to be in the kernel and not as a module.

 In my experience, the VGA16 FB didn't cause any problem, while using
 other drivers was quite risky on configurations running Xorg (garbled
 console when switching from X to tty[1-8]).

-- 
Loïc Minier [EMAIL PROTECTED]


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

Re: Kernel bootsplash without recompiling

[Paul van der Vlis]

Loïc Minier schreef:
 On Wed, Jun 14, 2006, Paul van der Vlis wrote:
 
I don't like the fact that I need to recompile the kernel to get a
bootsplash. I don't ask for a bootsplash by default, but I would like a
way to enable it with a standard kernel.
  
  Ubuntu starts Linux with a framebuffer atop of the VGA16 video driver
  and uses usplash in initrd and during system boot to display a boot
  splash screen.  

OK, interesting.

 This doesn't need any kernel patch, but might require
  CONFIG_VGA16 to be in the kernel and not as a module.

When they use initrd, I think a module is OK.

  In my experience, the VGA16 FB didn't cause any problem, while using
  other drivers was quite risky on configurations running Xorg (garbled
  console when switching from X to tty[1-8]).

Thanks for your info.

With regards,
Paul van der Vlis.



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

Re: Kernel compile fails.

[Linas Zvirblis]

Alejandro Bonilla Beeche wrote:

   I have a box with Sid with the latest upgrades, (almost cause 
dist-upgrade wants to remove a lot of stuff)


Anyway, fact is that I can't compile any kernel on the Linus tree. This, 
for more than a month.


Could anyone please help me find out which package is the broken one? 
/bin/sh in Bash.


I accidentally replied this to debian-user, but it actually belongs 
there. This is breakage in kernel, not Debian.



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

Re: kernel-package hooks transition

[Bernhard R. Link]

* Colin Watson [EMAIL PROTECTED] [051224 18:30]:
 The fd 3 redirection (and the corresponding redirection of stdout to
 stderr in the shell confmodule) was always acknowledged as a nasty hack
 in debconf. At the time, as I understand it, Joey reckoned it was easier
 to do that than to try to get everyone to change maintainer script code
 that used stdout. 

It may be an ugly hack, but I think it was predictable that it was
necessary. (postinst is quite an complex thing to expect widely used
things like stdin and stdout to be secure to use).

 It has various undesirable consequences, such as the
 requirement to call db_stop before starting daemons that don't take care
 to close down all their file descriptors,

Hopefully people will not only call db_stop, but also fix the buggy
daemon. (And I almost consider this a good consequence, as it makes it a
bit easier to find buggy code, even security-relvant buggy code)

 and some very weird
 workarounds in the confmodule bindings for other languages (see the
 changelog entry for debconf 0.3.74).

That is more a problem of inconsistency. I never understood why those
scripts are not called debconf communication at fds 3 and 4. (and put
/dev/null in stdin and something else to avoi things reading from it)
This way only buggy daemons would cause problems. (and beside fd_stop, 
just give them 3/dev/null to work around)

Hochachtungsvoll,
  Bernhard R. Link


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

Re: kernel-package hooks transition

[Sven Luther]

On Sun, Dec 25, 2005 at 01:50:35PM -0800, Steve Langasek wrote:
 On Sun, Dec 25, 2005 at 03:34:43PM +, Colin Watson wrote:
  The STOP command causes the debconf frontend to shut down; that would
  certainly break anything trying to talk to debconf after it. May be
  worth removing that and seeing if things start working.
 
  I haven't checked if kernel-package runs anything else that would
  require it to use STOP. It seems a little unlikely that it would be
  starting up any daemons, though. Note a common misconception: the STOP
  command does *not* put your file descriptors back the way they were
  before you started the debconf frontend.
 
 Indeed, not only does STOP not restore your file descriptors, it also leaves
 a sentinel value in the environment which prevents debconf-using children
 from successfully restarting the frontend.  STOP should only be used when
 you need to force-kill the frontend because of other processes that will
 otherwise leave dangling file descriptors open to it after your scripts
 exit.

Ok, then this is probably the root of the problem here.

Kernel-package does call db_stop, before calling the hooks, since it has no
guarantee that the hooks will behave properly.

I understand that the intention of Manoj was to restore the file descriptors
in order to have hooks like grub-update be able to send output to stdout, not
for the other reason Colin mentioned, having to deal with daemons. Colin could
you giive a bit more detail on how this daemon trick works and what the issue
is ? Is it possible that a random kernel hook would be starting such a daemon
? right now i don't think this is done, nor is it the job of the kernel hooks,
but one never knows, and i believe this has to be properly documented in the
kernel-package documentation.

Friendly,

Sven Luther


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

Re: kernel-package hooks transition

[Manoj Srivastava]

On Mon, 26 Dec 2005 10:45:52 +0100, Sven Luther [EMAIL PROTECTED] said: 

 Ok, then this is probably the root of the problem here.

 Kernel-package does call db_stop, before calling the hooks, since it
 has no guarantee that the hooks will behave properly.

Past tense. This has not been the case for a couple of uploads
of kernel-package now.

 I understand that the intention of Manoj was to restore the file
 descriptors in order to have hooks like grub-update be able to send
 output to stdout, not for the other reason Colin mentioned, having
 to deal with daemons. Colin could you giive a bit more detail on how
 this daemon trick works and what the issue is ?

Is this not flogging a dead horse?

 Is it possible that a random kernel hook would be starting such a
 daemon ? right now i don't think this is done, nor is it the job of
 the kernel hooks, but one never knows, and i believe this has to be
 properly documented in the kernel-package documentation.

I see no reason to restrict a hook script from starting a
 daemon, but that is neither here nor there.

manoj
-- 
We don't need no education, we don't need no thought control. Pink
Floyd
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: kernel-package hooks transition

[Colin Watson]

On Sun, Dec 25, 2005 at 01:43:19AM +0100, Sven Luther wrote:
 On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
  On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
   Notice that the debconf helper scripts provide stdout on 3, so any
   scripts writing to stdout only need to redirect their output to 3, no
   ? 
  
  No, that won't work; if you send something to fd 3, it will go to the
  debconf frontend and be interpreted as a debconf protocol command. In
 
 Well, you are the expert, i said this, because the
 /usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by
 debconf-devel says :
 
 # Redirect standard output to standard error. This prevents common
 # mistakes by making all the output of the postinst or whatever
 # script is using this library not be parsed as confmodule commands.
 #
 # To actually send something to standard output, send it to fd 3.
 
 which i read that 1 goes to debconf and 3 to stdout normally. But then i am
 largely out of my depth here, and would greatly greatly appreciate someone
 with a real clue (you or joeyh being likely candidates here :) to have a look
 at this issue.

I already described the real behaviour in my previous mail. The comment
above is certainly a bit confusing, but it's trying to say that fd 3
goes to the standard output of the confmodule *after* the frontend has
been started up. At that point, the confmodule's stdout is connected to
the frontend.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: kernel-package hooks transition

[Colin Watson]

On Sun, Dec 25, 2005 at 01:51:00AM +0100, Sven Luther wrote:
 On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
  On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
   Notice that the debconf helper scripts provide stdout on 3, so any
   scripts writing to stdout only need to redirect their output to 3, no
 
  My impression is that these days maintainer scripts are much better
  about not mixing up debconf interaction with normal use of stdout, and
  so it's still possible that the fd 3 hack will be removed some day.
 
 Ok, now i read it all, shouldn't really be replying to email after the
 christmas party ... :)

Likewise, on Christmas Day I haven't really looked at this issue in any
depth. :-)

 So, do you have any idea of what is going wrong here and how to fix it ? I
 mean having hosed powerpc kernels over christmas is really not the nicest
 thing to have happen, and i really don't understand the subtleties of what is
 going on here.
 
 k-p uses debconf (probably using the perl helpers you mentioned), and does a
 db_stop before calling the script hooks.

The STOP command causes the debconf frontend to shut down; that would
certainly break anything trying to talk to debconf after it. May be
worth removing that and seeing if things start working.

I haven't checked if kernel-package runs anything else that would
require it to use STOP. It seems a little unlikely that it would be
starting up any daemons, though. Note a common misconception: the STOP
command does *not* put your file descriptors back the way they were
before you started the debconf frontend.

 The script hooks, of which only mkvmlinuz uses debconf, but using debconf
 being the right thing to do probably given the debconf-related policy, so the
 script hooks calls debconf itself, which checks that debconf is not yet
 running and reruns it if not.

While it's correct for your hooks to load an appropriate debconf
confmodule library (/usr/share/debconf/confmodule, in your case), the
check you mention only works if the debconf frontend has never been
started. It won't notice that you've shut the frontend down with STOP in
the meantime. debconf isn't designed to be repeatedly shut down and
started up again in the same process.

 My belief is that somehow there is an inconsistency in the debconf helper,
 maybe in the interaction of the perl debconf helper and especially the perl
 db_stop, with the shell debconf helper. Can this be ? 

It's certainly possible, although those particular two confmodule
libraries are fairly well-tested and I think other things use them that
way round. I'd try removing the STOP command first.

 Do we have some kind of documented spec of how these helpers do handle the
 debconf interaction, or something, which would enable to investigate this
 issue without lengthy error-and-trial ?

debconf-devel(7) documents a lot of it here and there, but it's not
really in the form of a strict design document or anything.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: kernel-package hooks transition

[Steve Langasek]

On Sun, Dec 25, 2005 at 03:34:43PM +, Colin Watson wrote:
 On Sun, Dec 25, 2005 at 01:51:00AM +0100, Sven Luther wrote:
  On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
   On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
Notice that the debconf helper scripts provide stdout on 3, so any
scripts writing to stdout only need to redirect their output to 3, no

   My impression is that these days maintainer scripts are much better
   about not mixing up debconf interaction with normal use of stdout, and
   so it's still possible that the fd 3 hack will be removed some day.

  Ok, now i read it all, shouldn't really be replying to email after the
  christmas party ... :)

 Likewise, on Christmas Day I haven't really looked at this issue in any
 depth. :-)

  So, do you have any idea of what is going wrong here and how to fix it ? I
  mean having hosed powerpc kernels over christmas is really not the nicest
  thing to have happen, and i really don't understand the subtleties of what 
  is
  going on here.

  k-p uses debconf (probably using the perl helpers you mentioned), and does a
  db_stop before calling the script hooks.

 The STOP command causes the debconf frontend to shut down; that would
 certainly break anything trying to talk to debconf after it. May be
 worth removing that and seeing if things start working.

 I haven't checked if kernel-package runs anything else that would
 require it to use STOP. It seems a little unlikely that it would be
 starting up any daemons, though. Note a common misconception: the STOP
 command does *not* put your file descriptors back the way they were
 before you started the debconf frontend.

Indeed, not only does STOP not restore your file descriptors, it also leaves
a sentinel value in the environment which prevents debconf-using children
from successfully restarting the frontend.  STOP should only be used when
you need to force-kill the frontend because of other processes that will
otherwise leave dangling file descriptors open to it after your scripts
exit.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 09:19:36AM -0600, Manoj Srivastava wrote:
 Hi,
 
 In the recent 10.X series, kernel package has started
  producing image packages whose maintainer scripts use debconf for
  user interaction.  Unfortunately, this meant that any hook scripts
  called in the maintainer scripts for the image package (update-grub
  comes to mind), if they wrote anything at all to the STDout, would
  cause debconf to throw hissy fits, since it was expecting commands on
  STDOUT, not random chatter from the hook scripts.
 
 One solution was to call db_stop before calling the hook
  scripts, and redirecting stdout to stderr  in hte invocation of the
  scripts. Unfortunately, this made any scripts that used debconf
  impossible.

Notice that the debconf helper scripts provide stdout on 3, so any scripts
writing to stdout only need to redirect their output to 3, no ? 

Another idea would be to have some tag or something to declare if the script
uses debconf or not, and to do the redirection depending on that ? It could be
parsing for something like :

comment delimiter KPKG-TAG: debconf

(where comment delimiter is # for shell scripts, obviously).

This would allow for the most flexibility, and still work out fine, and
parsing would be a simple grep command, so rather cheap (if grep
KPKG-TAG.*debconf; then debconf stuff; else non-debconf stuff; fi)

Oh and BTW, 10.023 did not fix the mkvmlinuz problem, not sure if you saw me
reopening the bug reports. I will try to investigate this on tuesday, altough
i am really lost about this and help will be welcomed.

For powerpc users, a workaround is to remove the debconf stuff by hand. There
are two scripts : 

/etc/kernel/postinst.d/mkvmlinuz and /etc/kernel/prerm.d/mkvmlinuz

And the best way is to replace the lines : 

  . /usr/share/debconf/confmodule

  db_get mkvmlinuz/bootloaders
  bootloader=$RET

by :

  bootloader=your_choice

Where your_choice is yaboot on pmac and rs6k, and mkvmlinuz otherwise.

Friendly,

Sven Luther


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

Re: kernel-package hooks transition

[Colin Watson]

On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
 Notice that the debconf helper scripts provide stdout on 3, so any
 scripts writing to stdout only need to redirect their output to 3, no
 ? 

No, that won't work; if you send something to fd 3, it will go to the
debconf frontend and be interpreted as a debconf protocol command. In
any case, it's only the shell confmodule that sets up fd 3 to go to the
frontend, and the kernel-package-generated postinst is written in Perl;
people may well have written postinst.d fragments in Perl too. Please
use stderr instead, or, if possible, just make the script quiet.

The fd 3 redirection (and the corresponding redirection of stdout to
stderr in the shell confmodule) was always acknowledged as a nasty hack
in debconf. At the time, as I understand it, Joey reckoned it was easier
to do that than to try to get everyone to change maintainer script code
that used stdout. It has various undesirable consequences, such as the
requirement to call db_stop before starting daemons that don't take care
to close down all their file descriptors, and some very weird
workarounds in the confmodule bindings for other languages (see the
changelog entry for debconf 0.3.74).

My impression is that these days maintainer scripts are much better
about not mixing up debconf interaction with normal use of stdout, and
so it's still possible that the fd 3 hack will be removed some day.

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
 On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
  Notice that the debconf helper scripts provide stdout on 3, so any
  scripts writing to stdout only need to redirect their output to 3, no
  ? 
 
 No, that won't work; if you send something to fd 3, it will go to the
 debconf frontend and be interpreted as a debconf protocol command. In

Well, you are the expert, i said this, because the
/usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by
debconf-devel says :

# Redirect standard output to standard error. This prevents common
# mistakes by making all the output of the postinst or whatever
# script is using this library not be parsed as confmodule commands.
#
# To actually send something to standard output, send it to fd 3.

which i read that 1 goes to debconf and 3 to stdout normally. But then i am
largely out of my depth here, and would greatly greatly appreciate someone
with a real clue (you or joeyh being likely candidates here :) to have a look
at this issue. Mmm, need to go and read the rest of your mail really, ...

Friendly,

Sven Luther


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

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
 On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
  Notice that the debconf helper scripts provide stdout on 3, so any
  scripts writing to stdout only need to redirect their output to 3, no

 My impression is that these days maintainer scripts are much better
 about not mixing up debconf interaction with normal use of stdout, and
 so it's still possible that the fd 3 hack will be removed some day.

Ok, now i read it all, shouldn't really be replying to email after the
christmas party ... :)

So, do you have any idea of what is going wrong here and how to fix it ? I
mean having hosed powerpc kernels over christmas is really not the nicest
thing to have happen, and i really don't understand the subtleties of what is
going on here.

k-p uses debconf (probably using the perl helpers you mentioned), and does a
db_stop before calling the script hooks.

The script hooks, of which only mkvmlinuz uses debconf, but using debconf
being the right thing to do probably given the debconf-related policy, so the
script hooks calls debconf itself, which checks that debconf is not yet
running and reruns it if not.

My belief is that somehow there is an inconsistency in the debconf helper,
maybe in the interaction of the perl debconf helper and especially the perl
db_stop, with the shell debconf helper. Can this be ? 

Do we have some kind of documented spec of how these helpers do handle the
debconf interaction, or something, which would enable to investigate this
issue without lengthy error-and-trial ?

Friendly,

Sven Luther


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

Re: kernel-package hooks transition

[Sven Luther]

On Sat, Dec 24, 2005 at 05:30:26PM +, Colin Watson wrote:
 On Sat, Dec 24, 2005 at 05:03:17PM +0100, Sven Luther wrote:
  Notice that the debconf helper scripts provide stdout on 3, so any
  scripts writing to stdout only need to redirect their output to 3, no
  ? 
 
 No, that won't work; if you send something to fd 3, it will go to the
 debconf frontend and be interpreted as a debconf protocol command. In
 any case, it's only the shell confmodule that sets up fd 3 to go to the
 frontend, and the kernel-package-generated postinst is written in Perl;
 people may well have written postinst.d fragments in Perl too. Please
 use stderr instead, or, if possible, just make the script quiet.

Oh, and merry christmas to you and thanks for your help in replying to this
even on christmas eve's, ok off to bed now.

Friendly,

Sven Luther


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

Re: kernel-package hooks transition

[Adam Heath]

On Sun, 25 Dec 2005, Sven Luther wrote:

 Well, you are the expert, i said this, because the
 /usr/share/debconf/confmodule script i use in mkvmlinuz and recomended by
 debconf-devel says :

 # Redirect standard output to standard error. This prevents common
 # mistakes by making all the output of the postinst or whatever
 # script is using this library not be parsed as confmodule commands.
 #
 # To actually send something to standard output, send it to fd 3.

 which i read that 1 goes to debconf and 3 to stdout normally. But then i am
 largely out of my depth here, and would greatly greatly appreciate someone
 with a real clue (you or joeyh being likely candidates here :) to have a look
 at this issue. Mmm, need to go and read the rest of your mail really, ...

No, that says 1 goes to 2, 3 goes to stdout, and stdout is connected to
debconf.

I bet you'll find the debconf commands sending data to 3.


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

Re: kernel 2.6.14

[Andrew Vaughan]

Hi
On Thu, 15 Dec 2005 22:34, Richard Fojta wrote:
 Hi,
 I've recently try to install new kernel. Somethings go wrong and I cannot
 found solution. There is some problem with configuration. It seems to me,
 that this problem is not unique. Does anybody know how to solve ti?

[This is probably more appropriate for -users, attempting to move there. 
Reply to set to debian-user@lists.debian.org, Richard Fojta [EMAIL PROTECTED] 
Bcc-ed to -devel]

You don't give enough info be sure, but this sounds like it might be the same 
problem. 

On Thu, 15 Dec 2005 06:18, Andrei Popescu wrote:
 [EMAIL PROTECTED] wrote:
  Today I upgraded my system.
 
  It wouldn’t boot up. Instead it give me this error:
 
  Waiting 2 seconds /sys/block/hda/dev to show up.
 
  /bin/cat:/sys/block/hda/dev: no such file or directory.
 
  Is this fixable or do I have to set up my complete system again? Hope
  not.
 
  Pascal.

 Here is what worked for me:

 http://lists.debian.org/debian-user/2005/12/msg01408.html
 http://lists.debian.org/debian-user/2005/12/msg01406.html

 post your steps if you get stuck

 Andrei

HTH 
Andrew V.

Re: kernel 2.6.14

[Zejn Gasper]

I've had the same experience yesterday, i didn't have time, so i downgraded to 
2.6.12.

But there's something wrong with the kernel.

Greetings, 
Gasper Zejn

On Thursday 15 of December 2005 13:23, Andrew Vaughan wrote:
 Hi

 On Thu, 15 Dec 2005 22:34, Richard Fojta wrote:
  Hi,
  I've recently try to install new kernel. Somethings go wrong and I cannot
  found solution. There is some problem with configuration. It seems to me,
  that this problem is not unique. Does anybody know how to solve ti?

 [This is probably more appropriate for -users, attempting to move there.
 Reply to set to debian-user@lists.debian.org, Richard Fojta
 [EMAIL PROTECTED] Bcc-ed to -devel]

 You don't give enough info be sure, but this sounds like it might be the
 same problem.

 On Thu, 15 Dec 2005 06:18, Andrei Popescu wrote:
  [EMAIL PROTECTED] wrote:
   Today I upgraded my system.
  
   It wouldn’t boot up. Instead it give me this error:
  
   Waiting 2 seconds /sys/block/hda/dev to show up.
  
   /bin/cat:/sys/block/hda/dev: no such file or directory.
  
   Is this fixable or do I have to set up my complete system again? Hope
   not.
  
   Pascal.
 
  Here is what worked for me:
 
  http://lists.debian.org/debian-user/2005/12/msg01408.html
  http://lists.debian.org/debian-user/2005/12/msg01406.html
 
  post your steps if you get stuck
 
  Andrei

 HTH
 Andrew V.

Re: kernel 2.6.14

[Agustin Martin]

On Thu, Dec 15, 2005 at 03:16:52PM +0100, Zejn Gasper wrote:
 I've had the same experience yesterday, i didn't have time, so i downgraded 
 to 
 2.6.12.
 
 But there's something wrong with the kernel.

Others wrote:

 
  Waiting 2 seconds /sys/block/hda/dev to show up.
 
  /bin/cat:/sys/block/hda/dev: no such file or directory.

Before new bug reports are filed,

linux-image-2.6:

http://bugs.debian.org/343048
http://bugs.debian.org/343443

yaird:

http://bugs.debian.org/343042
http://bugs.debian.org/343280

First one for each package has a lot of information

-- 
Agustin


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

Re: Kernel Linux

[Rogelio Dominguez Hernandez]

On Thu, Nov 24, 2005 at 11:00:42PM +0100, Jose wrote:
 Hola a todos,
 
Estoy muy interesado en el kernel de Linux y querría empezar a 
 mirarme como está desarrollado, pero no me atrevo con tanto fuente, 
 ¿conocéis alguna página, libro, donde explique como está desarrollado, 
 y te vaya introduciendo en él de una manera un poco más suave?
 

2 libros muy recientes y que cubren el kernel 2.6:

-Linux Kernel Development, 2nd Edition
 Robert Love

-Linux Device Drivers, 3rd Edition
 Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman
 En PDF: http://lwn.net/Kernel/LDD3/

3 libros sobre el 2.4

-Understanding the Linux Kernel
 Daniel P. Bovet, Marco Cesati

-The Linux Process Manager
 John O'Gorman

-Understanding the Linux Virtual Memory Manager
 Mel Gorman
 En PDF:
 http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/understand.pdf

Este �ltimo contiene un ap�ndice en cada cap�tulo con los cambios que
se realizaron para el 2.6.


signature.asc
Description: Digital signature

Re: Kernel Linux

[Rudy Godoy]

El d�a 24/11/2005 a 23:20 Jose escribi�...

 Hola a todos,
 
Estoy muy interesado en el kernel de Linux y querría empezar a 
 mirarme como está desarrollado, pero no me atrevo con tanto fuente, 
 ¿conocéis alguna página, libro, donde explique como está desarrollado, 
 y te vaya introduciendo en él de una manera un poco más suave?
 

http://kernelnewbies.org hay un enlace a la secci�n en espa�ol (ahora
no puedo acceder por eso no te doy el url exacto).

-Rudy

-- 
Rudy Godoy | 0x3433BD21 | http://stone-head.org   ,''`.
http://www.apesol.org  -  http://www.debian.org  : :' :
GPG FP: 0D12 8537 607E 2DF5 4EFB  35A7 550F 1A00 3433 BD21   `. `'
   `-


signature.asc
Description: Digital signature

Re: kernel security bug #307900

[Holger Levsen]

Hi,

On Friday 10 June 2005 04:02, Adam Majer wrote:
   woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
  condition.
  Will this be fixed for Woody?
  I thought the plan was to provide security support for Woody for
  another year?
 AFAIK, there is no security support for Woody kernels for some time now.
 Use kernel.org and compile your kernels for security sensitive machines.

If this is true, this should be properly documented somewhere.


regards,
Holger


pgpRtFFh6zwaN.pgp
Description: PGP signature

Re: kernel security bug #307900

[Olaf van der Spek]

Adam Majer wrote:

Olaf van der Spek wrote:



woody's kernels are vulnerable to CAN-2004-1235, a uselib() race


condition.

Will this be fixed for Woody?
I thought the plan was to provide security support for Woody for
another year?




AFAIK, there is no security support for Woody kernels for some time now.
Use kernel.org and compile your kernels for security sensitive machines.


What's the reason for this lack of support?


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

Re: kernel security bug #307900

[Adam Majer]

Olaf van der Spek wrote:

 Adam Majer wrote:

 AFAIK, there is no security support for Woody kernels for some time now.
 Use kernel.org and compile your kernels for security sensitive machines.


 What's the reason for this lack of support?


I think after Herbert Xu left so did security updates for Woody's kernel,
http://www.mailarchives.org/list/debian-security-announce/msg/2005/00216

- Adam


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

Re: Re: kernel security bug #307900

[Olaf van der Spek]

 woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
condition.

Will this be fixed for Woody?
I thought the plan was to provide security support for Woody for another 
year?

--
Olaf van der Spek
http://xccu.sf.net/


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

Re: kernel security bug #307900

[Adam Majer]

Olaf van der Spek wrote:

  woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
 condition.

 Will this be fixed for Woody?
 I thought the plan was to provide security support for Woody for
 another year?


AFAIK, there is no security support for Woody kernels for some time now.
Use kernel.org and compile your kernels for security sensitive machines.

- Adam



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

Re: kernel security bug #307900

[Hamish Moffatt]

On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote:
 As far as I can tell from reading the bug report, the bug has not been
 fixed in sarge, will not be fixed for the release, but the bug has
 been closed.
 
 Have we come to the point where making a release is more important
 then fixing known security bugs?
 
 Does this mean people who want secure pre-compiled kernels have to
 resort to unstable until the issue is fixed?

woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
condition. The bug became public in January. I emailed [EMAIL PROTECTED]
after I got hacked last month, but there was no reply.


Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: kernel security bug #307900

[Steve Langasek]

On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote:
 Whats the deal with bug #307900?

 As far as I can tell from reading the bug report, the bug has not been
 fixed in sarge, will not be fixed for the release, but the bug has
 been closed.

kernel-source-2.6.8 2.6.8-15 has been in testing for some time now.

kernel-image packages built against 2.6.8-16 are available in sarge for the
past week or so for i386, alpha, and ia64.

kernel-image packages built against 2.6.8-15 are also available in sarge for
sparc; the amd64 kernels for the i386 architecture are also built against
this revision.  There are further security fixes in -16, so these images
should be rebuilt, but they include the fix for 307900.

Fixed kernel-image packages were not available for the other architectures
prior to the freeze, so will need to be handled via security.debian.org.
However, AIUI the exploit that exists in the wild for this hole is
i386-specific (please correct me if I'm wrong).

In light of the announcement at the beginning of May that sarge is
security-supported, I think it would be a good idea for any DSAs issued over
these holes to include mention of the relevant kernel versions for i386
etc., so that users who have upgraded earlier know that they need to upgrade
and reboot.

Most of the architectures that are still shipping unfixed 2.6.8 kernels in
sarge are outside the purview of the kernel team AIUI, so it may take a bit
of time to get packages synced up for a DSA.

 Have we come to the point where making a release is more important
 then fixing known security bugs?

What is known is that new security holes that affect sarge have been
appearing on a roughly weekly basis, and new security holes affecting the
kernel are being reported on a roughly monthly basis.  You can't get to a
release with no known security holes using those kinds of numbers; you can
pick and choose *which* security fixes you think are important enough to
wait on, but we just don't have the kind of turnaround on fixes to be able
to foresee a point where we can say that no package, anywhere in sarge, has
a known security hole.

 Does this mean people who want secure pre-compiled kernels have to
 resort to unstable until the issue is fixed?

Currently, unstable is in the same state as sarge wrt kernel security.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: kernel security bug #307900

[Brian May]

 Steve == Steve Langasek [EMAIL PROTECTED] writes:

Steve kernel-image packages built against 2.6.8-16 are available
Steve in sarge for the past week or so for i386, alpha, and ia64.

[...]

Steve In light of the announcement at the beginning of May that
Steve sarge is security-supported, I think it would be a good
Steve idea for any DSAs issued over these holes to include
Steve mention of the relevant kernel versions for i386 etc., so
Steve that users who have upgraded earlier know that they need to
Steve upgrade and reboot.

I think it would also be a good idea if the change log in the
kernel-image package could mention any DSAs fixed...

The changelog I have says:

--- cut ---
kernel-image-2.6.8-i386 (2.6.8-16) unstable; urgency=low

  * Fix up AMD descriptions to include CPU name.
Thanks to J. Grant. (Simon Horman)
  * Removed for those who want the latest ... from header
package descriptons as this is what packages from
kernel-latest-2.6-i386 do. (Simon Horman)
  * Build against kernel-tree-2.6.8-16. (Simon Horman)
  * Add myself as an uploader. (Simon Horman)

 -- Simon Horman [EMAIL PROTECTED]  Thu, 19 May 2005 16:52:19 +0900

kernel-image-2.6.8-i386 (2.6.8-15) unstable; urgency=high

  * Build against 2.6.8-15.

 -- Andres Salomon [EMAIL PROTECTED]  Tue, 22 Mar 2005 12:39:59 -0500
--- cut ---

This still leaves me confused if it fixed the problem or not.

I guess I am expected to cross reference this with the changelog of
the kernel-source package.

What is the kernel-tree-2.6.8-16 package? Or is this an abbreviation
for kernel-tree-2.6.8 version 2.6.8-16? Does this imply
kernel-source version 2.6.8-16?

Again, I think it would be much quicker, easier, and less prone to
errors if the DSAs where mentioned in the relevant kernel-image-change
too.
-- 
Brian May [EMAIL PROTECTED]


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

Re: kernel security bug #307900

[Steve Langasek]

On Mon, Jun 06, 2005 at 08:28:17AM +1000, Brian May wrote:
  Steve == Steve Langasek [EMAIL PROTECTED] writes:

 Steve kernel-image packages built against 2.6.8-16 are available
 Steve in sarge for the past week or so for i386, alpha, and ia64.

 [...]

 Steve In light of the announcement at the beginning of May that
 Steve sarge is security-supported, I think it would be a good
 Steve idea for any DSAs issued over these holes to include
 Steve mention of the relevant kernel versions for i386 etc., so
 Steve that users who have upgraded earlier know that they need to
 Steve upgrade and reboot.

 I think it would also be a good idea if the change log in the
 kernel-image package could mention any DSAs fixed...

 The changelog I have says:

 --- cut ---

 I guess I am expected to cross reference this with the changelog of
 the kernel-source package.

Yeah, at this point that's the process.

 What is the kernel-tree-2.6.8-16 package? Or is this an abbreviation
 for kernel-tree-2.6.8 version 2.6.8-16? Does this imply
 kernel-source version 2.6.8-16?

$ apt-cache show kernel-tree-2.6.8
Package: kernel-tree-2.6.8
Priority: optional
Section: devel
Installed-Size: 56
Maintainer: Debian kernel team debian-kernel@lists.debian.org
Architecture: all
Source: kernel-source-2.6.8
Version: 2.6.8-16
Provides: kernel-tree-2.6.8-1, kernel-tree-2.6.8-10, kernel-tree-2.6.8-11, 
kernel-tree-2.6.8-12, kernel-tree-2.6.8-13, kernel-tree-2.6.8-14, 
kernel-tree-2.6.8-15, kernel-tree-2.6.8-16, kernel-tree-2.6.8-2, 
kernel-tree-2.6.8-3, kernel-tree-2.6.8-4, kernel-tree-2.6.8-5, 
kernel-tree-2.6.8-6, kernel-tree-2.6.8-7, kernel-tree-2.6.8-8, 
kernel-tree-2.6.8-9
Depends: kernel-patch-debian-2.6.8 (= 2.6.8-16), kernel-source-2.6.8 (= 
2.6.8-1) | kernel-source-2.6.8 (= 2.6.8-10) | kernel-source-2.6.8 (= 2.6.8-11) 
| kernel-source-2.6.8 (= 2.6.8-12) | kernel-source-2.6.8 (= 2.6.8-13) | 
kernel-source-2.6.8 (= 2.6.8-14) | kernel-source-2.6.8 (= 2.6.8-15) | 
kernel-source-2.6.8 (= 2.6.8-16) | kernel-source-2.6.8 (= 2.6.8-2) | 
kernel-source-2.6.8 (= 2.6.8-3) | kernel-source-2.6.8 (= 2.6.8-4) | 
kernel-source-2.6.8 (= 2.6.8-5) | kernel-source-2.6.8 (= 2.6.8-6) | 
kernel-source-2.6.8 (= 2.6.8-7) | kernel-source-2.6.8 (= 2.6.8-8) | 
kernel-source-2.6.8 (= 2.6.8-9)
snip

 Again, I think it would be much quicker, easier, and less prone to
 errors if the DSAs where mentioned in the relevant kernel-image-change
 too.

It would be prone to errors from kernel-image uploaders who aren't actually
keeping track of what has been fixed in the kernel source; at least if
there's an expectation that you have to look at the kernel-source, you
always know where you stand.  You could try cooking up some magic to
automatically incorporate particular changelog snippets in kernel-image, but
there's also the possibility of arch-specific security issues, so...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Kernel version 100

[Norbert Tretkowski]

* Ladislav Bodnar wrote:
 Just curious: any particular reason why the kernel version is reported 
 as 100 on http://packages.debian.org/unstable/allpackages?

 kernel-image-2.6-386 (100)
 Linux kernel image for version 2.6 on 386.

This is just a meta-package, which depends on the latest 2.6 kernel
available.

Norbert

Re: Kernel version 100

[Ladislav Bodnar]

On Tuesday 26 October 2004 22:15, Norbert Tretkowski wrote:
  Just curious: any particular reason why the kernel version is
  reported as 100 on
  http://packages.debian.org/unstable/allpackages?
 
  kernel-image-2.6-386 (100)
      Linux kernel image for version 2.6 on 386.

 This is just a meta-package, which depends on the latest 2.6 kernel
 available.

Yes, but it used to have a proper version number in the parenthesis not 
so long ago. Why the sudden change?

Ladislav

Re: Kernel version 100

[Thiemo Seufer]

Ladislav Bodnar wrote:
 On Tuesday 26 October 2004 22:15, Norbert Tretkowski wrote:
   Just curious: any particular reason why the kernel version is
   reported as 100 on
   http://packages.debian.org/unstable/allpackages?
  
   kernel-image-2.6-386 (100)
       Linux kernel image for version 2.6 on 386.
 
  This is just a meta-package, which depends on the latest 2.6 kernel
  available.
 
 Yes, but it used to have a proper version number in the parenthesis not 
 so long ago.

100 is also a proper version number.

 Why the sudden change?

The way the metapackage was built changed, so the version number was
increased by an arbitrary amount.


Thiemo

Re: kernel update takes out nvidia drivers

[Carl B. Constantine]

* Carl B. Constantine ([EMAIL PROTECTED]) wrote:
 I just did an update on my system. it updated my kernel to a newer
 version of the same kernel. It also updated all the nvidia packages. But
 X no longer works. Even though the nvidia packages are installed, the
 drivers do not work, the kernel module doesn't load. 
 
 So I tried running the nvidia-installer program to re-wrap the
 compiled nvidia binary to the new kernel (which should have been done by
 the package maintainer IMHO) and it informs me I need the kernel source. 
 
 I installed the kernel source and the nvidia-install program STILL tells
 me I need the kernel source or headers.
 
 Anyone have ideas on how to fix? I have no X at all now :-(

Nevermind, I installed the headers instead and that worked. However, why
it happened in the first place is puzzling to me. If I update all the
nvidia packages with the kernel image, why doesn't it just work? Why do
I need to re-run nvidia's installer program? It doesn't make sense to
me.

-- 
 .''`.  Carl B. Constantine
: :' : [EMAIL PROTECTED]
`. `'GnuPG: 135F FC30 7A02 B0EB 61DB  34E3 3AF1 DC6C 9F7A 3FF8
  `-  Debian GNU/Linux -- The power of freedom
  Claiming that your operating system is the best in the world because more
  people use it is like saying McDonalds makes the best food in the world.

Re: kernel update takes out nvidia drivers

[Guglielmo Dapavo]

Carl B. Constantine wrote:
* Carl B. Constantine ([EMAIL PROTECTED]) wrote:
 

I just did an update on my system. it updated my kernel to a newer
version of the same kernel. It also updated all the nvidia packages. But
X no longer works. Even though the nvidia packages are installed, the
drivers do not work, the kernel module doesn't load.
I think you are in the wrong mlist, the place to ask these kind of 
question is debian-country

having nvidia packages installed doesn't mean that the module is 
included in every new kernel, when you  download a new kernel you have 
to compile them, they are not included cause they are not free software 
or even open source.

So I tried running the nvidia-installer program to re-wrap the
compiled nvidia binary to the new kernel (which should have been done by
the package maintainer IMHO) and it informs me I need the kernel source. 

I installed the kernel source and the nvidia-install program STILL tells
me I need the kernel source or headers.
   

header files are ready for compiling kernel modules, there is an header 
package for every kernel image, kernel source must be prepeared for 
every  kernel image.

Anyone have ideas on how to fix? I have no X at all now :-(
   

Nevermind, I installed the headers instead and that worked. However, why
it happened in the first place is puzzling to me. If I update all the
nvidia packages with the kernel image, why doesn't it just work? Why do
I need to re-run nvidia's installer program? It doesn't make sense to
me.
 

Yes it make sense cause Debian developers doesn't want to include non 
free software in a kernel release, but Debian gives u the possibility to 
compile a module by yourself.

--
Guglielmo Dapavo

Re: Kernel 2.4.18 and GCC 3.3 (not a good mix)

[Rob Weir]

On Sat, Dec 06, 2003 at 05:05:02AM +0100, smurfd said
 Seems that gcc 3.3 and kernel 2.4.18 (with grsec patch) dont like
 eachother.

Yes, this is a well-known problem.  Use gcc 2.95.4 (which is still the
recommended compiler for 2.4, anyway) or upgrade to 2.4.23.  Also,
2.4.18 has at least two local root holes, one of which is not stopped by
grsecurity.

-- 
Rob Weir [EMAIL PROTECTED] | [EMAIL PROTECTED]  |  Do I look like I want a CC?
Words of the day:   enforcers enforcers tempest investigation Defcon Peking MDA


signature.asc
Description: Digital signature

Re: kernel-patch-acl

[Christoph Hellwig]

On Fri, Dec 05, 2003 at 01:58:27PM +1100, Russell Coker wrote:
 Much of this patch is scheduled to be included in 2.4.24, so the work 
 required 
Who claims that? 

Re: kernel-patch-acl

[Herbert Xu]

On Fri, Dec 05, 2003 at 01:58:27PM +1100, Russell Coker wrote:
 Herbert, would it be possible to get the ACL kernel patch included in the 
 Debian kernel source?

I'm afraid that you've missed boat for 2.4.23.  I'll consider it for
2.4.24.  Please file a bug report against kernel about it.

 Much of this patch is scheduled to be included in 2.4.24, so the work 
 required 
If it is, then there may be nothing to merge at all.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel-patch-acl

[Russell Coker]

On Fri, 5 Dec 2003 13:59, Ben Collins [EMAIL PROTECTED] wrote:
  This problem has already bitten several skilled Debian developers at
  various times.  Given the problems that are caused for such skilled
  people as a result of this I hate to imagine the consequences for typical
  users!

 But typical users wont be building custom kernels with ACL patches, will
 they? :)

No.  But such kernels can be obtained in many other ways.

For example a user who has dual-boot Fedora and Debian and who uses Arjan's 
2.6 packages will have ACLs enabled in Fedora.  All they need to do is mount 
the Debian root fs and set an ACL or XATTR, or experiment with SE Linux and 
they will no longer be dual-booting, they will be unable to boot Debian.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: kernel-patch-acl

[Ben Collins]

 This problem has already bitten several skilled Debian developers at various 
 times.  Given the problems that are caused for such skilled people as a 
 result of this I hate to imagine the consequences for typical users!

But typical users wont be building custom kernels with ACL patches, will
they? :)

-- 
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

Re: Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image

[Nicola Larosa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 If you're using busybox then try regenerating the initrd image with
 BUSYBOX=no.

 I did not generate the image, i'm using a stock kernel-image-2.4.22-1-k7
 package, no trace of busybox in the initrd image, and it's not even installed
 on this machine. Do you suggest I try mkinitrd'ing a new image anyway?

Since there are no other ideas, I'll open a bug in the BTS.


- --
There are, in the end, no worthwhile things in the world;
there are only worthwhile doings. -- Steve Talbott, NetFuture

Nicola Larosa - [EMAIL PROTECTED]


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD4DBQE/sfQ9Xv0hgDImBm4RAgsNAJi19ykLtxlhxsfhzqeCjoLJPKZuAKCSE1oH
mRVNt0w01ln2z9/E9kzqSw==
=weE1
-END PGP SIGNATURE-

Re: Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image

[Herbert Xu]

Nicola Larosa [EMAIL PROTECTED] wrote:
 
 RAMDISK: cramfs filesystem found at block 0
 RAMDISK: Loading 3532 blocks [1 disk] into ram disk... done.
 Freeing initrd memory: 3532k freed
 VFS: mounted root (cramfs filesystem).
 mount: Usage: mount [-t filesystemtype] [-o options,...] device mountpoint
 This is a builtin command. /etc/fstab and /etc/mtab are NOT supported.

If you're using busybox then try regenerating the initrd image with
BUSYBOX=no.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Kernel 2.4.22-k7-1: initrd cannot mount proc from cramfs image

[Nicola Larosa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the attention, Herbert.


 If you're using busybox then try regenerating the initrd image with
 BUSYBOX=no.

I did not generate the image, i'm using a stock kernel-image-2.4.22-1-k7
package, no trace of busybox in the initrd image, and it's not even installed
on this machine. Do you suggest I try mkinitrd'ing a new image anyway?



- --
There are, in the end, no worthwhile things in the world;
there are only worthwhile doings. -- Steve Talbott, NetFuture

Nicola Larosa - [EMAIL PROTECTED]


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/sOkuXv0hgDImBm4RAh1xAJ976HWTyvqMuaaJd+zGjS51LowJugCgpjDe
6hXVhZ46R8bNVfdJaNzYppk=
=nJJF
-END PGP SIGNATURE-

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Joel Baker]

On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
 On 05-Nov-03, 19:14 (CST), Jonathan Dowland [EMAIL PROTECTED] wrote: 
  I'm in two minds whether or not to ask this, but I've been wondering
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 
 Surely these won't all show up in the same Packages file...if you're
 running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
 Linux and Hurd kernels even be in the list?

*-kernel-image-* is a binary image, and should, of course, have an
appropriate architecture (or tagging, if we ever move to that). However,
*-kernel-source-*, *-kernel-headers-*, and *-kernel-doc-* (off the top
of my head) are all Arch: all, or at least potentially so, since they're
non-binary data that could (arguably) be useful across the board (even on
other kernels, since cross-compiling a kernel is often a supported concept,
even if userland is far nastier as a rule).

Certainly 'netbsd-kernel-source-*' will be Arch: all, even if the package
one uses to build them (the equivalent of kernel-package, also a candidate
for renaming if it comes to pass) is arch-specific.
-- 
Joel Baker [EMAIL PROTECTED],''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpabHx6Zuzrl.pgp
Description: PGP signature

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[martin f krafft]

also sprach Greg Folkert [EMAIL PROTECTED] [2003.11.06.0243 +0100]:
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 [...]
 Martin Kraaft? Herbert Xu? among others... Ready for another heated
 debate.

I don't think we need to debate this. So far, I've heard no voices
against. It's just gonna take a while, you know, Herbert is busy
backporting features...

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft [EMAIL PROTECTED]
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgprf0gSrjstE.pgp
Description: PGP signature

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Henning Makholm]

Scripsit Zenaan Harkness [EMAIL PROTECTED]

 When I search for packages, I think I'd prefer (assuming I want
 to see all kernel- type packages), I'd prefer kernel-linux-*,
 kernel-hurd-*, kernel-freebsd-*, etc.

Instead of trying to cram that into package names, would it not be
more appropriate with a 'kernels' subsection in the archive?

-- 
Henning Makholm In my opinion, this child don't
   need to have his head shrunk at all.

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Steve Greenland]

On 05-Nov-03, 19:14 (CST), Jonathan Dowland [EMAIL PROTECTED] wrote: 
 I'm in two minds whether or not to ask this, but I've been wondering
 about the naming scheme for linux packages - kernel-*. Why not
 linux-kernel-* or linux-* ? If alternative kernels in debian become
 more popular, is there a potential for confusion in the future?

Surely these won't all show up in the same Packages file...if you're
running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
Linux and Hurd kernels even be in the list?

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Keegan Quinn]

On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
 On 05-Nov-03, 19:14 (CST), Jonathan Dowland [EMAIL PROTECTED] wrote: 
  I'm in two minds whether or not to ask this, but I've been wondering
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 
 Surely these won't all show up in the same Packages file...if you're
 running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
 Linux and Hurd kernels even be in the list?

It would be nice to be able to [relatively] easily switch between
kernels.  I have no idea if that is possible, but it would be nice.  :)

 - Keegan


signature.asc
Description: Digital signature

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Steve Greenland]

On 06-Nov-03, 13:47 (CST), Keegan Quinn [EMAIL PROTECTED] wrote: 
 On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
  Surely these won't all show up in the same Packages file...if you're
  running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
  Linux and Hurd kernels even be in the list?
 
 It would be nice to be able to [relatively] easily switch between
 kernels.  I have no idea if that is possible, but it would be nice.  :)

It isn't. At a *minimum*, the kernel side of libc is different,
and I doubt anyone puts any effort into making the user side
binary compatible. Not to mention file systems, device support and
configuration, etc. etc. etc. 

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Ryan Underwood]

Hi,

On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
 On 05-Nov-03, 19:14 (CST), Jonathan Dowland [EMAIL PROTECTED] wrote: 
  I'm in two minds whether or not to ask this, but I've been wondering
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 
 Surely these won't all show up in the same Packages file...if you're
 running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
 Linux and Hurd kernels even be in the list?

I think, when one considers this ideal state of Debian where a Debian
userland is portable to any architecture and Unix-like kernel in
existence, you really just have to consider every combination of
arch/kernel to actually be as a different architecture.  Perhaps the
best approach is to add a kernel tag to the Debian architecture, similar
to GNU config.guess string.

i386-linux is thus different from i386-freebsd, both different from
mips-*.  Packages for that architecture/kernel combination would be
maintained in the pool alongside everything else by the buildds.  Would
probably require significant reworking of lots of things. :(

Another (rather sillier idea) involved a virtual package *-kernel to
indicate to packages which userland the system was being run on, but I
haven't any idea where I was really going with that.

-- 
Ryan Underwood, [EMAIL PROTECTED]

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Jonathan Dowland]

On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote:
 On 05-Nov-03, 19:14 (CST), Jonathan Dowland [EMAIL PROTECTED] wrote: 
  I'm in two minds whether or not to ask this, but I've been wondering
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 
 Surely these won't all show up in the same Packages file...if you're
 running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the
 Linux and Hurd kernels even be in the list?

The image file for kernel A may not be of much use when you are running
kernel B, but I wouldn't suggest that nobody would have a need for it.
Sources and headers would be more useful as you may want to examine the
code of one kernel if you are working on another, and use sections etc.

-- 
Jon Dowland
http://jon.dowland.name/

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Jonathan Dowland]

On Wed, Nov 05, 2003 at 08:43:52PM -0500, Greg Folkert wrote:
 On Wed, 2003-11-05 at 20:14, Jonathan Dowland wrote:
  I'm in two minds whether or not to ask this, but I've been wondering
  about the naming scheme for linux packages - kernel-*. Why not
  linux-kernel-* or linux-* ? If alternative kernels in debian become
  more popular, is there a potential for confusion in the future?
 
 Here we GO again...
 
 Martin Kraaft? Herbert Xu? among others... Ready for another heated
 debate.

Sorry! I'm not out to cause a flamewar. I'll search the archives for the
arguments...

-- 
Jon Dowland
http://jon.dowland.name/

Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)

[Greg Folkert]

On Wed, 2003-11-05 at 20:14, Jonathan Dowland wrote:
 On Wed, Nov 05, 2003 at 11:13:28AM -0600, Ryan Underwood wrote:
  
  Before that realization, it seemed like the type of random cruft that
  sometimes gets pulled in on dist-upgrade; a name change would help
  alleviate that initial perception, IMO.  Why not libc6-linux-headers?
 
 I'm in two minds whether or not to ask this, but I've been wondering
 about the naming scheme for linux packages - kernel-*. Why not
 linux-kernel-* or linux-* ? If alternative kernels in debian become
 more popular, is there a potential for confusion in the future?

Here we GO again...

Martin Kraaft? Herbert Xu? among others... Ready for another heated
debate.
-- 
greg, [EMAIL PROTECTED]
REMEMBER ED CURRY! http://www.iwethey.org/ed_curry


signature.asc
Description: This is a digitally signed message part