date:20051107

On Mon, Nov 07, 2005 at 08:30:56AM +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2005 at 08:02:35AM +0100, Sven Luther wrote:
> > I have another proposal, and it involves symlinks. Simon has shown that 
> > using
> > symlinks inside svn is fully supported by svn, so let's try that.
> 
> This is incorrect. Symlinks are dumb pointers.

Indeed, but the checked out tree remain.

> > The plan goes as follows :
> > /dists/versions/2.6.12
> > /dists/versions/2.6.14
> > /dists/versions/2.6.15-rcX
> > /dists/versions/2.6.15
> > 
> > /dists/versions/2.6-git
> 
> WHAT does this fix, except that version disappear faster and you go into
> a merge mess I wanted to avoid.

not, because the versions will stay around.

> > This should solve everyone's problem, i believe.
> 
> Not until someone discribed what the problem is that this should solve.
> The problem is, that someone insists into removing the _main
> development_ tree.

Indeed. The idea was to move 2.6.14 to sid, and make the out-of-git tree the
main development tree, which was exactly what *YOU* where advocating post
2.6.12, so i don't understand what you are complaining about.

Bastian what do you think about my idea of splitting infrastructure and
per-version stuff ? I would hearthily like to hear your comments on that.

Friendly,

Sven Luther

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

Re: [kernel] r4732 - in dists: sid trunk

On Mon, Nov 07, 2005 at 08:31:24AM +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2005 at 07:20:24AM +0100, Norbert Tretkowski wrote:
> > It was announced in #debian-kernel.
> 
> So? This is without notice.

Indeed, we probably need a policy of 24h advance warning on debian-kernel
mailing list, does this seem right ? 

Friendly,

Sven Luther


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

kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

Hello,

Well, i had now two consecutive days of lengthy chats with Manoj about this
issue, and i hate to say it, but i don't think Manoj is ready to compromise on
this and he failed to give any argument apart from this is the way he decided
it in 96 and it has always been done so. A few short quotes to prove that
point :

  09:25 < Manoj> the whole "You do are not following the official way, so fuck
  off, you looser bit is not something I can support
  09:30 < Manoj> theofficial kernel teams botched this issue, and diverged, I
  am keeping the kernel-package behaviour the same as it has been since 1996

These two show perfectly the real problem here, and there has been not a
single technical argument in favour of his solution, and he just throwed away
our own arguments.

I think it is a shame, but well, i refuse to lose more time fighting over
this. What do other people of the kernel-team think about the issue ? 

Friendly,

Sven Luther


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

Bug#337914: linux-2.6: SOFTWARE_SUSPEND needs PM on ppc

Package: linux-2.6
Severity: normal
Tags: patch


As a work around I am going to disable SOFTWARE_SUSPEND on effected 
flavours, so far powerpc/miboot:

  It seems that CONFIG_PM needs to be set for CONFIT_SOFFTWARE_SUSPEND
  to compile cleanly. For startes, swsusp_arch_suspend needs
  swsusp_save.  Sould SOFTWARE_SUSPEND required PM, or should i add some
  strategic #ifdef CONFIG_PM to the code. This is 2.6.14, but i think
  its present in linus' current git.

  arch/ppc/kernel/built-in.o: In function `swsusp_arch_suspend':
  : undefined reference to `swsusp_save'
  arch/ppc/kernel/built-in.o: In function `swsusp_arch_resume':
  : undefined reference to `pagedir_nosave'
  arch/ppc/kernel/built-in.o: In function `swsusp_arch_resume':
  : undefined reference to `pagedir_nosave'
  arch/ppc/platforms/built-in.o: In function `pmac_late_init':
  : undefined reference to `pm_set_ops'

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686-smp
Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: 
LC_ALL set to ja_JP.eucJP)


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

Bug#337713: [PATCH] Null pointer access in nf_queue()

On Sun, Nov 06, 2005 at 12:02:37AM +0200, Torok Edwin wrote:
> Package: linux-image-2.6.14-1-k7
> Version: 2.6.14-1
> Severity: important
> 
> I have got a kernel panic, here it is: (I hand-copied it, since it wasn't 
> saved to disk)
> EIP: 0060: []  Not tainted VLI
> EFLAGS: 00010286 (2.6.14-1-k7)
> EIP is at nf_queue+0x16/0x240
> eax:  ebx: 0001 ecx:  edx: 0002
> esi: dece0920 edi: c03a3aa8 ebp: c0277e70 esp: cf165e78
> ds:  007b es:  007b ss: 0068
> 
> Process sh (pid:5278, threadinfo=cf164000 task=dc5b4ab0)
> Stack:   cf165f00 dae29000  c0277e70 0001 cf165f00 c03a3aa8 
> c0277e70
> c02b1f7c cf165f00 dece0920 0002 0001 dae29000  c0277e70 
>  dece0920  da641b40 da54bcde cc318abc c0277c10 0002
> 
> Call Trace:
> [] ip_local_deliver_finish+0x0/0x230
> [] ip_local_deliver_finish+0x0/0x230
> [] nf_hook_slow+0x0c/0x110
> [] ip_local_deliver_finish+0x0/0x230
> [] ip_local_deliver+0x60/0x2c0
> [] ip_rcv+0x357/0x540
> [] netif_receive_skb+0x238/0x2e0
> [] process_backlog+0x6e/0xf0
> [] net_rx_action+0x87/0x140
> [] __do_softirqq+0x43/0x90
> [] do_softirq+0x26/0x30
> [] do_IRQ+0x1e/0x30
> [] common_interrupt+0x1a/0x20
> Code: c0 75 ec e9 bd e5 e6 ff 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 57 56 
> 53
> 83 ec 10 8b 54 24 2c 8b 74 24 28 8b 04 9b c0 42 3a c0 <8b> 38 85 ff 0f 84 96 
> 01
> 00 00 86 44 24 2c 8b 7c 24 2c c7 44 24
> <0>Kernel panic - not syncing: Fatal exception in interrupt
> 
> Bug reproducible: always.
> Steps to reproduce: Start fireflierd
> Result: kernel panic
> 
> What fireflierd does is try to communicate with the ip_queue module, that 
> isn't loaded.
> If I load the module everything is ok. 
> On kernel version 2.6.12 I got an error message from fireflierd, but the 
> kernel didn't panic.
> If you need further info, tell please tell me how to provide it.
> If you need the program fireflierd, just tell me, I can upload it somewhere 
> (binary/source), it is a GPL program,
> that's going to be released soon.

Thanks,

I did some disasembling fun and games, and I'm pretty sure the patch
below will fix your problem. I'll fire of a build, I'd be greateful if
you could test it.

According to the trace above, pf (%edx) is 2, however, it seems that
queue_handler[pf] is NULL.  I would guess that it has been unbound using
netlink (nfqnl_recv_config(), case NFQNL_CFG_CMD_PF_UNBIND:)

Or in other words, queue_handler[pf] can be set to NULL from userspace,
but it is accessed without checking to see if it is NULL.

I'm taking a few leaps of faith here, so my logic could be out.
Here is the a portion of the disasembled code if anyone cares:

0xc02b2500: push   %ebp
0xc02b2501: push   %edi
0xc02b2502: push   %esi
0xc02b2503: push   %ebx
0xc02b2504: sub$0x10,%esp
0xc02b2507: mov0x2c(%esp),%edx
0xc02b250b: mov0x28(%esp),%esi
0xc02b250f: mov0xc03a42c0(,%edx,4),%eax
0xc02b2516: mov(%eax),%edi
0xc02b2518: test   %edi,%edi
0xc02b251a: je 0x412b26b6

Signed-off-by: Horms <[EMAIL PROTECTED]>


diff --git a/net/netfilter/nf_queue.c b/net/netfilter/nf_queue.c
index d10d552..d3a4f30 100644
--- a/net/netfilter/nf_queue.c
+++ b/net/netfilter/nf_queue.c
@@ -117,7 +117,7 @@ int nf_queue(struct sk_buff **skb, 
 
/* QUEUE == DROP if noone is waiting, to be safe. */
read_lock(&queue_handler_lock);
-   if (!queue_handler[pf]->outfn) {
+   if (!queue_handler[pf] || !queue_handler[pf]->outfn) {
read_unlock(&queue_handler_lock);
kfree_skb(*skb);
return 1;



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

Bug#337713: [netfilter-core] [PATCH] Null pointer access in nf_queue()

2005-11-07 Thread Harald Welte

On Mon, Nov 07, 2005 at 05:39:53PM +0900, Horms wrote:

> I did some disasembling fun and games, and I'm pretty sure the patch
> below will fix your problem. I'll fire of a build, I'd be greateful if
> you could test it.

Sorry, Horms, you must have missed my previos fix (that does exactly the
same).  I've already posted it to netdev, and IIRC, Arnaldo has merged
it for net-2.6.15.

Sorry for not Cc'ing you with the fix, it seems like I only reported
back to bugzilla :(

-- 
- Harald Welte <[EMAIL PROTECTED]> http://netfilter.org/

  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."-- Paul Vixie


pgpWjsIM8gAda.pgp
Description: PGP signature

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 6 Nov 2005 21:42:56 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> On Sun, Nov 06, 2005 at 09:05:49PM +0100, Jonas Smedegaard wrote:

> > I have heard this mentioned several times now, but without any
> > details. Could you please point me to some summary of that plan? Or
> > if missing then post a draft to our wiki?
> 
> Well, i am not a wiki guy, so i will post here, and you can add it
> somewhere ?
> 
> Basically, the plan is the folowing :

Thanks. It is now available for improvements here:
http://wiki.debian.org/KernelModulesPackaging



 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbyBTn7DbMsAkQLgRAigHAJ4motpzOU56XUO+wrz2QPofzYmY9QCeIzWa
L0pXA8/botWi0thS76c7CHo=
=pPuU
-END PGP SIGNATURE-

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, 7 Nov 2005 07:44:19 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Sun, Nov 06, 2005 at 11:17:53PM -0600, Manoj Srivastava wrote:
>> On Sun, 6 Nov 2005 18:12:48 +0100, Sven Luther
>> <[EMAIL PROTECTED]> said:
>> 
>> > On Sun, Nov 06, 2005 at 10:57:13AM -0600, Manoj Srivastava wrote:
>> >> > There is no reason that the linux-headers packages could not
>> >> > be used to build out-of-tree modules using the symlink,
>> >> > without having the linux-image installed, so this doesn't
>> >> > work, even though it looks like a seducing proposal.
>> >> 
>> >> Third party modules which have been integrated into Debian can
>> >> still be built, without the linux-image installed, by
>> >> a) cd /usr/src/kernel-headers-foo, call make-kpkg
>> >> b) KSRC=/usr/src/kernel-headers-foo, call make-kpkg
>> 
>> > Yeah, hear yourself, because you don't feel like adding a simple
>> > exception to the check for build, or do a find -name \*.ko as
>> > Martin suggested, each and all the packaged modules need to be
>> > modified, as well as all third party module which are not
>> > packaged and depend on the build symlink working.
>> 
>> When I, as a user, build kernel images, on make install, it creates
>> source and build links, pointing to the directory where the sources
>> lie. When I package the image up, it too comes with a nice source
>> and build links.

> Sure, whatever, but what is really needed here is that user-compiled
> kernel package follow the same layout as the official kernels,
> namely the -headers providing all the needed stuff to build
> out-of-tree modules, *AND* include the build symlink. The source
> symlink is bogus, and has been removed as such, only the build
> symlink should be used. We discussed this something like 6 month ago
> here, i believe.

That's silly. I have compiled a kernel image, I have the
 sources lying around, and now I must compile a headers package
 and install it, duplicating loads of files, just to  compile a
 module? Why? Upstream Makefile already install the source and build
 links, which work, why go out of our way to remove them to make the
 end user install yet another package?

>> So kernel image packages ship with source links, and build
>> links. Even if I did not ask the question preinst, the packages
>> would conflict, since the same files belong in both.

> Indeed, but what we, the kernel team, are asking you on this point,
> is to change the way you handle it, and you are resisting for no
> good reason, except the way you always did it, or whatever.

The question is, what benefit is derived for the common user
 with insisting that the source and build links are taken out
 of the kernel image?


a) If I compile and install a kernel image on the same
   machine, the build symlinks should just work.
b) if I install a kernel header package, but do not have
   sources, the /lib/modules/$(uname -r)/build trick should
   work. 
c) If i do not have a image installed, just a header packages,
   it should be possible to still compile third party modules.

I think that use cases a and b are by far the most common
 cases, and should be catered to work out of the box. case 3 requires
 you to set KSRC, but it is ewasy enough to set up a wrapper.

manoj
-- 
There are bugs and then there are bugs.  And then there are bugs. Karl
Lehenbauer
Manoj Srivastava <[EMAIL PROTECTED]>
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 and the build symlink ... I don't think we can continue to use k-p under current conditions.

On Mon, 7 Nov 2005 09:44:12 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> Hello, Well, i had now two consecutive days of lengthy chats with
> Manoj about this issue, and i hate to say it, but i don't think
> Manoj is ready to compromise on this and he failed to give any
> argument apart from this is the way he decided it in 96 and it has
> always been done so. A few short quotes to prove that point :

> These two show perfectly the real problem here, and there has been
> not a single technical argument in favour of his solution, and he
> just throwed away our own arguments.

Can we have some one who can acrtually follow a technical
 argument take this up with me, please? Repeatedly demonstrating
 common use cases and solutions to them have not worked with
 Sven. I'll happily continue the discussion with anyone able to follow
 along.

