[2.6.16-rc6-686] mod/modpost broken - wrong architecture!

[Eduard Bloch]

Hello,

the kernel-headers for the linux-headers-2.6.16-rc6-686 package
(installed from http://kernel-archive.buildserver.net/debian-kernel )
seem to be built on the wrong architecture. The module building script
are not executable, see below:

/usr/src/linux-headers-2.6.16-rc6-686/scripts/mod/modpost: ELF 32-bit MSB 
executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.2.0, 
dynamically linked (uses shared libs), not stripped

Eduard.
-- 
Citizen G'Kar: With luck, they may never find you, but if they do, you will
know pain...
Na'Toth #2: And you will know fear.
Citizen G'Kar: And then you will die.  Have a pleasant flight.
 -- Quotes from Babylon 5 --


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

Re: [2.6.16-rc6-686] missing include/linux/version.h

[Eduard Bloch]

Hello,

see subject, another critical bug in linux-headers-2.6.16-rc6-686.

Eduard.
-- 
Na'Toth #2: Ambassador, it is not my place to speculate on how anything gets
into your bed.
 -- Quotes from Babylon 5 --


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

Re: [2.6.16-rc6-686] mod/modpost broken - wrong architecture!

[Bastian Blank]

On Tue, Mar 14, 2006 at 07:51:49AM +0100, Eduard Bloch wrote:
> the kernel-headers for the linux-headers-2.6.16-rc6-686 package
> (installed from http://kernel-archive.buildserver.net/debian-kernel )
> seem to be built on the wrong architecture. The module building script
> are not executable, see below:

Yes, the packages are cross compiled on a powerpc machine as there are
no fast enough i386 machines available. Seems that I have to find a way
to fix that.

Bastian

-- 
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8


signature.asc
Description: Digital signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Jonas Smedegaard]

On Mon, 13 Mar 2006 10:28:57 -0500
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:

> Jonas Smedegaard wrote:
> 
> > I believe it is important for yaird to apply same strict logic to
> > all Linux kernels, official or not.
> 
> Seems perfectly reasonable to me.

Thanks.


> I think the following has been discovered:
> 
> 1. The ide-generic requirement was added by the modular IDE patch,
> which Debian included in its kernels. (Thus, kernel.org kernels never
> had it)
> 
> 2. The ide-generic requirement is gone as of 2.6.15.
> 
> I suspect a resolution that satisfies everyone is possible given the
> above two items.

I agree.

Do you consider the following a reasonable resolution?:

>From changelog for yaird 0.0.12-5:
>   * Drop ide-generic workarounds added in 0.0.12-2. This closes:
> bug#345067 (thanks especially to Jurij Smakov <[EMAIL PROTECTED]>
> bug#for
> his thorough analysis, and to others patiently helping resolve the
> issues involved).
> The workarounds turned out to be only needed together with a
> Debian-specific modular-ide kernel patch (and then needed always -
> not only with specific drivers).
> The modular-ide patch has been in use for quite some time but was
> dropped shortly after the yaird workaround got applied, and since
> yaird has not yet been part of an official Debian release it is
> safe to not maintain support for the broken modular-ide patch.

>From changelog of yaird 0.0.12-6:
>   * Add NEWS item warning about dropped ide-generic workaround, and
> suggesting a manual alternative (not adding README, as the need
> for this info should be only temporary).


(special note to Sven: no need to reply to this email unless you have
_new_ stuff to add. And if you do, then please do not cc me).


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


pgpdsppUxlEw0.pgp
Description: PGP signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Jonas Smedegaard]

Version: 0.0.12-5

On Mon, 13 Mar 2006 13:51:22 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> Notice that on wednesday, this bug will be open since 3 month, if i
> am not wrong,

Ah - for some reason my bug-closing hint in changelog was ignored. How
very annoying...


 - 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


pgpXtToDD1i1z.pgp
Description: PGP signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Sven Luther]

On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote:
> Version: 0.0.12-5
> 
> On Mon, 13 Mar 2006 13:51:22 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > Notice that on wednesday, this bug will be open since 3 month, if i
> > am not wrong,
> 
> Ah - for some reason my bug-closing hint in changelog was ignored. How
> very annoying...

Probably because you didn't upload it or something ? 

The -5 upload is not listed in http://packages.qa.debian.org/y/yaird.html, and
the -7 upload which is listed doesn't include the -5 and -6 changelog entries,
nor did i see those in the mailing list.

Not sure what happened about this, but thanks for fixing this bug.

Friendly,

Sven Luther


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

Re: [2.6.16-rc6-686] mod/modpost broken - wrong architecture!

[Martin Michlmayr]

* Bastian Blank <[EMAIL PROTECTED]> [2006-03-14 10:08]:
> Yes, the packages are cross compiled on a powerpc machine as there are
> no fast enough i386 machines available. Seems that I have to find a way
> to fix that.

BTW, I can confirm this problem.  I've been building test kernels for
mips and arm using a cross-compiler and have seen this as well.  I
just haven't got around to filing a bug yet... would be great if you
could look into it!
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Bug#356850: initramfs-tools: upon udev upgrade, system becomes unbootable if using lilo

[Adeodato Simó]

Package: initramfs-tools
Version: 0.53c
Severity: serious

