#include hallo.h
* Martin Michlmayr [Wed, Aug 04 2004, 05:42:44PM]:
Wouldn't it be easier and more reliable for mkinitrd to use
/proc/modules to get a list of modules to load, e.g. something
like
for m in $(cat /proc/modules | cut -d\ -f1); do
if test $(find /lib/modules/$(uname
Hi,
Goswin von Brederlow writes:
I don't see where such a strict Depends would reduce usefullness.
Now, users of kernel-tree have to download the upstream source once
per upstream release and the Debian patch once per Debian revision.
With a versioned dependency of kernel-tree on
Hi,
Sven Luther writes:
i think it warrants an upload.
So do I. Stuff is here and here and here:
http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source/
http://www.theorie.physik.uni-muenchen.de/~jens/kernel-patch-powerpc/
http://www.theorie.physik.uni-muenchen.de/~jens/mol-modules/
On Fri, Aug 06, 2004 at 09:51:02AM +0200, Jens Schmalzing wrote:
Hi,
Sven Luther writes:
Still, the kernel-patch package should be able to make the upgrade,
since it contains the patchset betweem the version of kernel-source
the user has, and the last one.
That's exactly how it's
Hi,
Sven Luther writes:
Still, the kernel-patch package should be able to make the upgrade,
since it contains the patchset betweem the version of kernel-source
the user has, and the last one.
That's exactly how it's done. More precisely, the apply script in
kernel-patch-debian does this
Hi,
Sven Luther writes:
So, i still don't understand what is broken.
Consider a patch that creates a single file containing a single line:
+foo
You publish this as the first revision, resulting in the patchset:
patch-1:
+foo
You realize you should have applied a different patch:
+bar
So
On Fri, Aug 06, 2004 at 10:33:37AM +0200, Jens Schmalzing wrote:
If you just replace the patch, you will break the path between the
first and the second revision, because you get:
So when I want to create an updated patch, I need a tree with the first
patch applied, a tree with the second
Processing commands for [EMAIL PROTECTED]:
tags 262982 + woody
Bug#262982: kernel: socket ioctl fails in 32-bit binary running on IA64 with
32-bit libraries
There were no tags set.
Tags added: woody
thanks.
Stopping processing here.
Please contact me if you need assistance.
Debian bug
tags 262982 + woody
thanks.
I can reproduce this problem on a sid box w/ woody's 2.4.17 kernel.
I ran your test program on a 2.4.26/sid system, and on a woody system
with a 2.4.20 kernel, and neither machine exhibited this problem.
Processing commands for [EMAIL PROTECTED]:
reassign 263901 kernel
Bug#263901: kernel-image-2.6.7-2: Kernel 2.6.7 USB-Storage Sony Clie: SCSI
Subsystem Errors
Warning: Unknown package 'kernel-image-2.6.7-2-deb.260704'
Bug reassigned from package `kernel-image-2.6.7-2-deb.260704' to `kernel'.
kernel-patch-powerpc-2.6.7_2.6.7-5_powerpc.changes uploaded successfully to
localhost
along with the files:
kernel-patch-powerpc-2.6.7_2.6.7-5.dsc
kernel-patch-powerpc-2.6.7_2.6.7-5.tar.gz
kernel-patch-powerpc-2.6.7_2.6.7-5_all.deb
kernel-headers-2.6.7_2.6.7-5_powerpc.deb
Your message dated Fri, 06 Aug 2004 07:32:17 -0400
with message-id [EMAIL PROTECTED]
and subject line Bug#263058: fixed in kernel-patch-powerpc-2.6.7 2.6.7-5
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the
Accepted:
kernel-build-2.6.7-power3-smp_2.6.7-5_powerpc.deb
to
pool/main/k/kernel-patch-powerpc-2.6.7/kernel-build-2.6.7-power3-smp_2.6.7-5_powerpc.deb
kernel-build-2.6.7-power3_2.6.7-5_powerpc.deb
to
pool/main/k/kernel-patch-powerpc-2.6.7/kernel-build-2.6.7-power3_2.6.7-5_powerpc.deb
kernel-source-2.6.7_2.6.7-4_powerpc.changes uploaded successfully to localhost
along with the files:
kernel-source-2.6.7_2.6.7-4.dsc
kernel-source-2.6.7_2.6.7-4.diff.gz
kernel-patch-debian-2.6.7_2.6.7-4_all.deb
kernel-tree-2.6.7_2.6.7-4_all.deb
kernel-source-2.6.7_2.6.7-4_all.deb
Accepted:
kernel-doc-2.6.7_2.6.7-4_all.deb
to pool/main/k/kernel-source-2.6.7/kernel-doc-2.6.7_2.6.7-4_all.deb
kernel-patch-debian-2.6.7_2.6.7-4_all.deb
to pool/main/k/kernel-source-2.6.7/kernel-patch-debian-2.6.7_2.6.7-4_all.deb
kernel-source-2.6.7_2.6.7-4.diff.gz
to
On Fri, Aug 06, 2004 at 10:33:37AM +0200, Jens Schmalzing wrote:
Hi,
Sven Luther writes:
So, i still don't understand what is broken.
Consider a patch that creates a single file containing a single line:
+foo
You publish this as the first revision, resulting in the patchset:
On my kernel compiled from 2.4.18-2.4.18-14.3 source code,
plus the patch:
http://linuxreviews.org/news/2004/06/11_kernel_crash/24_kernel_ia32-and-x86_64-fix-fpu-state.patch.txt
which is just adding one command in one header file:
include/asm-i386/i387.h
- asm volatile(fwait);
On Fri, Aug 06, 2004 at 11:17:35AM -0400, Andres Salomon wrote:
I've begun sorting through 2.6.8-rc3 packaging stuff; it's currently in my
arch repository
http://sloth.voxel.net/%7edilinger/archzoom.cgi/[EMAIL
PROTECTED]/kernel-source--debian--2.6.
Now that Jens has uploaded 2.6.7-4 (so
On Fri, 2004-08-06 at 18:40 +0200, Sven Luther wrote:
I don't understand what the problem is. Nothing is stopping us from having
2.6.7 nd 2.6.8 in parallel in th archive. You should start maybe by making an
svn cp of the 2.6.7 stuff, and then modifying this new branch.
If patches are
On Fri, Aug 06, 2004 at 12:59:43PM -0400, Andres Salomon wrote:
On Fri, 2004-08-06 at 18:40 +0200, Sven Luther wrote:
I don't understand what the problem is. Nothing is stopping us from having
2.6.7 nd 2.6.8 in parallel in th archive. You should start maybe by making
an
svn cp of the
Processing commands for [EMAIL PROTECTED]:
reassign 262002 initrd-tools
Bug#262002: pivot_root: No such file or directory
Bug reassigned from package `kernel-package' to `initrd-tools'.
--
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system
Your message dated Fri, 6 Aug 2004 22:47:55 -0300
with message-id [EMAIL PROTECTED]
and subject line closing
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
22 matches
Mail list logo