manoj
-- 
Machine-Independent, adj.: Does not run on any existing machine.
Manoj Srivastava <[EMAIL PROTECTED]>
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]

Bug#330583: Problem solved

2005-11-07 Thread Boris Kleibl


Uff, I solved the problem, but what happened?

As some days ago the new linux-image-2.6.14 was availlable, I did a 
fresh debian sid installation. Booting the system shows the same problem 
as mentioned above too. Hmmm! I tried to boot from a KNOPPIX 4.0.2 Live 
CD, it started up to the desktop, but showed the harddisk as not 
mountable! What the hell ... Perhaps the harddisk has a failure? I 
checked the mentioned drive with seagate seatools - all tests succeeded 
except the filesystem-test which shows a damaged master boot record. 
Strange! I tested the drive with the linux and windows tools not showing 
me any errors. So I deleted the vfat partition with windows and then the 
reboot with debian/sid 2.6.14 succeeded! Yippee! Now I wrote a new 
DOS-FAT on the drive, partitioned and formatted and all is ok.


What changed between kernel 2.6.12 and kernel 2.6.13/14 so that the 
error got evidently?


Boris


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

Bug#337293: linux-image-2.6.14-1-k7: kernel doesn't boot...

2005-11-07 Thread Bruno Boettcher

On Thu, Nov 03, 2005 at 09:06:25PM +0100, Jonas Smedegaard wrote:
> Unrelated to the bug, but please consider using aptitude instead of the
> old deprecated dselect.
hmm this looks hadeer to use than dselect, but i will try...

> this is a bug in yaird. Yaird is a ramdisk generator used by default
> for the most recent Linux kernels. The classical ramdisk generator
> mkinitrd (in the package mkinitrd-tools) cannot generate initramfs
> images needed by newest versions of Linux.
ok

> What kernel version did you run while installing the new version?
Linux jigoku 2.6.12-1-k7 #1 Tue Sep 27 13:22:07 JST 2005 i686 GNU/Linux

> In most cases if yaird cannot handle your system setup it fails to
> install the ramdisk. So I am very interested in knowing if somehow on
> your system yaird failed silently or you perhaps missed the failure at
> install time: Please report the output of the following command:
> 
> dpkg-reconfigure linux-image-2.6.14-1-k7
output on 
http://bboett.free.fr/kernel/

> If you can put your ramdisk image ( /boot/initrd.img-2.6.14-1-k7 )
> public somewhere for further investigation that would be helpful too.
output on 
http://bboett.free.fr/kernel/
> 
> If you want to try using the other laternative ramdisk generator
> capable of making initramfs images (the package called initramfs-tools
> that I noticed you have installed already) then add the following
> to /etc/kernel-img.conf (all in one line):
  will try

-- 
ciao bboett
==
[EMAIL PROTECTED]
http://inforezo.u-strasbg.fr/~bboett
===


signature.asc
Description: Digital signature

Bug#337902: Missing dependency on /usr/sbin/mkinitramfs

2005-11-07 Thread Magnus Ekdahl

Sven Luther wrote:

On Mon, Nov 07, 2005 at 07:48:07AM +0100, Magnus Ekdahl wrote:

Package: linux-image-2.6.14-1-k7
Version: 2.6.14-2
Severity: important

When installing I get the following error (sorry for the swedish locale)

running dpkg --pending --configure ...
Ställer in linux-image-2.6.14-1-k7 (2.6.14-2) ...
Failed to find suitable ramdisk generation tool for kernel version

You should have either yaird or initramfs-tools installed, yaird has the
benefit of not needing udev or hotplug.

That said, there is a dependency on :

yaird | initramfs-tools | linux-initramfs-tool

Which should have pulled in yaird, but apparently hasn't, can you check why ?

I think that I have yaird installed. The output below is freely translated from
Swedish

# apt-get install yaird
Reading pakagelists... done
Building depenencytree... done
yaird is already the latest version.

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# dpkg -P initramfs-tools
(Reading database ... 171586 files and directories installed.)
Removing initramfs-tools ...
Erasing configurationfiles for initramfs-tools ...
# apt-get install --reinstall linux-image-2.6.14-1-k7
Reading pakagelists... done
Building depenencytree... done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0B/17,4MB archive.
After extraction an additional of 0B will be used.
Do you want to continue [Y/n]?
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
(Reading database ... 171527 files and directories installed.)
Preparing to replace linux-image-2.6.14-1-k7 2.6.14-2 (with
.../linux-image-2.6.14-1-k7_2.6.14-2_i386.deb) ...

You are attempting to install an initrd kernel image (version
2.6.14-1-k7) while running a kernel of version 2.6.7-1-k7, but
you have no suitable ramdisk generation tool installed among
/usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs. This will break the
installation, unless a

suitable ramdisk generation tool is also being installed right
now.

Could not find . at /var/lib/dpkg/tmp.ci/preinst line 228.

You are attempting to install an initrd kernel image (version 2.6.14-1-k7)
This will not work unless you have configured your boot loader to use
initrd. (An initrd image is a kernel image that expects to use an INITial
Ram Disk to mount a minimal root file system into RAM and use that for
booting).

As a reminder, in order to configure LILO, you need
to add an 'initrd=/initrd.img' to the image=/vmlinuz
stanza of your /etc/lilo.conf

I repeat, You need to configure your boot loader -- please read your
bootloader documentation for details on how to add initrd images.

If you have already done so, and you wish to get rid of this message,
please put
"do_initrd = Yes"
in /etc/kernel-img.conf. Note that this is optional, but if you do not,
you will continue to see this message whenever you install a kernel
image using initrd.
Do you want to stop now? [Y/n]n
The directory /lib/modules/2.6.14-1-k7 still exists. Continuing as directed.
Extracting replacement linux-image-2.6.14-1-k7 ...
Setting up linux-image-2.6.14-1-k7 (2.6.14-2) ...
Failed to find suitable ramdisk generation tool for kernel version 2.6.14-1-k7 on running kernel
2.6.7-1-k7 in /usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs

dpkg: error while handling linux-image-2.6.14-1-k7 (--configure):
subprocess post-installation script gave errorcode 2
There was an error handling:
linux-image-2.6.14-1-k7
E: Sub-process /usr/bin/dpkg returned an error code (1)

# ls -la /usr/sbin/mkinitrd.yaird
-rwxr-xr-x 1 root root 2796 2005-11-03 05:06 /usr/sbin/mkinitrd.yaird
# ls -la /usr/sbin/mkinitrd
-rwxr-xr-x 1 root root 29308 2005-10-24 09:09 /usr/sbin/mkinitrd
# ls -la /usr/sbin/mkinitramfs
ls: /usr/sbin/mkinitramfs: The file or directory does not exist

--
I hope this brings some clearity to the fenomena.

/Magnus Ekdahl

Bug#337902: Missing dependency on /usr/sbin/mkinitramfs

On Mon, Nov 07, 2005 at 10:52:34AM +0100, Magnus Ekdahl wrote:
> Sven Luther wrote:
> >On Mon, Nov 07, 2005 at 07:48:07AM +0100, Magnus Ekdahl wrote:
> >
> >>Package: linux-image-2.6.14-1-k7
> >>Version: 2.6.14-2
> >>Severity: important
> >>
> >>When installing I get the following error (sorry for the swedish locale)
> >>
> >>running dpkg --pending --configure ...
> >>Ställer in linux-image-2.6.14-1-k7 (2.6.14-2) ...
> >>Failed to find suitable ramdisk generation tool for kernel version
> >
> >
> >You should have either yaird or initramfs-tools installed, yaird has the
> >benefit of not needing udev or hotplug.
> >
> >That said, there is a dependency on :
> >
> >  yaird | initramfs-tools | linux-initramfs-tool
> > 
> >Which should have pulled in yaird, but apparently hasn't, can you check 
> >why ?
> 
> I think that I have yaird installed. The output below is freely translated 
> from Swedish

please run LANG=C when doing this kind of stuff.

Not sure, this seems to be a kernel-package bug, need to look at it in the
future.

Friendly,

Sven Luther

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, Nov 07, 2005 at 03:52:31AM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 07:44:19 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

Manoj, it is clears you will not be convinced, and any argument given you will
just ignore, i will stop replying to you on this thread anymore.

Friendly,

Sven Luther


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

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, Nov 07, 2005 at 10:37:24AM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Sun, 6 Nov 2005 21:42:56 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > On Sun, Nov 06, 2005 at 09:05:49PM +0100, Jonas Smedegaard wrote:
> 
> > > I have heard this mentioned several times now, but without any
> > > details. Could you please point me to some summary of that plan? Or
> > > if missing then post a draft to our wiki?
> > 
> > Well, i am not a wiki guy, so i will post here, and you can add it
> > somewhere ?
> > 
> > Basically, the plan is the folowing :
> 
> Thanks. It is now available for improvements here:
> http://wiki.debian.org/KernelModulesPackaging

Thanks Jonas.

Friendly,

Sven Luther


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

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

On Mon, Nov 07, 2005 at 03:54:59AM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 09:44:12 +0100, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > Hello, Well, i had now two consecutive days of lengthy chats with
> > Manoj about this issue, and i hate to say it, but i don't think
> > Manoj is ready to compromise on this and he failed to give any
> > argument apart from this is the way he decided it in 96 and it has
> > always been done so. A few short quotes to prove that point :
> 
> > These two show perfectly the real problem here, and there has been
> > not a single technical argument in favour of his solution, and he
> > just throwed away our own arguments.
> 
> Can we have some one who can acrtually follow a technical
>  argument take this up with me, please? Repeatedly demonstrating
>  common use cases and solutions to them have not worked with
>  Sven. I'll happily continue the discussion with anyone able to follow
>  along.

Manoj, repeteadly ignoring any argumentation and failing to give any kind of
rational argument in your favour apart from the "i have always done so", and
then going insulting (not only me but lennert also) on irc, is hardly the way
to have a technical argument. So, until your change you mind and come to a
more reasonable state of mind, there is no way we can agree on anything, and i
think the kernel team is better off not using k-p, than having to repeteadly
lose a huge amount of time to argue with you.

Friendly,

Sven Luther

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

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 7 Nov 2005 09:44:12 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> Well, i had now two consecutive days of lengthy chats with Manoj
> about this issue, and i hate to say it, but i don't think Manoj is
> ready to compromise on this and he failed to give any argument apart
> from this is the way he decided it in 96 and it has always been done
> so. A few short quotes to prove that point :
> 
>   09:25 < Manoj> the whole "You do are not following the official
> way, so fuck off, you looser bit is not something I can support

If you do not include your non-annoying comment leading to the above it
is quite irrelevant for showing anything, I believe.


>   09:30 < Manoj> theofficial kernel teams botched this issue, and
> diverged, I am keeping the kernel-package behaviour the same as it
> has been since 1996
> 
> These two show perfectly the real problem here, and there has been
> not a single technical argument in favour of his solution, and he
> just throwed away our own arguments.
> 
> I think it is a shame, but well, i refuse to lose more time fighting
> over this. What do other people of the kernel-team think about the
> issue ? 

Well, I believe that the real problem is that you disagree about this
(from the proposed new module plan):

> Each modules should build packages using the
> KSRC=/lib/modules/--/build, which is the
> default KSRC recomended by upstream and which every module out there
> use.

Manoj seem to not want to change what has worked for a long time: Using
what with the new kernel package names is
KSRC=/usr/src/--


I understand the point of wanting to support /lib/modules/... as a
valid reference for source location, but I do not know if that location
is universally agreed upon. And it seems to me that Manoj is not
breaking things, but refusing to _change_ (and possibly improve)
something that is not broken.


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbyTQn7DbMsAkQLgRArCfAJkBFWPLB/DddDuQOLc6jRSxzV5KRQCfY1P3
ApRZxQsKxdFoschCFV5W8Xs=
=Fwyn
-END PGP SIGNATURE-

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, 7 Nov 2005 10:59:35 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Mon, Nov 07, 2005 at 03:52:31AM -0600, Manoj Srivastava wrote:
>> On Mon, 7 Nov 2005 07:44:19 +0100, Sven Luther
>> <[EMAIL PROTECTED]> said:

> Manoj, it is clears you will not be convinced, and any argument
> given you will just ignore, i will stop replying to you on this
> thread anymore.

Before insulting me by accusing me of being stubborn and being
 unconvincable,  you should consider whether you are able to either
 understand, or conduct, a technical debate. I am slowly being drawn
 to the conclusion you might not be; so I am inviting other people to
 enter this discussion that can actually understand the merits of the
 problems and solutions, rather than hand waving about how intractable
 everyone else is.

manoj
-- 
Cole's Law: Thinly sliced cabbage.
Manoj Srivastava <[EMAIL PROTECTED]>
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: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

2005-11-07 Thread Frans Pop

On Monday 07 November 2005 10:52, Manoj Srivastava wrote:
> That's silly. I have compiled a kernel image, I have the
>  sources lying around, and now I must compile a headers package
>  and install it, duplicating loads of files, just to  compile a
>  module? Why? Upstream Makefile already install the source and build
>  links, which work, why go out of our way to remove them to make the
>  end user install yet another package?

I agree with Manoj here: the user should have the option of having 
_either_ the full kernel sources installed _or_ the kernel headers 
package.
Does the scheme proposed by the kernel team make this possible?