Hi,

  when udev gets upgraded, the latest initram is regenerated via udev's
  postinst. If using lilo, the system becomes then unbootable due to
  lilo needing to get rerun in order to ack the changed initrd. See the
  irc snippet included below for details.

  Thanks.

04:15  maks: ok, that unbootability problem I had, had seemed to go away,
 but came today, and this one time I noted the error
04:19  maks: initramfs-tools and linux-image updated to sid last week, no
 updates since then; and, like the other time, seems like the udev 
update
 triggered it.
04:20  maks: (initramfs-tools 0.53c, linux-image 2.6.15-8, udev went 
0.086-1 -> 0.087-1 today)
04:21  maks: the 4 last lines when booting (and remember, no shell 
afterwards) were:
04:22  invalid compressed format (err=1)
04:22  VFS: Cannot open root device "301" on unknown-block(3,1)
04:22  Please append a correct "root=" option
04:22  Kernel panic - not syncing: VFS: unable to mount root fs on 
unknown-block(3,1)
04:22  maks: (using lilo, btw)

13:55  dato: sorry for not having your setup in my head, do you have a 
separate boot partition?
13:56  dato: is your root full?
14:16  maks: (np.) no, / is /dev/hda1, reiserfs, 275mb used, 425mb free.
 usr, var, tmp and home are separated (in LVs, but that's 
irrelevant here)
14:23  dato: you are using lilo?
14:23  maks: yes
14:23  ah that explains it.
14:24  "invalid compressed format (err=1)" helped
14:24  yeah, that was probably there the previous time, but I didn't 
notice it.
14:24  udev upgrade runs update-initramfs which generates a newer 
initrd.img
14:24  and lilo doesn't grog that
14:26  oh hum. so somebody should really be running lilo, then? (this 
sounds like a serious bug to me)
14:26  care to bug report against initramfs-tools
14:26  need to think a bit about how to solve that
14:26  you can send your aboves irc log.
14:26  ok, will do.
14:27  dato: thanks, udev and evms are currently the only hook user of 
initramfs-tools
14:28  but the hooks of lvm2 and md will need to go to their packages too
14:28  cryptsetup hook for crypto root is in the works too
14:28  dato: so i need to find a good solution for that. :)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.
--  Laurence J. Peter



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

Re: [2.6.16-rc6-686] mod/modpost broken - wrong architecture!

[Max Vozeler]

Hi all,

On Tue, Mar 14, 2006 at 07:51:49AM +0100, Eduard Bloch wrote:
> the kernel-headers for the linux-headers-2.6.16-rc6-686 package
> (installed from http://kernel-archive.buildserver.net/debian-kernel )
> seem to be built on the wrong architecture. The module building script
> are not executable, see below:
> 
> /usr/src/linux-headers-2.6.16-rc6-686/scripts/mod/modpost: ELF 32-bit MSB 
> executable, PowerPC or cisco 4500, version 1 (SYSV), for GNU/Linux 2.2.0, 
> dynamically linked (uses shared libs), not stripped

The m68k headers have a similar problem (#342248)

cheers,
Max


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

Bug#301004: bug persists in .15

[martin f krafft]

Just to let you know, the bug persists in 2.6.15.

-- 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"gott ist tot! und wir haben ihn getötet."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Anthony DeRobertis]

Jonas Smedegaard wrote:

> Do you consider the following a reasonable resolution?:

Sounds fine to me. Though it looks like your changelog entry has been
mangled a little:

>> bug#345067 (thanks especially to Jurij Smakov <[EMAIL PROTECTED]>
>> bug#for



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

Re: Bug#356850: initramfs-tools: upon udev upgrade, system becomes unbootable if using lilo

[Anthony DeRobertis]

Adeodato Simó wrote:

>   when udev gets upgraded, the latest initram is regenerated via
>   udev's postinst.

This sounds to me to be a fundamentally bad idea. The current initrd
clearly works --- the system did, after all, boot --- why would you
want to regenerate it?

If there is some *really* good reason to regenerate it, why does only
the latest initrd need regenerating? Shouldn't they all? And doesn't
the admin need to be prompted, in case he needs to copy the image to a
floppy, burn it to a CD, etc.?

>   If using lilo, the system becomes then unbootable 
>   due to lilo needing to get rerun in order to ack the changed initrd.

Yep. It'd be nice if Debian had some way to handle
adding/removing/changing kernels for all bootloaders... I imagine
similar problems arise on other platforms, too.


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

Processed: Re: Bug#356868: does not work with busybox-cvs-static

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 356868 initramfs-tools
Bug#356868: does not work with busybox-cvs-static
Bug reassigned from package `udev' to `initramfs-tools'.

> 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: Bug#356868: does not work with busybox-cvs-static

[Marco d'Itri]

reassign 356868 initramfs-tools
thanks

On Mar 14, martin f krafft <[EMAIL PROTECTED]> wrote:

> initramfs-tools is happy with busybox-cvs-static. However, this does
> not work, as ide.agent's way to determine the /proc/ide/* directory
> with printf doesn't work with busybox-cvs-static (hd141 instead of
> hda).
> 
> Please either fix ide.agent (preferred) or add a conflict on
> busybox-cvs-static. Using busybox instead works.

What what about initramfs-tools adding the conflict? Changing ide.agent
is not an option, it has been hell to find something which works in 
bash/dash/busybox and anyway it will be obsoleted by 2.6.16 kernels.
The initramfs is built by initramfs-tools and I believe that it is its
duty to provide a non-broken shell.

Or maybe this should just be reassigned to busybox-cvs-static.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Jonas Smedegaard]

On Tue, 14 Mar 2006 12:07:14 -0500
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:

> Jonas Smedegaard wrote:
> 
> > Do you consider the following a reasonable resolution?:
> 
> Sounds fine to me.

Great. :-)


> Though it looks like your changelog entry has been mangled a little:
> 
> >> bug#345067 (thanks especially to Jurij Smakov <[EMAIL PROTECTED]>
> >> bug#for

Ah, yes. I can thank the stupid quoting logic of my MUA, Sylpheed, for
that one. :-P


 - 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


pgp7Kte256kdE.pgp
Description: PGP signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Sven Luther]

On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote:
> Version: 0.0.12-5
> 
> On Mon, 13 Mar 2006 13:51:22 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > Notice that on wednesday, this bug will be open since 3 month, if i
> > am not wrong,
> 
> Ah - for some reason my bug-closing hint in changelog was ignored. How
> very annoying...

BTW, thanks for not crediting the research i did in the changelog entry, and
only mentioning Jurij, and then publicly blaming me in the -6 changelog entry.

Sven Luther


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

Bug#356868: does not work with busybox-cvs-static

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.03.14.1833 +0100]:
> What what about initramfs-tools adding the conflict?

Why? It does nicely with busybox-cvs-static. udev can't deal with
it.

> Changing ide.agent is not an option, it has been hell to find
> something which works in bash/dash/busybox and anyway it will be
> obsoleted by 2.6.16 kernels. The initramfs is built by
> initramfs-tools and I believe that it is its duty to provide
> a non-broken shell.

19:39 < madduck> Md: ide.agent is incompatible with busybox in
sarge. this is a udev problem. you will need to worry about this for
the upgrade path.

> Or maybe this should just be reassigned to busybox-cvs-static.

... which is deprecated anyway, it seems.

-- 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
microsoft: for when quality, reliability, and security
   just aren't that important!


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#356868: does not work with busybox-cvs-static

[Marco d'Itri]

On Mar 14, martin f krafft <[EMAIL PROTECTED]> wrote:

> > What what about initramfs-tools adding the conflict?
> Why? It does nicely with busybox-cvs-static. udev can't deal with
> it.
busybox-cvs-static providing a broken shell could be a good reason.

> 19:39 < madduck> Md: ide.agent is incompatible with busybox in
> sarge. this is a udev problem. you will need to worry about this for
> the upgrade path.
Then the versioned dependency in initramfs-tools should be updated.

> > Or maybe this should just be reassigned to busybox-cvs-static.
> ... which is deprecated anyway, it seems.
More than deprecated, apparenly it's not part of Debian anymore.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#356868: does not work with busybox-cvs-static

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.03.14.2021 +0100]:
> > Why? It does nicely with busybox-cvs-static. udev can't deal with
> > it.
> busybox-cvs-static providing a broken shell could be a good reason.

How is the shell broken?

> > > Or maybe this should just be reassigned to busybox-cvs-static.
> > ... which is deprecated anyway, it seems.
> More than deprecated, apparenly it's not part of Debian anymore.

busybox-cvs-static:
  Installed: (none)
  Candidate: 20040623-1
  Version table:
 20040623-1 0
700 http://debian.ethz.ch stable/main Packages

-- 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"man kann die menschen nur von ihren eigenen meinungen überzeugen."
-- charles tschopp


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#356868: does not work with busybox-cvs-static

[Marco d'Itri]

On Mar 14, martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.03.14.2021 +0100]:
> > > Why? It does nicely with busybox-cvs-static. udev can't deal with
> > > it.
> > busybox-cvs-static providing a broken shell could be a good reason.
> How is the shell broken?
You experienced "how".
And if something breaks a script which works with bash, dash and a
modern busybox then it fits pretty well my definiton of brokeness.

> > > > Or maybe this should just be reassigned to busybox-cvs-static.
> > > ... which is deprecated anyway, it seems.
> > More than deprecated, apparenly it's not part of Debian anymore.
> 700 http://debian.ethz.ch stable/main Packages
Indeed, it's not in testing nor in unstable.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#356850: initramfs-tools: upon udev upgrade, system becomes unbootable if using lilo

[Jonas Smedegaard]

[responding to the bug rather than only the d-kernel list]

On Tue, 14 Mar 2006 12:29:19 -0500
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:

> Adeodato Simó wrote:
> 
> >   when udev gets upgraded, the latest initram is regenerated via
> >   udev's postinst.
> 
> This sounds to me to be a fundamentally bad idea. The current initrd
> clearly works --- the system did, after all, boot --- why would you
> want to regenerate it?
> 
> If there is some *really* good reason to regenerate it, why does only
> the latest initrd need regenerating? Shouldn't they all? And doesn't
> the admin need to be prompted, in case he needs to copy the image to a
> floppy, burn it to a CD, etc.?

I believe udev cintained within ramdisk needs to match udev outside -
so if udev on the system is updated then (all!) initramfs-based ramdisks
needs to be regenerated in order to survive _next_ boot.

That is a fundamental challenge to using udev in initial ramdisks. Not
because of udev itself, but because of its lack of backwards
compatibility (which can be a plus, as it means less ugly workarounds to
fight with kernel maintainers about).