pgpQkusiPxQVY.pgp
Description: PGP signature

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, Nov 07, 2005 at 11:21:39AM +0100, Frans Pop wrote:
> On Monday 07 November 2005 10:52, Manoj Srivastava wrote:
> > That's silly. I have compiled a kernel image, I have the
> >  sources lying around, and now I must compile a headers package
> >  and install it, duplicating loads of files, just to  compile a
> >  module? Why? Upstream Makefile already install the source and build
> >  links, which work, why go out of our way to remove them to make the
> >  end user install yet another package?
> 
> I agree with Manoj here: the user should have the option of having 
> _either_ the full kernel sources installed _or_ the kernel headers 
> package.

At the cost of breaking the official kernel images ? 

> Does the scheme proposed by the kernel team make this possible?

I don't care what happens to user built packages, i just want Manoj to not
break the official kernels. 

And yes, i believe that there is no reason why the kernel-source package built
by the user should not provide this symlink, or better yet the source symlink,
don't you think.

Friendly,

Sven Luther



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

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

2005-11-07 Thread Frans Pop

On Monday 07 November 2005 09:44, Sven Luther wrote:
>   09:25 < Manoj> the whole "You do are not following the official way,
> so fuck off, you looser bit is not something I can support
>   09:30 < Manoj> theofficial kernel teams botched this issue, and
> diverged, I am keeping the kernel-package behaviour the same as it has
> been since 1996

Sven, I've seen you make very similar remarks in your mails/comments on 
IRC to Manoj. This is not helping.

The fact that you are unable to convince someone means that you either 
need to involve other people or take a step back and look at the problem 
yourself again. Failure to reach an agreement is always to blame on both 
parties.

pgpb3Lg91DbRp.pgp
Description: PGP signature

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

On Mon, Nov 07, 2005 at 10:56:32AM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 7 Nov 2005 09:44:12 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > Hello,
> > 
> > Well, i had now two consecutive days of lengthy chats with Manoj
> > about this issue, and i hate to say it, but i don't think Manoj is
> > ready to compromise on this and he failed to give any argument apart
> > from this is the way he decided it in 96 and it has always been done
> > so. A few short quotes to prove that point :
> > 
> >   09:25 < Manoj> the whole "You do are not following the official
> > way, so fuck off, you looser bit is not something I can support
> 
> If you do not include your non-annoying comment leading to the above it
> is quite irrelevant for showing anything, I believe.

No, this clearly shows Manoj's attitude with regard to the official kernels,
and it is not the first time he has said this, and i believe that until he
loses that attitude, it is not fruitful to work with him on this, and we
should do our own thing, as various other people have been wanting to do since
a long time.

> >   09:30 < Manoj> theofficial kernel teams botched this issue, and
> > diverged, I am keeping the kernel-package behaviour the same as it
> > has been since 1996
> > 
> > These two show perfectly the real problem here, and there has been
> > not a single technical argument in favour of his solution, and he
> > just throwed away our own arguments.
> > 
> > I think it is a shame, but well, i refuse to lose more time fighting
> > over this. What do other people of the kernel-team think about the
> > issue ? 
> 
> Well, I believe that the real problem is that you disagree about this
> (from the proposed new module plan):
> 
> > Each modules should build packages using the
> > KSRC=/lib/modules/--/build, which is the
> > default KSRC recomended by upstream and which every module out there
> > use.
> 
> Manoj seem to not want to change what has worked for a long time: Using
> what with the new kernel package names is
> KSRC=/usr/src/--

Indeed, the upstream modules will all default to use the build symlink, and
Manoj wants all third-party module maintainer to change the KSRC as well as
all users to do so as well. 

> I understand the point of wanting to support /lib/modules/... as a
> valid reference for source location, but I do not know if that location
> is universally agreed upon. And it seems to me that Manoj is not

Sure, it is the official upstream way, and all third party modules default to
it.

> breaking things, but refusing to _change_ (and possibly improve)
> something that is not broken.

Nope, he plans to break what we currently have working in the official
kernels, and has been working and agreed upon since over 6 month, and which we
have started advertizing as the canonical way of building third party modules
since a few month now.

In any case, if he disliked it, 6 month ago was the time to provide feedback,
provided there where real arguments to back it off, which i have failed to
see, did you see any ?

Friendly,

Sven Luther

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

Bug#337713: email-address update

2005-11-07 Thread Török Edvin

owner 337713 [EMAIL PROTECTED]
submitter 337713 [EMAIL PROTECTED]
owner 336915 [EMAIL PROTECTED]
submitter 336915 [EMAIL PROTECTED]
owner 320784 [EMAIL PROTECTED]
submitter 320784 [EMAIL PROTECTED]
owner 336094 [EMAIL PROTECTED]
submitter 336094 [EMAIL PROTECTED]
thanks
This is my new email address ([EMAIL PROTECTED])

Processed: email-address update

Processing commands for [EMAIL PROTECTED]:

> owner 337713 [EMAIL PROTECTED]
Bug#337713: linux-image-2.6.14-1-k7: Kernel panic "Fatal exception in interrupt"
Owner recorded as [EMAIL PROTECTED]

> submitter 337713 [EMAIL PROTECTED]
Bug#337713: linux-image-2.6.14-1-k7: Kernel panic "Fatal exception in interrupt"
Changed Bug submitter from Torok Edwin <[EMAIL PROTECTED]> to [EMAIL PROTECTED]

> owner 336915 [EMAIL PROTECTED]
Bug#336915: gcc-4.0: Incorrect "Warning statement has no effect" when using a 
GNU extension (possible regression)
Owner recorded as [EMAIL PROTECTED]

> submitter 336915 [EMAIL PROTECTED]
Bug#336915: gcc-4.0: Incorrect "Warning statement has no effect" when using a 
GNU extension (possible regression)
Changed Bug submitter from Torok Edwin <[EMAIL PROTECTED]> to [EMAIL PROTECTED]

> owner 320784 [EMAIL PROTECTED]
Bug#320784: installation-reports: missing script & packages from CD
Owner recorded as [EMAIL PROTECTED]

> submitter 320784 [EMAIL PROTECTED]
Bug#320784: installation-reports: missing script & packages from CD
Changed Bug submitter from Torok Edwin <[EMAIL PROTECTED]> to [EMAIL PROTECTED]

> owner 336094 [EMAIL PROTECTED]
Bug#336094: kdevelop3: crashes on build project when kdevelop3-plugins package 
is installed
Owner recorded as [EMAIL PROTECTED]

> submitter 336094 [EMAIL PROTECTED]
Bug#336094: kdevelop3: crashes on build project when kdevelop3-plugins package 
is installed
Changed Bug submitter from Torok Edwin <[EMAIL PROTECTED]> to [EMAIL PROTECTED]

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

On Mon, Nov 07, 2005 at 11:28:25AM +0100, Frans Pop wrote:
> On Monday 07 November 2005 09:44, Sven Luther wrote:
> >   09:25 < Manoj> the whole "You do are not following the official way,
> > so fuck off, you looser bit is not something I can support
> >   09:30 < Manoj> theofficial kernel teams botched this issue, and
> > diverged, I am keeping the kernel-package behaviour the same as it has
> > been since 1996
> 
> Sven, I've seen you make very similar remarks in your mails/comments on 
> IRC to Manoj. This is not helping.

Oh, you want a few more : 

09:11 < lennert> fwiw i'm with svenl on this one
...
09:13 < Manoj> well, there is too much going on to have to deal with clueless
ad hominems
09:14 < Manoj> before you pontificate on which side your august opinions sides
with, perhaps you should understand what the sides really are?
09:13 < lennert> geeez
09:13 < lennert> guess i ended up in #wank-central, sorry guys
09:16 -!- lennert [~] has left #debian-kernel []
...
09:45 < Manoj> svenl: then you guys are, in my opinion, not really worth
dealing with.
...
09:56 < Manoj> svenl: you, sir, are an idiot, if you think that people who
install just a kernel-image or kernel-image+kernel-headers and wanting to
compile thiord party modules are fewer than people who just install random
headers and compile third party modules.

Face it, nothing is going to help.

> The fact that you are unable to convince someone means that you either 
> need to involve other people or take a step back and look at the problem 
> yourself again. Failure to reach an agreement is always to blame on both 
> parties.

Sure, and i ma the only one to blame here, right ? And Manoj is ok. Why you
didn't step in when he started making outwordly claims and fails to present a
single technical argument to back his claims, and ignores my own reasonable
requests.

I mean, where was he when we discussed this over 6 month ago and fixed the
packages accordyingly ? Then was time to comment. Now he just comes and breaks
everything, and is insulting to everyone not agreeing with him ? 

Friendly,

Sven Luther

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

Packaging of modules which are in official kernel

2005-11-07 Thread Sebastian Ley

Hi,

I am the maintainer of the ipw2100 module package. That module is now
included in the kernel as of version 2.6.14. For the time being I want to
keep the package and decide later whether to drop it.

The question is however, where to put the modules such that they do not
conflict with the modules from the kernel. The related bugreport is
#337920.

I just want to verify that the submitter's solution is the right way to go.

Please CC me on replies, as I am not subscribed to this list.

TIA and greetings,
Sebastian




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

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 7 Nov 2005 11:21:39 +0100
Frans Pop <[EMAIL PROTECTED]> wrote:

> On Monday 07 November 2005 10:52, Manoj Srivastava wrote:
> > That's silly. I have compiled a kernel image, I have the
> >  sources lying around, and now I must compile a headers package
> >  and install it, duplicating loads of files, just to  compile a
> >  module? Why? Upstream Makefile already install the source and build
> >  links, which work, why go out of our way to remove them to make the
> >  end user install yet another package?
> 
> I agree with Manoj here: the user should have the option of having 
> _either_ the full kernel sources installed _or_ the kernel headers 
> package.
> Does the scheme proposed by the kernel team make this possible?

If the scheme includes the plan for module-building summarized by Sven
[1] then I believe the answer is no.

If instead the scheme includes the adjusted[3] plan for module-building
[2] then I believe the answer is yes.


I would appreciate more info on that scheme[4] - and would be happy to
put it on wiki if it is not already documented somewhere.


 - Jonas

[1] http://wiki.debian.org/KernelModulesPackaging?action=recall&rev=2

[2] http://wiki.debian.org/KernelModulesPackaging?action=recall&rev=8

[3] Sven feels strongly about the kernel team mentioned on the adjusted
page.

[4] A "read backlog" is no use: IRC is for chatting, not
documenting!

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDbz1hn7DbMsAkQLgRAgsWAJoCJcPTLUG1VUlheniE8pZqKTdObACeMKbk
whm0D1eLzvWq7Tlhjt+rEUU=
=H9aR
-END PGP SIGNATURE-

Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed

On Mon, Nov 07, 2005 at 12:41:21PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 7 Nov 2005 11:21:39 +0100
> Frans Pop <[EMAIL PROTECTED]> wrote:
> 
> > On Monday 07 November 2005 10:52, Manoj Srivastava wrote:
> > > That's silly. I have compiled a kernel image, I have the
> > >  sources lying around, and now I must compile a headers package
> > >  and install it, duplicating loads of files, just to  compile a
> > >  module? Why? Upstream Makefile already install the source and build
> > >  links, which work, why go out of our way to remove them to make the
> > >  end user install yet another package?
> > 
> > I agree with Manoj here: the user should have the option of having 
> > _either_ the full kernel sources installed _or_ the kernel headers 
> > package.
> > Does the scheme proposed by the kernel team make this possible?
> 
> If the scheme includes the plan for module-building summarized by Sven
> [1] then I believe the answer is no.
> 
> If instead the scheme includes the adjusted[3] plan for module-building
> [2] then I believe the answer is yes.

Ok, it seems Jonas knows how to do this better than everyone, and also
resorted to insulting me, i guess i was wrong on these issues, and i hope him
big luck in fixing the kernel packages the way he and Manoj want them.

Jonas, the way you spoke to me is unexcusable, and i can't work with you in
these conditions, please don't adress me again in the near future.

Sven Luther


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

Bug#337939: linux-image-2.6.14-1-powerpc64: [powerpc64] linux-image-2.6.14-1 fails to install

2005-11-07 Thread Eduardo Trapani

Package: linux-image-2.6.14-1-powerpc64
Version: 2.6.14-2
Severity: important

Trying to install linux-image-2.6.14-1-powerpc64 from unstable yields
the following error:

 You already have a NoLOADER configuration in /etc/.conf
 Install a boot block using the existing /etc/.conf? [Yes]
 There was an error with running , a log file is
 available in file /var/log/_log.7153.  Please edit /etc/.conf
 manually and re-run , or make other arrangements to boot
 your machine.
  Please hit return to continue 

The file mentioned above has just one line saying:

 sh: line 1: /sbin/: is a directory

I tried not installing the boot block and generating it again, but I get
the same error.

The package can be installed by saying no to "using existing /etc/.conf" and to 
"wipe out your old NoLOADER ..." 

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc64)
Kernel: Linux 2.6.12-1-powerpc64
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.14-1-powerpc64 depends on:
ii  module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo
ii  yaird 0.0.11-3   Yet Another mkInitRD

-- no debconf information


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

Bug#336993: noise from line in on G5

2005-11-07 Thread Michel Dänzer