> >   If using lilo, the system becomes then unbootable 
> >   due to lilo needing to get rerun in order to ack the changed
> > initrd.
> 
> Yep. It'd be nice if Debian had some way to handle
> adding/removing/changing kernels for all bootloaders... I imagine
> similar problems arise on other platforms, too.

Something like kernel-install-helper[1] perhaps?


 - Jonas

[1] http://wiki.debian.org/FlexibleKernelHandling

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

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgpzuLJLmOomk.pgp
Description: PGP signature

Re: Bug#356868: does not work with busybox-cvs-static

[martin f krafft]

also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.03.14.2030 +0100]:
> And if something breaks a script which works with bash, dash and a
> modern busybox then it fits pretty well my definiton of brokeness.

the code in ide.agent is one massive hack. it's not posix afaict.
thus, no shell is broken if it cannot execute it flawlessly.

> > > More than deprecated, apparenly it's not part of Debian anymore.
> > 700 http://debian.ethz.ch stable/main Packages
> Indeed, it's not in testing nor in unstable.

it's still a part of debian.

-- 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"let me take you down, 'cause i'm going to strawberry fields.
 nothing is real and nothing to get hungabout.
 strawberry fields forever."
-- the beatles


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#356868: does not work with busybox-cvs-static

[Marco d'Itri]

On Mar 14, martin f krafft <[EMAIL PROTECTED]> wrote:

> also sprach Marco d'Itri <[EMAIL PROTECTED]> [2006.03.14.2030 +0100]:
> > And if something breaks a script which works with bash, dash and a
> > modern busybox then it fits pretty well my definiton of brokeness.
> the code in ide.agent is one massive hack. it's not posix afaict.
> thus, no shell is broken if it cannot execute it flawlessly.
I think that it is very reasonable code and I verified that it works even
with posh.
I doubt that it is not at least a valid XSI script, but even if it were
not I would not care since it passes the "reasonable Bourne shell" test.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Jonas Smedegaard]

On Tue, 14 Mar 2006 19:55:48 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote:
> > Version: 0.0.12-5
> > 
> > On Mon, 13 Mar 2006 13:51:22 +0100
> > Sven Luther <[EMAIL PROTECTED]> wrote:
> > 
> > > Notice that on wednesday, this bug will be open since 3 month, if
> > > i am not wrong,
> > 
> > Ah - for some reason my bug-closing hint in changelog was ignored.
> > How very annoying...
> 
> BTW, thanks for not crediting the research i did in the changelog
> entry, and only mentioning Jurij, and then publicly blaming me in the
> -6 changelog entry.

Your repeatitive pointing out what big a fool I am gave me the
impression that you yourself was handling your own credit.

If you are unaware of what I am talking about then have a look at this:
http://wiki.debian.org/LinuxKernelIdeProblem?action=diff&rev2=23&rev1=15

The issue is solved thanks to folks figuring out the kernel actually
behave and behaved earlier, not folks claiming that there is no problem.


 - Jonas

P.S.

I know, I shouldn't even respond to a message like the above, feeding
this irrelevant non-technical fight. sorry - couldn't resist.

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

 - Enden er nær: http://www.shibumi.org/eoti.htm


pgpDq42yEqX0P.pgp
Description: PGP signature

Bug#356933: linux-image-2.6.16-rc5-powerpc: modprobe snd-powermac segfaults

[Filippo Giunchedi]

Package: linux-image-2.6.16-rc5-powerpc
Version: 2.6.15+2.6.16-rc5-0experimental.1
Severity: normal

Hi,
I was trying 2.6.16-rc5 and I got this error while trying to modprobe
snd-powermac on powerbook6,2

Unable to handle kernel paging request for data at address 0x0002
Faulting instruction address: 0xc01a302c
Oops: Kernel access of bad area, sig: 11 [#1]
Modules linked in: snd_powermac snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd 
soundcore snd_page_alloc binfmt_misc ipv6 rfcomm l2cap nls_utf8 ext3 jbd 
mbcache dm_snapshot dm_crypt fuse usblp apm_emu vfat fat hfsplus therm_adt746x 
sr_mod sbp2 scsi_mod eth1394 hci_usb bluetooth evdev tsdev ohci1394 ieee1394 
uninorth_agp agpgart dm_mod xfs exportfs usbhid ehci_hcd sungem sungem_phy 
ohci_hcd usbcore ide_disk ide_cd cdrom
NIP: C01A302C LR: E45A93F4 CTR: C01A3000
REGS: d999fcc0 TRAP: 0300   Not tainted  (2.6.16-rc5-powerpc)
MSR: 9032   CR: 22008444  XER: 2000
DAR: 0002, DSISR: 4000
TASK = d9f3c0f0[3587] 'modprobe' THREAD: d999e000
GPR00: E45A93F4 D999FD70 D9F3C0F0  0001 0060  0001 
GPR08: 0002  C0018C2C C01A3000  1001E638   
GPR16:   100013D0 1001F2B0 3002A000 0003   
GPR24: 10021C00  1001FBAC DFC95800 DD6A1560 000A E45B2504 E45AC580 
NIP [C01A302C] i2c_smbus_write_byte_data+0x2c/0x50
LR [E45A93F4] send_init_client+0x30/0x90 [snd_powermac]
Call Trace:
[D999FD70] [C0053C80] setup_irq+0x12c/0x148 (unreliable)
[D999FDB0] [E45A93F4] send_init_client+0x30/0x90 [snd_powermac]
[D999FDD0] [E454FF00] snd_pmac_tumbler_post_init+0x30/0x68 [snd_powermac]
[D999FDE0] [E454E228] snd_pmac_probe+0x1a8/0x324 [snd_powermac]
[D999FE10] [C017D740] platform_drv_probe+0x20/0x30
[D999FE20] [C017B734] driver_probe_device+0x98/0x100
[D999FE40] [C017ABD0] bus_for_each_drv+0x50/0x98
[D999FE70] [C017B80C] device_attach+0x6c/0xa8
[D999FE90] [C017AC50] bus_add_device+0x38/0xf4
[D999FEB0] [C0179964] device_add+0xe0/0x174
[D999FED0] [C017D58C] platform_device_add+0x118/0x160
[D999FEF0] [C017DB18] platform_device_register_simple+0x4c/0x78
[D999FF10] [E454E044] alsa_card_pmac_init+0x44/0x80 [snd_powermac]
[D999FF20] [C004BAF0] sys_init_module+0x15c/0x2c0
[D999FF40] [C000FF3C] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0xff6e708
LR = 0x10003e30
Instruction dump:
4e800020 7c0802a6 9421ffc0 7c691b78 7c872378 38c0 3902 98a10008 
90010044 6000 6000 6000  a0890004 39210008 80630008 
 
# uname -a
Linux hattori 2.6.16-rc5-powerpc #2 Thu Mar 9 16:31:40 CET 2006 ppc GNU/Linux

-- System Information:
Debian Release: testing/unstable
  APT prefers experimental
  APT policy: (650, 'experimental'), (600, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-rc5-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.16-rc5-powerpc depends on:
ii  initramfs-tools [linux-initra 0.53c  tools for generating an initramfs
ii  mkvmlinuz 18 create a kernel to boot a PowerPC 
ii  module-init-tools 3.2.2-2tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-8   Yet Another mkInitRD

linux-image-2.6.16-rc5-powerpc recommends no packages.

-- debconf information:
  
linux-image-2.6.16-rc5-powerpc/preinst/overwriting-modules-2.6.16-rc5-powerpc: 
true
  linux-image-2.6.16-rc5-powerpc/preinst/bootloader-initrd-2.6.16-rc5-powerpc: 
true
  linux-image-2.6.16-rc5-powerpc/preinst/abort-install-2.6.16-rc5-powerpc:
  
linux-image-2.6.16-rc5-powerpc/prerm/would-invalidate-boot-loader-2.6.16-rc5-powerpc:
 true
  
linux-image-2.6.16-rc5-powerpc/preinst/failed-to-move-modules-2.6.16-rc5-powerpc:
  
linux-image-2.6.16-rc5-powerpc/postinst/depmod-error-initrd-2.6.16-rc5-powerpc: 
false
  linux-image-2.6.16-rc5-powerpc/postinst/kimage-is-a-directory:
  linux-image-2.6.16-rc5-powerpc/preinst/abort-overwrite-2.6.16-rc5-powerpc:
  linux-image-2.6.16-rc5-powerpc/preinst/lilo-initrd-2.6.16-rc5-powerpc: true
  
linux-image-2.6.16-rc5-powerpc/prerm/removing-running-kernel-2.6.16-rc5-powerpc:
 true
  
linux-image-2.6.16-rc5-powerpc/postinst/old-dir-initrd-link-2.6.16-rc5-powerpc: 
true
  
linux-image-2.6.16-rc5-powerpc/postinst/create-kimage-link-2.6.16-rc5-powerpc: 
true
  linux-image-2.6.16-rc5-powerpc/postinst/depmod-error-2.6.16-rc5-powerpc: false
  
linux-image-2.6.16-rc5-powerpc/preinst/already-running-this-2.6.16-rc5-powerpc:
  linux-image-2.6.16-rc5-powerpc/preinst/elilo-initrd-2.6.16-rc5-powerpc: true
  linux-image-2.6.16-rc5-powerpc/postinst/bootloader-error-2.6.16-rc5-powerpc:
  linux-image-2.6.16-rc5-powerpc/preinst/initrd-2.6.16-rc5-powerpc:
  
linux-image-2.6.16-rc5-powerpc/postinst/bootloader-test-error-2.6.16-rc5-powerpc:
  
linux-image-2.6.16-rc5-powerpc/postinst/old-system-map-link-2.6.16-rc5-powerpc: 
true
  linux-image-2.6.16-rc5-powerpc/postinst/old-initrd-link-2.6.16-rc5-powerpc: 
true
  linux-

timeline for next kernel update round

[Andreas Barth]

Hi,

as we're now on track in getting sarge r2 out, I'm interessted when the
next kernel update should happen - and of course if there is something
important from your side. As far as I understood, that update will be an
ABI-change, which means: we need to rebuild the installer. Is that
correct?


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


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

Bug#356946: linux-image-2.6.15-1-686: the power off button does not work anymore

[Ludovic Rousseau]

Package: linux-image-2.6.15-1-686
Version: 2.6.15-8
Severity: normal

Hello,

I can't use the power off button of my laptop to start the power off
sequence. I recompiled a vanilla kernel linux-2.6.15.6 (from kernel.org)
and the button works (without changing anything in user space) so the
bug seems to be Debian specific.

The button kernel module is loaded and the files are created in
/proc/acpi
$ find /proc/acpi/button/
/proc/acpi/button/
/proc/acpi/button/lid
/proc/acpi/button/lid/LID
/proc/acpi/button/lid/LID/state
/proc/acpi/button/lid/LID/info
/proc/acpi/button/sleep
/proc/acpi/button/power
/proc/acpi/button/power/PWBN
/proc/acpi/button/power/PWBN/info
/proc/acpi/button/power/PWRF
/proc/acpi/button/power/PWRF/info

but pressing the button has no effect.

$ cat /proc/acpi/button/power/PWBN/info
type:Power Button (CM)
$  cat /proc/acpi/button/power/PWRF/info
type:Power Button (FF)

I just tried with linux-image-2.6.14-2-686 (2.6.14-6bpo1 from
backports.org) and the power off button works. The button also worked
with previous official Debian kernels. I don't know exactly when it
stopped working.

I am using etch.

What can I do to help the debug?

Thanks

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

Versions of packages linux-image-2.6.15-1-686 depends on:
ii  module-init-tools 3.2.2-2tools for managing Linux kernel mo
ii  yaird [linux-initramfs-tool]  0.0.12-3   Yet Another mkInitRD

Versions of packages linux-image-2.6.15-1-686 recommends:
ii  libc6-i6862.3.5-13   GNU C Library: Shared libraries [i

-- debconf information:
  linux-image-2.6.15-1-686/postinst/kimage-is-a-directory:
* linux-image-2.6.15-1-686/preinst/overwriting-modules-2.6.15-1-686: false
  linux-image-2.6.15-1-686/postinst/depmod-error-initrd-2.6.15-1-686: false
  linux-image-2.6.15-1-686/postinst/bootloader-error-2.6.15-1-686:
  linux-image-2.6.15-1-686/postinst/bootloader-test-error-2.6.15-1-686:
  linux-image-2.6.15-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.15-1-686/preinst/failed-to-move-modules-2.6.15-1-686:
  linux-image-2.6.15-1-686/postinst/old-system-map-link-2.6.15-1-686: true
  linux-image-2.6.15-1-686/preinst/abort-install-2.6.15-1-686:
  linux-image-2.6.15-1-686/preinst/abort-overwrite-2.6.15-1-686:
  linux-image-2.6.15-1-686/preinst/bootloader-initrd-2.6.15-1-686: true
  linux-image-2.6.15-1-686/prerm/would-invalidate-boot-loader-2.6.15-1-686: true
  linux-image-2.6.15-1-686/preinst/lilo-initrd-2.6.15-1-686: true
  linux-image-2.6.15-1-686/postinst/old-initrd-link-2.6.15-1-686: true
  linux-image-2.6.15-1-686/postinst/old-dir-initrd-link-2.6.15-1-686: true
* linux-image-2.6.15-1-686/preinst/already-running-this-2.6.15-1-686:
  linux-image-2.6.15-1-686/preinst/initrd-2.6.15-1-686:
  linux-image-2.6.15-1-686/postinst/depmod-error-2.6.15-1-686: false
  linux-image-2.6.15-1-686/postinst/create-kimage-link-2.6.15-1-686: true
  linux-image-2.6.15-1-686/prerm/removing-running-kernel-2.6.15-1-686: true
  linux-image-2.6.15-1-686/preinst/elilo-initrd-2.6.15-1-686: true


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

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Sven Luther]

On Tue, Mar 14, 2006 at 09:09:45PM +0100, Jonas Smedegaard wrote:
> On Tue, 14 Mar 2006 19:55:48 +0100
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Mar 14, 2006 at 11:58:58AM +0100, Jonas Smedegaard wrote:
> > > Version: 0.0.12-5
> > > 
> > > On Mon, 13 Mar 2006 13:51:22 +0100
> > > Sven Luther <[EMAIL PROTECTED]> wrote:
> > > 
> > > > Notice that on wednesday, this bug will be open since 3 month, if
> > > > i am not wrong,
> > > 
> > > Ah - for some reason my bug-closing hint in changelog was ignored.
> > > How very annoying...
> > 
> > BTW, thanks for not crediting the research i did in the changelog
> > entry, and only mentioning Jurij, and then publicly blaming me in the
> > -6 changelog entry.
> 
> Your repeatitive pointing out what big a fool I am gave me the
> impression that you yourself was handling your own credit.
> 
> If you are unaware of what I am talking about then have a look at this:
> http://wiki.debian.org/LinuxKernelIdeProblem?action=diff&rev2=23&rev1=15
> 
> The issue is solved thanks to folks figuring out the kernel actually
> behave and behaved earlier, not folks claiming that there is no problem.

Yeah, sure, and before jurij had a look, i didn't spent many hours looking at
the code, and following it in detail, and trying to convince you about the
issue.

I want to remember you that i proposed to do exactly that in erkelenz and was
plainly refused, and that normally it should be your responsability as the
maintainer of the package to do so.

> I know, I shouldn't even respond to a message like the above, feeding
> this irrelevant non-technical fight. sorry - couldn't resist.

You know, this is exactly the problem, and i am not the first who thinks it is
difficult to work with you on such issues, maybe you should reconsider your
part in this, too, don't you think ? 

At the start of each of those days, i tried to be positive and gave info and
looked at the code, and invested time to solve the issue, but invariably as
the day passed and you stayed staunch in your refusal to hearing any kind of
reason, i went over the border again. This happened not one time, but 4 days
in a row. You cannot say that i didn't show positive behavior, and tried to
solve the issue. If i where not convinced that you are not a bad guy, i would
say that you voluntarily forced me into going over the border, just to
ridicoulous me. So i think there was a serious communication problem here, but
putting all the blame on me and not aknowledging the work i did to solve the
bug is abysmal behavior.

I will not post again on this, and i hope that some of the others here will
have a word or two with you about this.

Sven Luther


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

Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch

[Sven Luther]

For info, ...

It seems that i am to get blamed for everything that went badly after all, and
it is perfectly normal for jonas not to aknowledge the effort i put into
solving this issue, while he was just ignoring it and putting out random crazy
theories for not acting.

I am disgusted with how how jonas handled this, and i am not all so happy how
all others basically let this happen, and still see me as the evil flammer,
and jonas as the good guy, and nobody ever said a word to him about his
behavior.

I lost many hours to investigate the issue, hours i could have used for RL
work instead, and that is all i get over this, i am sorry, and i did get
almost no support, except from two persons who will recognize themselves, so i
am leaving for some time now, as i have matters of personal nature to handle,
and all this frustration lost with so little return is not worth it.

Just an (anonymized) quote so as to show you that not everyone is blinded by
jonas and his shiny wiki-writing skills :

  00:06 <***> i had issues with jonas in his *** package long time
  ago and he is very difficult to talk about issues.

So, it has been nice to work on the kernel, but every time jonas got involved,
now, but also when i was working on the ramdisk generator issue, it quickly
degenerated into a disgusting flamewar. It may be partially my fault, but
please go over the events, and the irc logs if you keep them, and don't put
all the blame on me.

I hope to be able to help again in the (near) future with kernel packaging,
once i have time to lose again, and did overcome the personal issues, and
maybe by then people will not be so quick to blame me on everything.

Friendly,

Sven Luther


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

linux-2.6_2.6.15+2.6.16-rc5-0experimental.1_i386.changes ACCEPTED

[Debian Installer]

Accepted:
kernel-image-2.6-386_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-386_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
kernel-image-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
kernel-image-2.6-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
kernel-image-2.6-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
kernel-image-2.6-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-vserver-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-vserver-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-vserver-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-vserver-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-xen-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-xen-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6-xen-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-xen-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-k7-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-vserver-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-vserver-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-vserver-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-vserver-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-vserver_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-vserver_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-xen-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-xen-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-xen-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-xen-k7_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5-xen_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-xen_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16-rc5_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-headers-2.6.16_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-image-2.6-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6-486_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-image-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6-686-smp_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
linux-image-2.6-686_2.6.15+2.6.16-rc5-0experimental.1_i386.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6-686_2.6.15+2.6.16-r

linux-2.6_2.6.15+2.6.16-rc5-0experimental.1_s390.changes ACCEPTED

[Debian Installer]

Accepted:
kernel-image-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
kernel-image-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/kernel-image-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6.16-rc5-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6.16-rc5-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6.16-rc5_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16-rc5_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-headers-2.6.16_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.16_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-2.6.16-rc5-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.16-rc5-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-2.6.16-rc5-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.16-rc5-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-s390_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
linux-image-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb
  to 
pool/main/l/linux-2.6/linux-image-s390x_2.6.15+2.6.16-rc5-0experimental.1_s390.deb


Thank you for your contribution to Debian.


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

Re: timeline for next kernel update round

[Moritz Muehlenhoff]

Andreas Barth wrote:
> as we're now on track in getting sarge r2 out, I'm interessted when the
> next kernel update should happen - and of course if there is something
> important from your side. As far as I understood, that update will be an
> ABI-change, which means: we need to rebuild the installer. Is that
> correct?

The update is built and tested, it'll appear soon. It contains three
ABI changing security fixes, so the ABI will be bumped. I can't speak
for d-i.

Cheers,
Moritz


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

Re: timeline for next kernel update round

[Frans Pop]

On Wednesday 15 March 2006 00:15, Moritz Muehlenhoff wrote:
> The update is built and tested, it'll appear soon. It contains three
> ABI changing security fixes, so the ABI will be bumped. I can't speak
> for d-i.

ABI changes are for both 2.6 and 2.4 kernel, correct? Or is the ABI change 
only for the 2.6 kernel update?

(BTW. Did you drop [EMAIL PROTECTED] on purpose?)


pgpqTFgFOxZ0L.pgp
Description: PGP signature

Re: timeline for next kernel update round

[dann frazier]

On Tue, 2006-03-14 at 21:46 +0100, Andreas Barth wrote:
> Hi,
> 
> as we're now on track in getting sarge r2 out, I'm interessted when the
> next kernel update should happen - and of course if there is something
> important from your side. As far as I understood, that update will be an
> ABI-change, which means: we need to rebuild the installer. Is that
> correct?

This build has been submitted to the security team and jmm is working on
getting that uploaded to stable/updates.  So it should happen real soon
now.  And yes, it is indeed an ABI change.

If you decide to include this update in r2, d-i will need to be prepared
first.  We have not yet prepared the kernel udebs for the d-i roll, or
made changes to the sarge branch of d-i to incorporate it.

Thanks for contacting us about this; I was planning on sending you an
e-mail this afternoon.



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

removal of svenl from the project

[Andres Salomon]

Hi,

I am going through the expulsion process to have Sven Luther removed
from the project.  The process is outlined here:
,
and I have already completed step 1.

Step #2 requires the support of some 15 developers.  I am attempting to
find people that are interested in publically seconding my explusion
request.  If you are interested, please email me.  Remember that your
request will be public, and you will have to provide reasons why you
feel that his removal will benefit the project.  I'm looking both for
people who have had conflicts w/ him (logs are always good, too), as
well as people who have just seen the effects of his actions (ie,
unbiased opinions).

Sven has always been a nuisance to deal w/, but up until now I have not
considered this action.  In the past two weeks, the following comments
made by him have changed my mind:

2006-03-07:
 jonas: i hope we never again meet in public, because i promise i
will hit you if i do.

2006-03-14:
svenl> vorlon: so, you think it is correct of jonas to mention
traveller and thanking him for investigating the issue, while fully
ignoring my own contribution ?
<-- vorlon ([EMAIL PROTECTED]) has left
#debian-kernel
 yeah, coward.

Sven's behavior has always been combative (and some might argue
hostile), but this is beyond what is acceptable.  He threatens bodily
harm upon another developer in a public forum, and then a week later
publically insults/taunts a developer (one of the Release Managers,
even), behind his back.  This is incredibly childish, aggressive
behavior, and should not be tolerated within the project (IMO).

Some might argue that we should just kick him from the channel and
remove his commit access to the debian-kernel project, but that does not
solve the problem of him abusing other teams, as well as his abusive
mailing list posts.  He also {co-,}maintains some 47 packages, which
means users for those packages will have to deal w/ him as well.  I
believe it is better if he is removed from the project altogether, as he
damages it more than he helps.

So, if you are interested in seconding the expulsion request, please let
me know.  Please do not turn this into a flamewar; I don't care about
your reasons why people should not be forcefully removed from the
project.  Those who feel this way probably have not had to work w/ Sven
on a team for the past 2 years.



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

Re: removal of svenl from the project

[Andres Salomon]

On Tue, 2006-03-14 at 21:01 -0500, Andres Salomon wrote:
[...]
> Sven has always been a nuisance to deal w/, but up until now I have not
> considered this action.  In the past two weeks, the following comments
> made by him have changed my mind:
> 
> 2006-03-07:
>  jonas: i hope we never again meet in public, because i promise i
> will hit you if i do.
> 
> 2006-03-14:
> svenl> vorlon: so, you think it is correct of jonas to mention
> traveller and thanking him for investigating the issue, while fully
> ignoring my own contribution ?
> <-- vorlon ([EMAIL PROTECTED]) has left
> #debian-kernel
>  yeah, coward.
> 

A few clarifications/comments based upon what people have said:

1) These quotes are examples of his destructive behavior.  One can find
plenty more in the mailing lists.  The ones I supplied here are the ones
that made *me* decide to take action.

2) Yes, I have tried talking to him.  After a number of blowups on the
debian-kernel list, myself and a number of kernel team members have
talked to him to calm him down (and in some cases getting him to
apologize).  The behavior he displays happens repeatedly, despite
warnings and requests that he behave himself.  The rest of the IRC log
from when he threatened Jonas is basically me attempting to show Sven
how destructive his behavior is.  The fact that, a week later, he
continues w/ this behavior (after years of doing the same thing) is why
you're seeing this request.