On Mon, 2005-11-07 at 12:46 +, Paul Brossier wrote:
> 
> On Wed, Nov 02, 2005 at 05:01:06AM +, Paul Brossier wrote:
> > 
> > I have been trying to boot this PowerBook7,2 on 2.6.14, but it fails for
> > me (see #336993), so maybe this got fixed since 2.6.12.
> 
> right, i can reproduce this on 2.6.14 too.

See

http://bugzilla.ubuntu.com/show_bug.cgi?id=14485

and

https://wiki.ubuntu.com/BreezyReleaseNotes

This seems to be a bug in yaboot, I couldn't boot an initramfs kernel
either until I moved /boot from XFS to ext3.


-- 
Earthling Michel Dänzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

Re: Re: Re: I can't build Modules.debs with linuxheaders 2.6.12-1-k7

2005-11-07 Thread Sébastien Platel

I'm trying to compile nvidia kernel driver by getting source from debian 
repository, decompressing it using "tar -zxvf XXX" and then using


cd /usr/src/linux-headers-2.6.12-1686
make-kpkg modules_image

since then I found another way to compile this module following this 
document http://www.coagul.org/article.php3?id_article=346 (as you can't 
read french I can describe it quickly saying that after a few 
environnement variables setup and cd into the module source the line 
"debian/rules binary_modules" compiles the debian package



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

Care to comment on plan for module building?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Eduard (and cc kernel list),

I have put together a draft for future kernel module handling, based on
a discussion at the kernel list and spiced up with a few thoughts of my
own. It is available here: http://wiki.debian.org/KernelModulesPackaging

Could you please have a look and tell me what you think (or perhaps
simply edit that wiki page directly)?

I honestly have never ever used module-assistant, but suspect you have
a lot of knowledge on ugly makefiles, and quite possibly have valuable
input on this.


Regards,

 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb1bQn7DbMsAkQLgRAuyVAKCOf7dPCwUbkim3ynfj5TZCmqhtVgCfehjh
BCab11AQ3MDi+T495BhotOE=
=iZ3J
-END PGP SIGNATURE-

Re: Care to comment on plan for module building?

On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Eduard (and cc kernel list),
> 
> I have put together a draft for future kernel module handling, based on
> a discussion at the kernel list and spiced up with a few thoughts of my
> own. It is available here: http://wiki.debian.org/KernelModulesPackaging
> 
> Could you please have a look and tell me what you think (or perhaps
> simply edit that wiki page directly)?

Notice that you again sided with Manoj, depite him never providing any
arguments in favour of not using the standard upstream mandated build symlink,
and since both of you prefered resulting to insults instead of reasoned
argumentations, i want to have no plan with any such plans as you have, so go
ahead, and break everything for all i care.

> I honestly have never ever used module-assistant, but suspect you have
> a lot of knowledge on ugly makefiles, and quite possibly have valuable
> input on this.

Yeah, sure, and if the input is not to you or Manoj's liking, we are idiots
and should go fuck ourselves hard, right, thanks.

Sven Luther

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

Re: [kernel] r4732 - in dists: sid trunk

2005-11-07 Thread Bastian Blank

On Mon, Nov 07, 2005 at 08:56:39AM +0100, Sven Luther wrote:
> Indeed. The idea was to move 2.6.14 to sid, and make the out-of-git tree the
> main development tree, which was exactly what *YOU* where advocating post
> 2.6.12, so i don't understand what you are complaining about.

I advocated using trunk/linux-2.6 for such development. This is
something different then removing the directory.

> Bastian what do you think about my idea of splitting infrastructure and
> per-version stuff ? I would hearthily like to hear your comments on that.

I have some concerns about it. Including that it makes the probability
to break much higher.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.


signature.asc
Description: Digital signature

Re: kernel-package and the build symlink ... I don't think we can continue to use k-p under current conditions.

2005-11-07 Thread Bastian Blank

On Mon, Nov 07, 2005 at 09:44:12AM +0100, Sven Luther wrote:
> These two show perfectly the real problem here, and there has been not a
> single technical argument in favour of his solution, and he just throwed away
> our own arguments.

Can you please call CTTE?

> I think it is a shame, but well, i refuse to lose more time fighting over
> this. What do other people of the kernel-team think about the issue ? 

I think you know my point of view about kernel-package.

Bastian

-- 
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8


signature.asc
Description: Digital signature

Re: [kernel] r4732 - in dists: sid trunk

On Mon, Nov 07, 2005 at 03:33:48PM +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2005 at 08:56:39AM +0100, Sven Luther wrote:
> > Indeed. The idea was to move 2.6.14 to sid, and make the out-of-git tree the
> > main development tree, which was exactly what *YOU* where advocating post
> > 2.6.12, so i don't understand what you are complaining about.
> 
> I advocated using trunk/linux-2.6 for such development. This is
> something different then removing the directory.

Well, i guess it was a mistake, since it was renamedto trunk/linux-2.6-git.

> > Bastian what do you think about my idea of splitting infrastructure and
> > per-version stuff ? I would hearthily like to hear your comments on that.
> 
> I have some concerns about it. Including that it makes the probability
> to break much higher.

Any idea of the kind of breakage you expect ? 

Friendly,

Sven Luther


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

Re: Care to comment on plan for module building?

On Mon, 7 Nov 2005 15:08:30 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Hi Eduard (and cc kernel list),
>> 
>> I have put together a draft for future kernel module handling,
>> based on a discussion at the kernel list and spiced up with a few
>> thoughts of my own. It is available here:
>> http://wiki.debian.org/KernelModulesPackaging
>> 
>> Could you please have a look and tell me what you think (or perhaps
>> simply edit that wiki page directly)?

> Notice that you again sided with Manoj, depite him never providing
> any arguments in favour of not using the standard upstream mandated
> build symlink,

his is a mnischaracterization of my position, but then, I have
 come to expect that.

The upstream convention of using 
 /lib/modules/$(uname -r)/build 
 is supported, has been supported, and shall be supported by
 kernel-package in the future.

> and since both of you prefered resulting to insults instead of
> reasoned argumentations, i want to have no plan with any such plans
> as you have, so go ahead, and break everything for all i care.

Packages built using kernel-package coherently are not
 broken. Just more FUD and slander.

manoj

-- 
"Some would sooner die than think.  In fact, they often do." Bertrand
Russell
Manoj Srivastava <[EMAIL PROTECTED]>
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]

Bug#335601: compaq arrays with ida

2005-11-07 Thread Erich Schubert

Hi,
> + if ($name =~ /^ida!c\d+d\d+$/) {
> + ModProbe::addModules ($actions, [ "cpqarray" ]);
> + $actions->add("mkbdev", $device->yspecial, sysname => $name);
> + return 1;
> + }

That is what I had inserted myself. Works fine.

best regards,
Erich Schubert
-- 
erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_
   There was never a good war or a bad peace. - Benjamin Franklin//\
  Bei dem Freunde halte still, der dich nur, nicht das deine will.   V_/_



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

automatic pending tag fixes

Jonas pointed out that tagging a closed bug pending seems to reopen it.
So, I've updated the commit hook to check if a bug is already marked
pending or is marked as done before adding the tag.  If you see problems
with this (misidentifying bugs as open, etc) please let me know.
-- 
dann frazier <[EMAIL PROTECTED]>


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

Bug#330583: Problem solved

On Mon, 2005-11-07 at 10:59 +0100, Boris Kleibl wrote:
> Uff, I solved the problem, but what happened?
> 
> As some days ago the new linux-image-2.6.14 was availlable, I did a 
> fresh debian sid installation. Booting the system shows the same problem 
> as mentioned above too. Hmmm! I tried to boot from a KNOPPIX 4.0.2 Live 
> CD, it started up to the desktop, but showed the harddisk as not 
> mountable! What the hell ... Perhaps the harddisk has a failure? I 
> checked the mentioned drive with seagate seatools - all tests succeeded 
> except the filesystem-test which shows a damaged master boot record. 
> Strange! I tested the drive with the linux and windows tools not showing 
> me any errors. So I deleted the vfat partition with windows and then the 
> reboot with debian/sid 2.6.14 succeeded! Yippee! Now I wrote a new 
> DOS-FAT on the drive, partitioned and formatted and all is ok.
> 
> What changed between kernel 2.6.12 and kernel 2.6.13/14 so that the 
> error got evidently?

Hard to say - could've been something in the code itself, or a result of
better hardware detection by either initramfs-tools or yaird.  Either
way, I'm glad your problem went away.  Thanks for letting us know.





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

Bug#330583: marked as done (linux-image-2.6.12-1-k7: pdc202xx - system doesn't boot with kernel 2.6.12)

Your message dated Mon, 07 Nov 2005 08:53:32 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#330583: Problem solved
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
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 28 Sep 2005 18:59:32 +
>From [EMAIL PROTECTED] Wed Sep 28 11:59:31 2005
Return-path: <[EMAIL PROTECTED]>
Received: from unet-lmtp.univie.ac.at (imap.unet.univie.ac.at) [131.130.221.38] 
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EKh9N-00064h-00; Wed, 28 Sep 2005 11:59:30 -0700
Received: from landsteiner.zifotronic 
(chello062178074188.25.11.univie.teleweb.at [62.178.74.188])
by imap.unet.univie.ac.at (8.12.10/8.12.10) with ESMTP id 
j8SIxJVc064290;
Wed, 28 Sep 2005 20:59:22 +0200
Message-Id: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Boris Kleibl <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: linux-image-2.6.12-1-k7: pdc202xx - system doesn't boot with kernel 
2.6.12
X-Mailer: reportbug 3.17
Date: Wed, 28 Sep 2005 20:59:18 +0200
X-DCC-ZID-Univie-Metrics: mx9.univie.ac.at 4248; bulk Body=1 Fuz1=1 Fuz2=56
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: linux-image-2.6.12-1-k7
Version: 2.6.12-10
Severity: critical
Justification: breaks the whole system


After installing kernel-image-2.6-k7_2.6.12-7 the system doesn't boot
anymore giving the following error messages:
   hdh: dma_intr: status = 0x51 { DriveReady SeekCompleteError}
   hdh: dma_intr: error = 0x10 { SectorIdNotFound }
   pdc202xx_new:
   ide: failed opcode was: unknown

The error appears for all of my 4 harddisks. This error comes also on 
kernel-image-2.6-k7_2.6.12-8,
kernel-image-2.6-k7_2.6.12-9 and kernel-image-2.6-k7_2.6.12-10, but
booting with a 2.6.11-k7 kernel gives no problem. I tried to give the
kernel-parameter ide=nodma, but this has no effekt.

I have a Promise Ultra 133 TX2 (pdc202xx_new) ATA-adapter with 4
harddisks (hde = WDC WD800JB (WindowsXP), hdf = Seagate ST360021A (Data),
hdg = Samsung SP0812N (Linux), hdh = Seagate ST330621A (Media)). My
mainboard is an ASRock K7VT4A Pro (VIA KT400A): hda=DVD-Rom,
hdc=DVD-Writer.

What is the problem? I found no issues googleing the internet.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages linux-image-2.6.12-1-k7 depends on:
ii  coreutils [fileutils] 5.2.1-2.1  The GNU core utilities
ii  initrd-tools  0.1.82 tools to create initrd image for p
ii  module-init-tools 3.2-pre9-1 tools for managing Linux kernel mo

linux-image-2.6.12-1-k7 recommends no packages.

-- no debconf information

---
Received: (at 330583-done) by bugs.debian.org; 7 Nov 2005 15:54:23 +
>From [EMAIL PROTECTED] Mon Nov 07 07:54:23 2005
Return-path: <[EMAIL PROTECTED]>
Received: from colo.lackof.org [198.49.126.79] 
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EZ9KA-0006hy-00; Mon, 07 Nov 2005 07:54:22 -0800
Received: from localhost (localhost [127.0.0.1])
by colo.lackof.org (Postfix) with ESMTP id 45D1A360004;
Mon,  7 Nov 2005 09:01:26 -0700 (MST)
Received: from colo.lackof.org ([127.0.0.1])
by localhost (colo.lackof.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 12020-06; Mon, 7 Nov 2005 09:01:25 -0700 (MST)
Received: from localhost (localhost [127.0.0.1])
by colo.lackof.org (Postfix) with ESMTP id 08AB2298026;
Mon,  7 Nov 2005 09:01:24 -0700 (MST)
Subject: Re: Bug#330583: Problem solved
From: dann frazier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], Boris Kleibl <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Content-Type: text/plain
Date: Mon, 07 Nov 2005 08:53:32 -0700
Message-Id: <[EMAIL PROTECTED]>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org
Delivered-To:

kernel-package (10.005) heading to experimental

Hi,

I think this fixes all issues that had been reported to
 me. 10.006 should head out to Sid tonight, or tomorrow.

manoj

kernel-package (10.005) experimental; urgency=low

* Bug fix: "kernel/image.postinst should mention GRUB", thanks to
  Martin Michlmayr. Well, I don't see why we should mention _any_ boot
  loader at all, so we are no longer biased against grub. (Closes: #336927)
* Bug fix: "kernel-package: Using dpkg --remove followed by dpkg
  --install does not restore the kernel package", thanks to Daniel
  Jacobowitz. Also: "kernel-package tells me we're being reinstalled AND
  updated". Actually, the installed/updated is just sematics; when you
  reinstall a kernel image you are updating it, and vice versa. The
  actual problem was that while the symbolic links were removed when the
  package was removed, dpkg passed the last-version-configured to the
  postinst, and we took that as evidence that the package had been
  installed before -- which, while true, did not take into account that
  the package was currently uninstalled. The fix is to always see if a
  missing symlink needs to be installed, and not touch existing
  symlinks.   (Closes: #336733,  #336517).
* Added kernel/pkg/headers/create_link as an example. The user can install
  it in the postinst.d directory to set up the /lib/modules/foo/build
  symlink to point to the kernel-headers. This is not needed, since the
  kernel-image postinst already checks in the /usr/src/ directory for an
  installed kernel headers package.
* Convert the image prerm scripts to debconf as well, the questions are
  asked if we try to remove the running kernel image, or if we are
  removing a kernel version mentioned in boot loader configuration.
* Have the minimal.mk not overwrite the control or the changelog file. 
* Added a whole slew of config files, and updated older ones, to bring
  the configurations offered up by default to be more in line with
  official kernels.
* Fixed substitutions in the kernel image package, there was a duplicate
  =B substitution. 
* Ran lintian on all the generated packages. Fixed FSF address in all
  the copyright notices, and fixed case in the templates file as
  well. This shall be the last experimental release, barring major
  problems. 

-- 
To do two things at once is to do neither. Publilius Syrus
Manoj Srivastava <[EMAIL PROTECTED]>
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: Care to comment on plan for module building?

On Mon, Nov 07, 2005 at 03:08:30PM +0100, Sven Luther wrote:
> On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > Hi Eduard (and cc kernel list),
> > 
> > I have put together a draft for future kernel module handling, based on
> > a discussion at the kernel list and spiced up with a few thoughts of my
> > own. It is available here: http://wiki.debian.org/KernelModulesPackaging
> > 
> > Could you please have a look and tell me what you think (or perhaps
> > simply edit that wiki page directly)?
> 
> Notice that you again sided with Manoj, depite him never providing any
> arguments in favour of not using the standard upstream mandated build symlink,
> and since both of you prefered resulting to insults instead of reasoned
> argumentations, i want to have no plan with any such plans as you have, so go
> ahead, and break everything for all i care.

I'm reluctantly entering this discussion, as it seems to be at an impass
to say the least. I must say that I really stuggle to understand why
everyone is so up-tight about this issue. I know there have been words
said in this thread and on IRC that might have been better not said, but
really, what is the issue? As far as I can see, the issue is that we
need to have a better framwork for out-of-tree module support.

There is the problem of the build/ link, which has historical behaviour
that dates back quite a number of years. Its current behaviour is not
entirely ideal from the point of view of users who only install
kernel-header packages. But it is quite useful for users who roll their
own kernel packages. And due to certain packaging limitations, it is
somewhat tedious to make it both have the historical behaviour that many
users might expect, and reach the expections of users with only
kernel-header packages installed. To be honest, its probably best to
stear clear of that link as much as possible when defining how modules
are packaged.

As for the wiki entry. I take it to be a work-in-progress document,
rather than doctrine. I personally don't find much at fault with what it
says. But I haven't been looking into the module build problem much.

I really think we should focus our energies on finding a module build
framework that works for packagers and uers. Rather firing harsh words
at each other.

-- 
Horms

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

Bug#337974: linux-image-2.6.12-1-k7: i2o controller probe failed err -110

2005-11-07 Thread Bill Gatliff


Package: linux-image-2.6.12-1-k7
Version: 2.6.12-10
Severity: critical
Justification: breaks the whole system


Kernel hangs at boot after failing to init iop0:

...
iop0: get status timeout
iop0: reset rejected trying to clear
iop0: unable to clear (status=0xbe)
i2o controller probe failed err -110
[hang]

The very same system boots fine under 2.6.8, where it uses dpti instead
of iop.  The dpti driver on 2.6.12 looks like it issues the same messages
as it does under 2.6.8 (suggests that it is working properly), but
apparently iop steps in shortly thereafter and tries (unsuccessfully) to
take over.

My dmesg from 2.6.8:

...
Loading Adaptec I2O RAID: Version 2.4 Build 5go
Detecting Adaptec I2O RAID controllers...
ACPI: PCI interrupt :00:0b.1[A] -> GSI 19 (level, low) -> IRQ 185
Adaptec I2O RAID controller 0 at f887f000 size=10 irq=185
dpti: If you have a lot of devices this could take a few minutes.
dpti0: Reading the hardware resource table.
TID 008  Vendor: ADAPTEC  Device: AIC-7899 Rev: 0001
TID 009  Vendor: ADAPTEC  Device: AIC-7899 Rev: 0001
TID 010  Vendor: ADAPTEC  Device: AIC-7899 Rev: 0001
TID 011  Vendor: ADAPTEC  Device: AIC-7899 Rev: 0001
TID 518  Vendor: IBM  Device: DDYS-T18350N Rev: SA2A
TID 523  Vendor: ADAPTEC  Device: RAID-5   Rev: 370F
scsi2 : Vendor: Adaptec  Model: 3410SFW:370F
Vendor: IBM   Model: DDYS-T18350N  Rev: SA2A
Type:   Direct-Access  ANSI SCSI revision: 03
Vendor: ADAPTEC   Model: RAID-5Rev: 370F
Type:   Direct-Access  ANSI SCSI revision: 02

A grep for "iop0" in my 2.6.8 dmesg produces no results.

I don't have a dmesg for 2.6.12, since the system won't boot.   :) 




-- System Information:
Debian Release: testing/unstable
 APT prefers testing
 APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.12-1-k7 depends on:
ii  coreutils [fileutils] 5.2.1-2.1  The GNU core utilities
ii  initrd-tools  0.1.84 tools to create initrd image for p
ii  module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo

linux-image-2.6.12-1-k7 recommends no packages.

-- no debconf information



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

Bug#278729: kernel-image-2.6-k7: kernel-image-2.6-k7 and 2.6-686 should

2005-11-07 Thread Richard Burton


2.6.8 is frozen solid for sarge. IF there is interest in having this
added for the etch kernels, can you please reasign it to linux-2.6


I think it should become a permanent addition to all 686 class kernels going 
forward, but I don't mind what point that starts at - unstable would be fine 
for me, but etch would be useful more widely. I wouldn't expect anything to 
change in sarge at this stage in it's release.


I'm afraid I don't know how to reassign a bug in BTS though, so I can't do 
that.


Richard.




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

Re: Care to comment on plan for module building?

On Mon, Nov 07, 2005 at 09:21:55AM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 15:08:30 +0100, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > On Mon, Nov 07, 2005 at 02:29:52PM +0100, Jonas Smedegaard wrote:
> >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >> 
> >> Hi Eduard (and cc kernel list),
> >> 
> >> I have put together a draft for future kernel module handling,
> >> based on a discussion at the kernel list and spiced up with a few
> >> thoughts of my own. It is available here:
> >> http://wiki.debian.org/KernelModulesPackaging
> >> 
> >> Could you please have a look and tell me what you think (or perhaps
> >> simply edit that wiki page directly)?
> 
> > Notice that you again sided with Manoj, depite him never providing
> > any arguments in favour of not using the standard upstream mandated
> > build symlink,
> 
> his is a mnischaracterization of my position, but then, I have
>  come to expect that.
> 
> The upstream convention of using 
>  /lib/modules/$(uname -r)/build 
>  is supported, has been supported, and shall be supported by
>  kernel-package in the future.

Indeed, and that is the real problem here, *YOU* decide unilaterally how the
kernel infrastructure shoud look, and disregard any discussion with the kernel
team. I still don't get why Jonas so suddenly took of with you and told me to
go fuck myself, but i still fail to see any kind of argument in what you
mentioned above.

> > and since both of you prefered resulting to insults instead of
> > reasoned argumentations, i want to have no plan with any such plans
> > as you have, so go ahead, and break everything for all i care.
> 
> Packages built using kernel-package coherently are not
>  broken. Just more FUD and slander.

Yeah, i will let the rest of the kernel team judge how unbroken the
kernel-package stuff is right now, but then we mostly override most of it
anyway.

Sven Luther


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

Re: Care to comment on plan for module building?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 8 Nov 2005 01:58:25 +0900
Horms <[EMAIL PROTECTED]> wrote:

> As for the wiki entry. I take it to be a work-in-progress document,
> rather than doctrine.

That was exactly the intention with that page.

I believe IRC is quite good at throwing ideas and opinions (too good,
perhaps?), but bad at glancing and getting a quick status on things.

I believe wiki is quite good at tracking the evolution of ideas - with
emphasis on "what is most recent of each idea".

Wiki pages are by design always in flux. So if need of doctrine, then
go for a static web page instead.

My concrete invitation with this email was for you to look at the wiki
page and either have it help you understand the discussion on IRC (if
interacting with that is what you want) or perhaps correct issues you
believe are wrong or weak on that page (either directly if you so like,
or by dropping an email to the list or yell out on IRC).

 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb47An7DbMsAkQLgRApG+AJ9h8OLS/C+CWt9bkqfDe+d/uONOsQCaAvyj
gheMnlCZ6RQz1IA6VzWY31Y=
=wDa6
-END PGP SIGNATURE-

Re: kernel-package (10.005) heading to experimental

On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
> Hi,
> 
> I think this fixes all issues that had been reported to
>  me. 10.006 should head out to Sid tonight, or tomorrow.

Which will probably break the kernel builds, no thanks.

Please refrain from uploading to unstable until at least there is a decision
taken on the build symlink issue.

Sven Luther

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

Bug#337974: linux-image-2.6.12-1-k7: i2o controller probe failed err -110

2005-11-07 Thread Norbert Tretkowski

* Bill Gatliff wrote:
> Package: linux-image-2.6.12-1-k7
> Version: 2.6.12-10

Can you please give 2.6.14-2 a try?

Thanks, Norbert


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

Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found

2005-11-07 Thread Erik van Konijnenburg

On Sat, Nov 05, 2005 at 03:30:26PM -0800, Beiad Dalton wrote:
> 'mesh' is the onboard oldworld SCSI host adapter; my installation
> happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root
> filesystem.

Could you post 'ls -lR /sys' to see what kind of input we have to
recognise this kind of host,

and could you give a hint which modules you expect to be loaded
to get this device operational?

Thanks,
Erik

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

Why I wanted Sven to fuck himself (Was: Care to comment on plan for module building?)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 7 Nov 2005 18:45:30 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> I still don't get why Jonas so suddenly took of with you and told me
> to go fuck myself

Let me illustrate through quoting IRC, since you seem to prefer that:

This is what directly led to my insulting you:

12:09 < jonas> svenl: Can we please focus on the topic?
12:10 < jonas> svenl: When who did (not) do what is irrelevant
12:10 < jonas> svenl: when what did (not) work is more interesting
12:10 < svenl> jonas: there is nothing to focus, Manoj is going to
either dictate his stuff unto us or we are going to drop k-p, there is
no middle way possible. 12:11 < jonas> svenl: End of discussion then.
Go fuck yourself. Hard!

So why am I that rude suddently, you ask? Well, let's go a little back
and find out why I asked you to change focus:

11:40 < Manoj> and kernel package ensure that  /lib/modules/$(uname
- -r)/build always works 11:41 < svenl> Manoj: except for official kernel
packages, riught ? 11:41 < Manoj> whether you have installed a kernel
image on the local machine, or just have a kernel headers installed,
k-p packages always ensure that  /lib/modules/$(uname -r)/build  works.
11:41 < jonas> so how to run a kernel without installing it? 11:41 <
Manoj> even for official kernels 11:41 < svenl> Manoj: not for official
Manoj> kernels. 11:41 < svenl> Manoj: since you are out to break it.
11:41 < Manoj> no matter what,  /lib/modules/$(uname -r)/build always
works 11:41 < Manoj> svenl: grow up, and get a clue.
..
11:42  * svenl ignores Manoj.

Why on earth do you repeat yourself instead of clarify _why_ you
believe Manoj makes exceptions regarding official kernels when he
himself claims it "always works"?

Ok, so Manoj gives up on you and calls you childish. I agree that your
discussion technique is indeed childish.

(if Manoj would have reason to believe that you did not understand that
"uname -r" implies "works only on running kernel", then I would call
his discussion technique mean - but I do not have reason to believe so)

Well well - let's continue...

11:42 < jonas> svenl: Do you ignore me as well?
11:42 < svenl> nope, you did not insult me like Manoj did.
11:42 < jonas> svenl: then talk with me, and _do_ ignore Manoj as you
claim to do :-P ..
11:43 < jonas> svenl: oh - and talk with me about the topic, _not_
about Manoj!

Here I ask you to stick to the technical topic and not get personal.

Have a look back - even further back than quoted here, if you still
have the backlog around - and check out how frequently you get
personal in the discussion compared to Manoj.

11:45 < svenl> jonas: well, what is there to say ? we right now have
the build symlink correctly set, it worked for the past 6 month, and we
where almost ready to push for the proposal, and the new k-p wants to
break it all for no reason. .. 11:47 < jonas> svenl: Define "symlink
correctly set" - there seem to be some confusion about what that is...

You obviously do not want to play along. I try dig into the technical
part, but...

11:55 < svenl> jonas: [..explanation..] Manoj wants to break this.
11:56 < svenl> jonas: and have all users and third party module
packages do the KSRC thingy.

...you insist on throwing accusations.

You seem to see KSRC as being a pet thing for Manoj, so throws that at
him (through answering me). Thing is, using KSRC is not "Manoj fanatism"
but a sane way to go beyond building modules for the running kernel,
so...

11:56 < Manoj> no, it wont just work. You have to set KSRC
11:56 < Manoj> and you can just set KSRC in my scheme to, no additional
work, and everything just works 11:56 < Manoj> see, if you do not have
the image isntalled, the uname -r trick does not work 11:57 < Manoj>
so, again, it is KSRC=/lib/modules/fo vs
KSRC=/usr/src/linux-headers-foo 11:57 < Manoj> What is the damned
difference?

Have a look at that. Even persistently provoced Manoj manages to stay
technical for several lines before slipping in a single "damned"...

11:58 < svenl> Manoj: so why are you being so stuborn about it ? 
11:59 < svenl> Just do it, we have been doing it for over 6 month now,
why didn't you complain back then ? 11:59 < svenl> this was amply and
publicly discussed.

You bring no technical arguments on the table...

11:59 < Manoj> since doing it my way, rather than a dance in the
postinst, requires far less code, and less code that can develop bugs
12:00 < Manoj> the way it stands, we have a clean, working, tested
solution, since kernel-package has had this behaviour forever 12:00 <
Manoj> I want less code, not more code

...Manoj tries again...

12:02 < svenl> Manoj: k-p and clean code are not something i would
mention in the same sentence.

...and again you provoke...

12:04 < Manoj> yeah, with your level of technical expertise, I would
expect no less 12:04 < jonas> svenl: The argument of "we have been
doing it for 6 months now" sounds odd compared to "the same as it has
been since 1996" 12:0

Re: Care to comment on plan for module building?

On Mon, 7 Nov 2005 18:45:30 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> Yeah, i will let the rest of the kernel team judge how unbroken the
> kernel-package stuff is right now, but then we mostly override most
> of it anyway.

With an attitude like this, I guess I can claim any issue
 where you have overridden the kernel-package behaviour  are yours to
 deal with.  The behaviour of the underlying kernel-package, if buggy,
 shall be fixed. If you change kernel-package, then fixing the overlay
 is your problem.

Again, I invite other people to have a conversation with me,
 as some have done on IRC.

manoj
-- 
The first version always gets thrown away.
Manoj Srivastava <[EMAIL PROTECTED]>
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: Why I wanted Sven to fuck himself (Was: Care to comment on plan for module building?)

On Mon, Nov 07, 2005 at 07:49:24PM +0100, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Mon, 7 Nov 2005 18:45:30 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > I still don't get why Jonas so suddenly took of with you and told me
> > to go fuck myself
> 
> Let me illustrate through quoting IRC, since you seem to prefer that:

No, this is no excuse to being rude. I don't know, maybe you speak another
kind of english than me, or have some other cultural bias against this kind of
language, but i am seriously offended.

> This is what directly led to my insulting you:
> 
> 12:09 < jonas> svenl: Can we please focus on the topic?
> 12:10 < jonas> svenl: When who did (not) do what is irrelevant
> 12:10 < jonas> svenl: when what did (not) work is more interesting
> 12:10 < svenl> jonas: there is nothing to focus, Manoj is going to
> either dictate his stuff unto us or we are going to drop k-p, there is
> no middle way possible. 12:11 < jonas> svenl: End of discussion then.

Upto here, well it was normal you have the right to your opinion as i do to
mine.

> Go fuck yourself. Hard!

This on the other hand was severly misplaced and i expect apologizes from your
part, not justifying yourself like you did above.

> So why am I that rude suddently, you ask? Well, let's go a little back
> and find out why I asked you to change focus:
> 
> 11:40 < Manoj> and kernel package ensure that  /lib/modules/$(uname
> - -r)/build always works 11:41 < svenl> Manoj: except for official kernel
> packages, riught ? 11:41 < Manoj> whether you have installed a kernel
> image on the local machine, or just have a kernel headers installed,
> k-p packages always ensure that  /lib/modules/$(uname -r)/build  works.
> 11:41 < jonas> so how to run a kernel without installing it? 11:41 <
> Manoj> even for official kernels 11:41 < svenl> Manoj: not for official
> Manoj> kernels. 11:41 < svenl> Manoj: since you are out to break it.
> 11:41 < Manoj> no matter what,  /lib/modules/$(uname -r)/build always
> works 11:41 < Manoj> svenl: grow up, and get a clue.
> ..
> 11:42  * svenl ignores Manoj.

Well, i may have gotten out of hand with Manoj and insisted too much, but in
no way have i been incorect and insulting, the worse i said was that Manoj was
stubborn, even saying that it was not necessarily a bad thing. This is no
excuse for bad-wording me like above, and i cannot work further with you like
this.

> Why on earth do you repeat yourself instead of clarify _why_ you
> believe Manoj makes exceptions regarding official kernels when he
> himself claims it "always works"?

Because the above was lead up by over a day of email exchanges here, where i
argued my point, provided reasonabable arguments, which where taken again by
folk like hch, willy or fjp this evening if i remember well, and Manoj did not
give any single real argument apart from the "i have been doing this since 96
and it will stay so". Also, you where not there when he pissed off lennert in
the most ugly way when he dared say he agreed with me.

> Ok, so Manoj gives up on you and calls you childish. I agree that your
> discussion technique is indeed childish.

And his is not ? I don't understand why you picked me out for your insults,
while Manoj did nothing different, and even worse never gave a single argument
when asked, and resorted to insults. I think your discernement is lacking on
this, but then given the way you insulted me, i guess i should not have
wondered why you sided with Manoj on this. Someone is insulting someone else,
so let's join the bully.

> (if Manoj would have reason to believe that you did not understand that
> "uname -r" implies "works only on running kernel", then I would call
> his discussion technique mean - but I do not have reason to believe so)

This claim alone is prove that you have no understanding of the situation. We
never argued about the uname -r, but about the build symlink. Sure, you can
get the version number with uname -r, but if you are not running the kernel,
you obvisouly need to know the version you want to build modules for, so where
is the problem.

This is obtained in official kernels by the flavours file, and even
kernel-package passes this info to the dir.d scripts so you could envisage
building modules at kernel install time just fine.

So, you had no clue, you saw him insulting me, you decided to join. 

And just to be curious, can you please cite a single technical argument by
Manoj ? I saw no such thing.

Sven Luther
> 
> 
> Well well - let's continue...
> 
> 11:42 < jonas> svenl: Do you ignore me as well?
> 11:42 < svenl> nope, you did not insult me like Manoj did.
> 11:42 < jonas> svenl: then talk with me, and _do_ ignore Manoj as you
> claim to do :-P ..
> 11:43 < jonas> svenl: oh - and talk with me about the topic, _not_
> about Manoj!
> 
> Here I ask you to stick to the technical topic and not get personal.
> 
> Have a look back - even further back than quoted here, if you still
> have

Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found

On Mon, Nov 07, 2005 at 07:48:32PM +0100, Erik van Konijnenburg wrote:
> On Sat, Nov 05, 2005 at 03:30:26PM -0800, Beiad Dalton wrote:
> > 'mesh' is the onboard oldworld SCSI host adapter; my installation
> > happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root
> > filesystem.
> 
> Could you post 'ls -lR /sys' to see what kind of input we have to
> recognise this kind of host,
> 
> and could you give a hint which modules you expect to be loaded
> to get this device operational?

at lest : 

/lib/modules/2.6.12-1-powerpc/kernel/drivers/scsi/mesh.ko

I guess the usual scsi disk stuff too.

Friendly,

Sven Luther



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

Re: kernel-package (10.005) heading to experimental

On Mon, 7 Nov 2005 18:51:09 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
>> Hi,
>> 
>> I think this fixes all issues that had been reported to me. 10.006
>> should head out to Sid tonight, or tomorrow.

> Which will probably break the kernel builds, no thanks.

> Please refrain from uploading to unstable until at least there is a
> decision taken on the build symlink issue.

If there is a bug in the way kernel-package behaves, please
 file a bug. The behaviour of kernel-package towards the build symlink
 has not changed in years -- until now, when more care is taken to
 ensure /lib/modules/$(uname -r)/build is valid in all possible use
 cases.

If there are bugs in the way kernel-package generates kernel
 packages from source, or in the way these generated packages
 interact, when using the packages  as generated, I'll take not
 uploading to Sid under advicement.

So, please test the kernel-package, and file bug reports.

manoj
-- 
As long as we're going to reinvent the wheel again, we might as well
try making it round this time.- Mike Dennison
Manoj Srivastava <[EMAIL PROTECTED]>
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: Care to comment on plan for module building?

On Mon, Nov 07, 2005 at 01:14:25PM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 18:45:30 +0100, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > Yeah, i will let the rest of the kernel team judge how unbroken the
> > kernel-package stuff is right now, but then we mostly override most
> > of it anyway.
> 
> With an attitude like this, I guess I can claim any issue
>  where you have overridden the kernel-package behaviour  are yours to

You would be happy to know that i did personally touch none of that. They are
mostly the work of Jurij, Andres and Bastian, also based on work by Jens, and
many others over the years. If you really cared, you would have noticed this
years ago.

>  deal with.  The behaviour of the underlying kernel-package, if buggy,
>  shall be fixed. If you change kernel-package, then fixing the overlay
>  is your problem.

> Again, I invite other people to have a conversation with me,
>  as some have done on IRC.

Yeah, did you also insult them ? Did you also gave them no other argument than
"i have been doing that since 96" ? 

If so, why did you chose to serve only that to me ? 

Friendly,

Sven Luther

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

Re: kernel-package (10.005) heading to experimental

On Mon, Nov 07, 2005 at 01:18:32PM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 18:51:09 +0100, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
> >> Hi,
> >> 
> >> I think this fixes all issues that had been reported to me. 10.006
> >> should head out to Sid tonight, or tomorrow.
> 
> > Which will probably break the kernel builds, no thanks.
> 
> > Please refrain from uploading to unstable until at least there is a
> > decision taken on the build symlink issue.
> 
> If there is a bug in the way kernel-package behaves, please
>  file a bug. The behaviour of kernel-package towards the build symlink
>  has not changed in years -- until now, when more care is taken to
>  ensure /lib/modules/$(uname -r)/build is valid in all possible use
>  cases.

Yeah, we would have more time to test if we had not to fight for every trivial
issue with you just to be insulted in the end.

I did test the build, did i not, and provided you the failure message on irc.

Sven Luther


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

Re: kernel-package (10.005) heading to experimental

On Mon, 7 Nov 2005 20:39:11 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Mon, Nov 07, 2005 at 01:18:32PM -0600, Manoj Srivastava wrote:
>> On Mon, 7 Nov 2005 18:51:09 +0100, Sven Luther
>> <[EMAIL PROTECTED]> said:
>> 
>> > On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
>> >> Hi,
>> >> 
>> >> I think this fixes all issues that had been reported to
>> >> me. 10.006 should head out to Sid tonight, or tomorrow.
>> 
>> > Which will probably break the kernel builds, no thanks.
>> 
>> > Please refrain from uploading to unstable until at least there is
>> > a decision taken on the build symlink issue.
>> 
>> If there is a bug in the way kernel-package behaves, please file a
>> bug. The behaviour of kernel-package towards the build symlink has
>> not changed in years -- until now, when more care is taken to
>> ensure /lib/modules/$(uname -r)/build is valid in all possible use
>> cases.

> Yeah, we would have more time to test if we had not to fight for
> every trivial issue with you just to be insulted in the end.

I have been sending uploads to experimental since the 25th of
 october.  So there has been no time to test anything since then?
 Also, the behaviour of kernel-package has not changed, not for years,
 and I have been talking about my plans and intentions on this list
 for at least a couple of months now. There was no time to comment for
 months? 

Seems like you are spending a lot of time fighting.

> I did test the build, did i not, and provided you the failure
> message on irc.

Right. And I think the last couple of uploads should have that
 bug fixed. See, when you tell me about bugs, they get fixed.

manoj
-- 
Them as has, gets.
Manoj Srivastava <[EMAIL PROTECTED]>
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]