3) If he was in the NM queue, and you were his AM, would you accept him
after seeing how he behaves?  If not, why is that so different from
kicking him out of the project (other than asking that he be banned from
the lists, but this is a request of the list masters, not the DAM)?  In
that regards, I have a wonderful quote from Sven: "I am not in the AM
queue, so i can be as rude as i want." [0]

I presume he meant the NM queue.

[0] http://lists.debian.org/debian-legal/2004/07/msg00967.html


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

Re: timeline for next kernel update round

[Moritz Muehlenhoff]

Frans Pop wrote:
> On Wednesday 15 March 2006 00:15, Moritz Muehlenhoff wrote:
> > The update is built and tested, it'll appear soon. It contains three
> > ABI changing security fixes, so the ABI will be bumped. I can't speak
> > for d-i.
> 
> ABI changes are for both 2.6 and 2.4 kernel, correct? Or is the ABI change 
> only for the 2.6 kernel update?

Both, the 2.4 update includes fixes for CVE-2005-0449 and CVE-2005-2709,
which change the ABI.
 
> (BTW. Did you drop [EMAIL PROTECTED] on purpose?)

By accident, my first reply was through Gmane, which for obvious reasons
doesn't carry a [EMAIL PROTECTED] newsgroup :-)

Cheers,
Moritz


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

Re: removal of svenl from the project

[Sven Luther]

On Tue, Mar 14, 2006 at 09:01:09PM -0500, Andres Salomon wrote:
> Hi,
> 
> I am going through the expulsion process to have Sven Luther removed
> from the project.  The process is outlined here:
> ,
> and I have already completed step 1.

Thanks very much Andres, this is really appreciated.

/me leaves in disgust.

Sven Luther


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