Bug#337855: yaird fails with error "Could not read output for /usr/bin/ldd ... (fatal)"

2005-11-07 Thread Erik van Konijnenburg

On Sun, Nov 06, 2005 at 11:22:35PM +0100, Walter Hofmann wrote:
> I have a yaird configuration which includes /bin/busybox, a statically
> linked executable. yaird calls "/usr/bin/ldd /bin/busybox", which
> returns with exit status 1 because the file is not a dynamic executable.
> yaird checks for this exit code and stops because it is not zero.

> The same problem seems to happen with script files.

Ouch.  You are correct; this is a regression introduced with adding getOutput
in Yaird 0.0.11-11.  

As an aside, /bin/busybox is a dynamic executable on this sid box;
where did your version originate?


Regards,
Erik




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

Re: kernel-package (10.005) heading to experimental

On Mon, Nov 07, 2005 at 02:08:36PM -0600, Manoj Srivastava wrote:
> On Mon, 7 Nov 2005 20:39:11 +0100, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > On Mon, Nov 07, 2005 at 01:18:32PM -0600, Manoj Srivastava wrote:
> >> On Mon, 7 Nov 2005 18:51:09 +0100, Sven Luther
> >> <[EMAIL PROTECTED]> said:
> >> 
> >> > On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
> >> >> Hi,
> >> >> 
> >> >> I think this fixes all issues that had been reported to
> >> >> me. 10.006 should head out to Sid tonight, or tomorrow.
> >> 
> >> > Which will probably break the kernel builds, no thanks.
> >> 
> >> > Please refrain from uploading to unstable until at least there is
> >> > a decision taken on the build symlink issue.
> >> 
> >> If there is a bug in the way kernel-package behaves, please file a
> >> bug. The behaviour of kernel-package towards the build symlink has
> >> not changed in years -- until now, when more care is taken to
> >> ensure /lib/modules/$(uname -r)/build is valid in all possible use
> >> cases.
> 
> > Yeah, we would have more time to test if we had not to fight for
> > every trivial issue with you just to be insulted in the end.
> 
> I have been sending uploads to experimental since the 25th of
>  october.  So there has been no time to test anything since then?

Well, Simon Horman did test an earlier version, and i did test 10.004, but
seriously, i have very little motivation to do more testings if i am returned
with insults.

>  Also, the behaviour of kernel-package has not changed, not for years,
>  and I have been talking about my plans and intentions on this list

Yeah, i remember you telling me around december 2003 about the big reorg, but
you where not accepting changes because of the imminent sarge release :)

>  for at least a couple of months now. There was no time to comment for
>  months? 


Well, have i not contributed comments back then ? 

> > I did test the build, did i not, and provided you the failure
> > message on irc.
> 
> Right. And I think the last couple of uploads should have that
>  bug fixed. See, when you tell me about bugs, they get fixed.

Yeah, a full build is around 8 hours or so though, and i have X packages and
mesa also building on that box, so ...

Friendly,

Sven Luther


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

Bug#252335: "tc filter ls .." makes a kernel oops

2005-11-07 Thread Samuel Thibault

Hi,

Isn't the bug resolved ? The proposed patch is now in 2.4.27...

Regards,
Samuel


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

Bug#337855: yaird fails with error "Could not read output for /usr/bin/ldd ... (fatal)"

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 7 Nov 2005 21:05:12 +0100
Erik van Konijnenburg <[EMAIL PROTECTED]> wrote:

> As an aside, /bin/busybox is a dynamic executable on this sid box;
> where did your version originate?

Probably installed the package busybox-static ;-)


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb8NWn7DbMsAkQLgRAmH8AJ4zdCH1fPMmDaeRGhuFtBRoK4pN2ACeOf1m
8Lwc0cFk9MxrZXo2ODZwGSs=
=CKoD
-END PGP SIGNATURE-

Bug#338030: yaird error: Could not read output for /sbin/lvdisplay -c (fatal)

2005-11-07 Thread Bill Gatliff


Package: yaird
Version: 0.0.11-11
Severity: grave
Justification: renders package unusable



# apt-get install linux-image-2.6.14-1-k7
Reading package lists... Done
Building dependency tree... Done
linux-image-2.6.14-1-k7 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 296 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up linux-image-2.6.14-1-k7 (2.6.14-2) ...
Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd
/usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs.
yaird error: Could not read output for /sbin/lvdisplay -c (fatal)
Failed to create initrd image.
dpkg: error processing linux-image-2.6.14-1-k7 (--configure):
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 linux-image-2.6.14-1-k7
 E: Sub-process /usr/bin/dpkg returned an error code (1)

# lvdisplay -c
 /dev/0/0:0:3:1:-1:1:426778624:52097:-1:0:0:254:0
 /dev/sda1: Checksum error
 Couldn't read volume group metadata.
 Volume group "vg0" not found

# lvs
 /dev/sda1: Checksum error
 Couldn't read volume group metadata.
 Volume group "vg0" not found
 LV   VG   Attr   LSize   Origin Snap%  Move Copy%
 00-wi-ao 203.50G
	  
# lvscan

 ACTIVE'/dev/0/0' [203.50 GB] inherit
 /dev/sda1: Checksum error
 Couldn't read volume group metadata.
 Volume group "vg0" not found

# mount
/dev/mapper/0-0 on / type ext3 (rw,errors=remount-ro)
/dev/sda1 on /boot type ext3 (rw)
/dev/sda5 on /tmp type ext3 (rw)
/dev/hda1 on /mnt/backup type ext3 (ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)


	  



-- System Information:
Debian Release: testing/unstable
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages yaird depends on:
ii  cpio 2.6-9   GNU cpio -- a program to manage ar
ii  dash 0.5.2-7 The Debian Almquist Shell
ii  libc62.3.5-6 GNU C Library: Shared libraries an
ii  libhtml-template-perl2.6-2   HTML::Template : A module for usin
ii  libparse-recdescent-perl 1.94.free-1 Generates recursive-descent parser
ii  perl 5.8.7-7 Larry Wall's Practical Extraction 


yaird recommends no packages.

-- no debconf information



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

Bug#292328: It works fine with linux-image-2.6.14-1-686

2005-11-07 Thread Cesar Martinez Izquierdo

This problem (which was present in all kernels starting from 2.6.9 kernels) is 
not present in linux-image-2.6.14-1-686. It works fine for me.

  César

Bug#336869: the Philips is a CD writer and A DVD WRITER

2005-11-07 Thread Dan Jacobson

But as lshw shows, the Philips is a CD writer and a _DVD WRITER_,
not just DVD ROM!

 *-cdrom:0
   description: DVD writer
   product: PHILIPS DVDR1648P1


As far as patches to fix the problem, I'm no kernel hacker.


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

Re: [kernel] r4732 - in dists: sid trunk

On Mon, 2005-11-07 at 08:26 +0100, Bastian Blank wrote:
> On Sun, Nov 06, 2005 at 05:45:16PM -0700, dann frazier wrote:
> > > Hu? It disappeared without notice.
> > If I'd been working on the tree at the time, I probably would've whined
> > then too.
> 
> The development version disappeared.
> 
> > A little more ranting... I don't like that we're using a temporal layout
> > because it means moves are always happening.  svn lets us move stuff,
> > which is a great feature, but the way we're using it is an abuse of this
> > feature (imo).
> 
> Hu? Why does it disappear in the first time?
> 
> > To avoid being one that complains without providing an alternate
> > suggestion - what if we tracked things by upstream kernel version?
> > 
> > linux-2.6/2.6.12/
> > linux-2.6/2.6.14/
> 
> Please explain what this will fix?

Its one way to prevent trees from being moved around in svn.  2.6.14
would always be under linux-2.6/2.6.14 (or whatever) - at least as long
as that tree is still being maintained.  I wouldn't have to worry about
an svn up moving a tree out from under me, which happens way too often
these days.




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

Re: [kernel] r4732 - in dists: sid trunk

On Mon, 2005-11-07 at 08:30 +0100, Bastian Blank wrote:
> On Mon, Nov 07, 2005 at 08:02:35AM +0100, Sven Luther wrote:
> > I have another proposal, and it involves symlinks. Simon has shown that 
> > using
> > symlinks inside svn is fully supported by svn, so let's try that.
> 
> This is incorrect. Symlinks are dumb pointers.
> 
> > The plan goes as follows :
> > /dists/versions/2.6.12
> > /dists/versions/2.6.14
> > /dists/versions/2.6.15-rcX
> > /dists/versions/2.6.15
> > 
> > /dists/versions/2.6-git
> 
> WHAT does this fix, except that version disappear faster and you go into
> a merge mess I wanted to avoid.

Why do you say that versions disappear faster?  I don't understand that
statement.

And what is the merge mess you are trying to avoid?  I know that keeping
multiple trees in sync is complex, but I don't see how this introduces
complexity.

> > This should solve everyone's problem, i believe.
> 
> Not until someone discribed what the problem is that this should solve.
> The problem is, that someone insists into removing the _main
> development_ tree.

I think we may just have different ways of looking at this.  I spend my
time porting patches between trees, so to me, every upstream release
that's still maintained is logically a separate branch.  Maybe the
current scheme makes more sense for you folks working on the actual
packaging.

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

Bug#338030: yaird error: Could not read output for /sbin/lvdisplay -c (fatal)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 07 Nov 2005 15:45:14 -0600
Bill Gatliff <[EMAIL PROTECTED]> wrote:

> yaird error: Could not read output for /sbin/lvdisplay -c (fatal)
> Failed to create initrd image.

> # lvdisplay -c
>   /dev/0/0:0:3:1:-1:1:426778624:52097:-1:0:0:254:0
>   /dev/sda1: Checksum error
>   Couldn't read volume group metadata.
>   Volume group "vg0" not found

lvdisplay belongs to lvm2 I believe. Why do you file this bugreport
against yaird? It seems to me that you have problems with your LVM
headers or something.


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDb9Vtn7DbMsAkQLgRAkzVAJ9lHp+4pFo+6a6EVqvIyGstFKYJGACeNsDc
Yl6/3xNZ4NQhMlMqobQZwpA=
=t96i
-END PGP SIGNATURE-

Bug#338089: New aic7xxx driver fails spectacularly on 2940UW

2005-11-07 Thread Graham Knap

Package: linux-image-2.6.14-1-686
Version: 2.6.14-2

Recent versions of the aic7xxx driver will not boot on my secondary PC.
The 2.6.8 kernel shipped with sarge works perfectly, but neither the
2.6.12 kernel in testing nor the 2.6.14 kernel in unstable will boot.

This is an older system: 
Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP
Adaptec 2940UW, IBM DDYS-T09170 (9GB disk)

I can't understand what exactly is failing, but I will attach a boot
log. (So null modem cables *are* still useful for something!)

I've tried adding "aic7xxx=dv:{0}" to the boot arguments but that
doesn't seem to make a difference. Also, "aic7xxx=verbose" doesn't seem
to do anything either.

I don't know if this makes a difference but my 2940UW reports its BIOS
revision as "1.34.3" during POST.

Any help would be much appreciated.

-- grahamLinux version 2.6.14-1-686 (Debian 2.6.14-2) ([EMAIL PROTECTED]) (gcc version 
4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Tue Nov 1 15:51:43 JST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 17ffd000 (usable)
 BIOS-e820: 17ffd000 - 17fff000 (ACPI data)
 BIOS-e820: 17fff000 - 1800 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
0MB HIGHMEM available.
383MB LOWMEM available.
DMI 2.0 present.
ACPI: PM-Timer IO Port: 0xe408
Allocating PCI resources starting at 2000 (gap: 1800:e7ff)
Built 1 zonelists
Kernel command line: root=/dev/sda3 ro single console=tty0 console=ttyS1,38400n8
Local APIC disabled by BIOS -- you can enable it with "lapic"
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 501.254 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 385200k/393204k available (1803k kernel code, 7432k reserved, 512k 
data, 180k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1002.82 BogoMIPS (lpj=501412)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel Celeron (Mendocino) stepping 05
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs... it is
softlockup thread 0 started up.
Freeing initrd memory: 1176k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region e400-e43f claimed by PIIX4 ACPI
PCI quirk: region e800-e81f claimed by PIIX4 SMB
PIIX4 devres B PIO at 0290-0297
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved
pnp: 00:01: ioport range 0xe800-0xe80f has been reserved
pnp: 00:01: ioport range 0x294-0x297 has been reserved
PCI: Bridge: :00:01.0
  IO window: disabled.
  MEM window: d600-d7df
  PREFETCH window: d7f0-e3ff
Simple Boot Flag at 0x46 set to 0x1
audit: initializing netlink socket (disabled)
audit(1131398011.104:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
pnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3

Re: Packaging of modules which are in official kernel

On Mon, Nov 07, 2005 at 12:32:23PM +0100, Sebastian Ley wrote:
> Hi,
> 
> I am the maintainer of the ipw2100 module package. That module is now
> included in the kernel as of version 2.6.14. For the time being I want to
> keep the package and decide later whether to drop it.
> 
> The question is however, where to put the modules such that they do not
> conflict with the modules from the kernel. The related bugreport is
> #337920.
> 
> I just want to verify that the submitter's solution is the right way to go.
> 
> Please CC me on replies, as I am not subscribed to this list.

That seems reasonable to me. Can others comment?

-- 
Horms


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

Re: Re: Re: I can't build Modules.debs with linuxheaders 2.6.12-1-k7

On Mon, Nov 07, 2005 at 02:23:41PM +0100, Sébastien Platel wrote:
> I'm trying to compile nvidia kernel driver by getting source from debian 
> repository, decompressing it using "tar -zxvf XXX" and then using
> 
> cd /usr/src/linux-headers-2.6.12-1686
> make-kpkg modules_image
> 
> since then I found another way to compile this module following this 
> document http://www.coagul.org/article.php3?id_article=346 (as you can't 
> read french I can describe it quickly saying that after a few 
> environnement variables setup and cd into the module source the line 
> "debian/rules binary_modules" compiles the debian package

I think that it is fair to say that the problem is not that the
modules don't compile, but that its not entirely obvious how
to make them compile.

The kernel-team is currently working on making this situation 
better, however as you might note if you scan debian-kernel,
we are far from consensus on the issue.

-- 
Horms


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

Re: kernel-package (10.005) heading to experimental

On Mon, Nov 07, 2005 at 06:51:09PM +0100, Sven Luther wrote:
> On Mon, Nov 07, 2005 at 10:47:12AM -0600, Manoj Srivastava wrote:
> > Hi,
> > 
> > I think this fixes all issues that had been reported to
> >  me. 10.006 should head out to Sid tonight, or tomorrow.
> 
> Which will probably break the kernel builds, no thanks.
> 
> Please refrain from uploading to unstable until at least there is a decision
> taken on the build symlink issue.

Sven, I don't believe that 10.006 changes the build symlink behaviour
from what is currently in sid. So that really is an othogonal issue.

Manoj, as I mentioned just now on IRC, I am seeing an issue
with ppc builds from trunk/experimental using 10.004. I'd like
a chance to look through that more throrougly before you upload.
Its probably not a kernel-package problem, but if it is, it could
put the kernel-team in a bit of a pickle with regards to and
releases in the near future.

-- 
Horms

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

Bug#278729: kernel-image-2.6-k7: kernel-image-2.6-k7 and 2.6-686 should

reassign 278729 linux-2.6
retitle 278729 some i386 images should recommend libc6-i686
thanks

On Mon, Nov 07, 2005 at 04:58:36PM +, Richard Burton wrote:
> >2.6.8 is frozen solid for sarge. IF there is interest in having this
> >added for the etch kernels, can you please reasign it to linux-2.6
> 
> I think it should become a permanent addition to all 686 class kernels 
> going forward, but I don't mind what point that starts at - unstable would 
> be fine for me, but etch would be useful more widely. I wouldn't expect 
> anything to change in sarge at this stage in it's release.

I think Etch would be an appropriate place for this.
Though as I mentioned earlier, it requires some slight
reengineering of the build scripts, if I'm not mistaken.

Waldi, can you coment on how to add a recommends to
images on a per-flavour basis?

> I'm afraid I don't know how to reassign a bug in BTS though, so I can't do 
> that.

IF your are interested, that is covered on http://bugs.debian.org,
but breifly, CC [EMAIL PROTECTED] and start the message as I have above.

-- 
Horms

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

Bug#330583: Problem solved

On Mon, Nov 07, 2005 at 10:59:50AM +0100, Boris Kleibl wrote:
> Uff, I solved the problem, but what happened?

Lots of things changed between 2.6.12 and 2.6.14.
If you are really interested you could hunt through the
changelogs, patches and git-commits. But its probably
enough just to know if it is fixed in 2.6.14-2. Is that
the case?

-- 
Horms


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

Bug#338030: yaird error: Could not read output for /sbin/lvdisplay -c (fatal)

2005-11-07 Thread Bill Gatliff


Jonas Smedegaard wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 07 Nov 2005 15:45:14 -0600
Bill Gatliff <[EMAIL PROTECTED]> wrote:

 


yaird error: Could not read output for /sbin/lvdisplay -c (fatal)
Failed to create initrd image.
   



 


# lvdisplay -c
 /dev/0/0:0:3:1:-1:1:426778624:52097:-1:0:0:254:0
 /dev/sda1: Checksum error
 Couldn't read volume group metadata.
 Volume group "vg0" not found
   



lvdisplay belongs to lvm2 I believe. Why do you file this bugreport
against yaird? It seems to me that you have problems with your LVM
headers or something.
 



Alright.  I'll send a report to lvm2.


b.g.

--
Bill Gatliff
[EMAIL PROTECTED]



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

Bug#337713: [netfilter-core] [PATCH] Null pointer access in nf_queue()

On Mon, Nov 07, 2005 at 09:55:56AM +0100, Harald Welte wrote:
> On Mon, Nov 07, 2005 at 05:39:53PM +0900, Horms wrote:
> 
> > I did some disasembling fun and games, and I'm pretty sure the patch
> > below will fix your problem. I'll fire of a build, I'd be greateful if
> > you could test it.
> 
> Sorry, Horms, you must have missed my previos fix (that does exactly the
> same).  I've already posted it to netdev, and IIRC, Arnaldo has merged
> it for net-2.6.15.
> 
> Sorry for not Cc'ing you with the fix, it seems like I only reported
> back to bugzilla :(

No problem, it would have saved me some hunting, but actually it was
quite fun. Glad to hear the problem is fixed.

-- 
Horms


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

Bug#338089: New aic7xxx driver fails spectacularly on 2940UW

On Mon, Nov 07, 2005 at 09:45:23PM -0500, Graham Knap wrote:
> Package: linux-image-2.6.14-1-686
> Version: 2.6.14-2
> 
> Recent versions of the aic7xxx driver will not boot on my secondary PC.
> The 2.6.8 kernel shipped with sarge works perfectly, but neither the
> 2.6.12 kernel in testing nor the 2.6.14 kernel in unstable will boot.
> 
> This is an older system: 
> Asus P2L-B, Celeron 500MHz, 384MB RAM, GeForce2 MX AGP
> Adaptec 2940UW, IBM DDYS-T09170 (9GB disk)
> 
> I can't understand what exactly is failing, but I will attach a boot
> log. (So null modem cables *are* still useful for something!)
> 
> I've tried adding "aic7xxx=dv:{0}" to the boot arguments but that
> doesn't seem to make a difference. Also, "aic7xxx=verbose" doesn't seem
> to do anything either.
> 
> I don't know if this makes a difference but my 2940UW reports its BIOS
> revision as "1.34.3" during POST.
> 
> Any help would be much appreciated.

Hi Graham, 

thanks for your detailed report. This does smell a lot like a driver
bug, and as such, its proably best passed onto the upstream maintainers.
As such I've CCed James Bottomley and linux-scsi for comment.

The other main possiblility, is that perhaps the aic7xxx_old driver would
work. Or perhaps some other module loading foo, though its seems the
module is loaded fine, it just doesn't like your card very much.

Content-Description: 2066060778-bootlog-2.6.14.txt
> Linux version 2.6.14-1-686 (Debian 2.6.14-2) ([EMAIL PROTECTED]) (gcc version 
> 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Tue Nov 1 15:51:43 JST 2005
> BIOS-provided physical RAM map:
>  BIOS-e820:  - 0009fc00 (usable)
>  BIOS-e820: 0009fc00 - 000a (reserved)
>  BIOS-e820: 000f - 0010 (reserved)
>  BIOS-e820: 0010 - 17ffd000 (usable)
>  BIOS-e820: 17ffd000 - 17fff000 (ACPI data)
>  BIOS-e820: 17fff000 - 1800 (ACPI NVS)
>  BIOS-e820:  - 0001 (reserved)
> 0MB HIGHMEM available.
> 383MB LOWMEM available.
> DMI 2.0 present.
> ACPI: PM-Timer IO Port: 0xe408
> Allocating PCI resources starting at 2000 (gap: 1800:e7ff)
> Built 1 zonelists
> Kernel command line: root=/dev/sda3 ro single console=tty0 
> console=ttyS1,38400n8
> Local APIC disabled by BIOS -- you can enable it with "lapic"
> Initializing CPU#0
> PID hash table entries: 2048 (order: 11, 32768 bytes)
> Detected 501.254 MHz processor.
> Using pmtmr for high-res timesource
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Memory: 385200k/393204k available (1803k kernel code, 7432k reserved, 512k 
> data, 180k init, 0k highmem)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> Calibrating delay using timer specific routine.. 1002.82 BogoMIPS (lpj=501412)
> Security Framework v1.0.0 initialized
> SELinux:  Disabled at boot.
> Capability LSM initialized
> Mount-cache hash table entries: 512
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 128K
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> mtrr: v2.0 (20020519)
> CPU: Intel Celeron (Mendocino) stepping 05
> Enabling fast FPU save and restore... done.
> Checking 'hlt' instruction... OK.
> ACPI: setting ELCR to 0200 (from 0a00)
> checking if image is initramfs... it is
> softlockup thread 0 started up.
> Freeing initrd memory: 1176k freed
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: PCI BIOS revision 2.10 entry at 0xf06d0, last bus=1
> PCI: Using configuration type 1
> ACPI: Subsystem revision 20050902
> ACPI: Interpreter enabled
> ACPI: Using PIC for interrupt routing
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
> ACPI: PCI Root Bridge [PCI0] (:00)
> PCI: Probing PCI hardware (bus 00)
> ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
> PCI quirk: region e400-e43f claimed by PIIX4 ACPI
> PCI quirk: region e800-e81f claimed by PIIX4 SMB
> PIIX4 devres B PIO at 0290-0297
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> pnp: PnP ACPI: found 12 devices
> PnPBIOS: Disabled by ACPI PNP
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
> pnp: 00:01: ioport range 0xe400-0xe43f could not be reserved
> pnp: 00:01: ioport range 0xe800-0xe80f has been reserved
> pnp: 00:01: ioport range 0x294-0x297 has been reserved
> PCI: Bridge: :00:01.0
>   IO window: disabled.
>   MEM window: d600-d7df
>   PREFETCH window: d7f0-e3ff
> Simple Boot Flag at 0x46 set to 0x1
> audit: initializing netlink socket (disable

Processed: Re: Bug#278729: kernel-image-2.6-k7: kernel-image-2.6-k7 and 2.6-686 should

Processing commands for [EMAIL PROTECTED]:

> reassign 278729 linux-2.6
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should 
recommend libc6-i686
Bug reassigned from package `kernel-image-2.6-k7' to `linux-2.6'.

> retitle 278729 some i386 images should recommend libc6-i686
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should 
recommend libc6-i686
Changed Bug title.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#252335: marked as done (kernel-image-2.4.26-1-686: "tc filter ls .." makes a kernel oops)

Your message dated Tue, 8 Nov 2005 11:42:11 +0900
with message-id <[EMAIL PROTECTED]>
and subject line Bug#252335: "tc filter ls .." makes a kernel oops
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
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 2 Jun 2004 19:34:10 +
>From [EMAIL PROTECTED] Wed Jun 02 12:34:09 2004
Return-path: <[EMAIL PROTECTED]>
Received: from smtp.itanets.com [216.12.200.84] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1BVbV3-00010P-00; Wed, 02 Jun 2004 12:34:09 -0700
Received: (qmail 12703 invoked by uid 104); 2 Jun 2004 19:34:08 -
Received: from [EMAIL PROTECTED] by smtp.itanets.com by uid 107 with 
qmail-scanner-1.16 
 (clamscan: 0.67.  Clear:. 
 Processed in 1.83024 secs); 02 Jun 2004 19:34:08 -
Received: from office.itanets.com (HELO deb-off.itanets.com) (193.200.14.52)
  by smtp.itanets.com with SMTP; 2 Jun 2004 19:34:06 -
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Delian Krustev <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: kernel-image-2.4.26-1-686: "tc filter ls .." makes a kernel oops
Bcc: Delian Krustev <[EMAIL PROTECTED]>
X-Mailer: reportbug 2.61
Date: Wed, 02 Jun 2004 22:33:53 +0300
X-Qmail-Scanner-Message-ID: <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 

Package: kernel-image-2.4.26-1-686
Version: 2.4.26-1
Severity: normal
Tags: sid



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-dm-pom-1
Locale: LANG=C, LC_CTYPE=C

Versions of packages kernel-image-2.4.26-1-686 depends on:
ii  coreutils [fileutils] 5.0.91-2   The GNU core utilities
ii  fileutils 5.0.91-2   The GNU file management utilities 
ii  initrd-tools  0.1.70 tools to create initrd image for p
ii  modutils  2.4.26-1   Linux module utilities

-- no debconf information
deb-off:~# tc qdisc add dev eth0 root tbf rate 1024kbit latency 10ms burst 4096
deb-off:~# tc filter ls dev eth0

Unable to handle kernel NULL pointer dereference at virtual address 
printing eip:

*pde = 
Oops: 
CPU:0
EIP:0010:[<>]Not tainted
EFLAGS: 00010246
eax:    ebx: c688d180   ecx: c6d38840   edx: c8854ba0
esi: c7078400   edi: c1560460   ebp: c6bf8af0   esp: c0c1dc40
ds: 0018   es: 0018   ss: 0018
Process tc (pid: 825, stackpage=c0c1d000)
Stack: c01cef4a c7f94e60   c010905c c0c1dc5c 0002 
   c8854ba0  c7f94e60 c688d180 01f0 c764fa40 c58657c0 c01bd8a4
   c11876a8 01f0 c58657c0 c1560460 c688d180 c1560460 c1560460 c58657c0
Call Trace:[] [] [] [] []
  [] [] [] [] [] []
  [] [] [] [] [] []
  [] [] [] [] [] []
  [] [] [] []

Code:  Bad EIP value.
 Segmentation fault

-

I have the following patches applied to the kernel:

1. CONNMARK from the latest patch-o-matic when this kernel package was
   released. It's available from netfilter.org

2.linux-2.4.22-VFS-lock.patch
  linux-2.4.22-devmapper-ioctl.patch
These are available from sistina.com (they've released patches for 4.26
probably a month later).

I wonder whether someone could reproduce this ?

---
Received: (at 252335-done) by bugs.debian.org; 8 Nov 2005 03:35:05 +
>From [EMAIL PROTECTED] Mon Nov 07 19:35:05 2005
Return-path: <[EMAIL PROTECTED]>
Received: from koto.vergenet.net [210.128.90.7] 
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EZKGH-0006Vh-00; Mon, 07 Nov 2005 19:35:05 -0800
Received: by koto.vergenet.net (Postfix, from userid 7100)
id 841EE3404F; Tue,  8 Nov 2005 12:34:34 +0900 (JST)
Date: Tue, 8 Nov 2005 11:42:11 +0900
From: Horms <[EMAIL PROTECTED]>
To: Samuel Thibault <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: Bug#252335: "tc filter ls .." makes a kernel oops
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
X-Cl

Processed: #337914

Processing commands for [EMAIL PROTECTED]:

> tag 337914 -patch
Bug#337914: linux-2.6: SOFTWARE_SUSPEND needs PM on ppc
Tags were: patch
Tags removed: patch

> tag 337914 +upstream
Bug#337914: linux-2.6: SOFTWARE_SUSPEND needs PM on ppc
There were no tags set.
Tags added: upstream

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Bug#292328: marked as done (kernel-image-2.6.10-1-686: kernel freezes for about 30 sec. during the boot process)