On Thu, Dec 29, 2005 at 04:14:50AM +0100, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 28 Dec 2005 16:09:11 +1030
Rod Whitby [EMAIL PROTECTED] wrote:
As requested by fs on #debian-kernel, here is the first post in an
effort to identify and remove
On Thu, Dec 29, 2005 at 04:14:50AM +0100, Jonas Smedegaard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 28 Dec 2005 16:09:11 +1030
Rod Whitby [EMAIL PROTECTED] wrote:
As requested by fs on #debian-kernel, here is the first post in an
effort to identify and remove
On Thu, Dec 29, 2005 at 02:48:49AM +0100, maximilian attems wrote:
On Wed, 28 Dec 2005, Joey Hess wrote:
I also see this bug, using initramfs-tools 0.44 and
linux-image-2.6.14-2-386 (2.6.14-6).
could you try the attached hook file,
please place it under
Processing commands for [EMAIL PROTECTED]:
unmerge #337497
Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT!
/dev/hda1 does
Bug#332824: linux-image-2.6.13-1-686: Cannot find LVM root fs
Bug#342925: initramfs-tools: [sparc64] generated initrd fails to boot
Disconnected
Package: linux-image-2.6.14-2-686
Version: 2.6.14-6
Hello,
Since I upgraded from linux-image-2.6.12 to linux-image-2.6.14 my
ali5451 soundcard is no more able of playing any sound...
I've tried all the successives revisions of 2.6.14 but it really seems
it's since the change 2.6.12/2.6.14
Hi,
at the time where sarge was released, the question was raised multiple
times whether we can put newer kernels into volatile. As it is now about
halfways between release of sarge and release of etch, it is time to
reconsider whether to put an newer kernel into volatile or not.
Reasons to add
On Thu, 29 Dec 2005, Laurent Neiger wrote:
Hello,
Since I upgraded from linux-image-2.6.12 to linux-image-2.6.14 my
ali5451 soundcard is no more able of playing any sound...
I've tried all the successives revisions of 2.6.14 but it really seems
it's since the change 2.6.12/2.6.14 that
On Thu, Dec 29, 2005 at 11:06:47AM +0100, Andreas Barth wrote:
Hi,
at the time where sarge was released, the question was raised multiple
times whether we can put newer kernels into volatile. As it is now about
halfways between release of sarge and release of etch, it is time to
reconsider
Hi,
* Sven Luther ([EMAIL PROTECTED]) [051229 11:47]:
The main problem are the too strict rules for building in volatile, which stop
us from uploading the etch/sid kernels and associated packages to it.
Actually, I think we should first consider which kernel minor version we
want to use
Dear Maximilian,
first of all many thanks for your so quick answer.
Unfortunately, upgrading to 2.6.15 didn't solve my problem.
Messages in /var/log/dmesg (or boot or syslog) are just the same, there
is an error while loading the ali5451 module.
But as at last it achieve to be loaded, alsa,
On Wed, Dec 28, 2005 at 10:58:25PM +0100, Sven Luther wrote:
I never saw those before, so i wonder if this are harmless messages coming
They are harmless. I made ld a little too paranoid on 2005-09-19, and
cured the paranoia on 2005-11-18. If you update to current binutils the
warnings should
On Thu, Dec 29, 2005 at 12:15:53PM +0100, Andreas Barth wrote:
Hi,
* Sven Luther ([EMAIL PROTECTED]) [051229 11:47]:
The main problem are the too strict rules for building in volatile, which
stop
us from uploading the etch/sid kernels and associated packages to it.
Actually, I think
On Thu, Dec 29, 2005 at 10:08:05PM +1030, Alan Modra wrote:
On Wed, Dec 28, 2005 at 10:58:25PM +0100, Sven Luther wrote:
I never saw those before, so i wonder if this are harmless messages coming
They are harmless. I made ld a little too paranoid on 2005-09-19, and
cured the paranoia on
On Thu, Dec 29, 2005 at 01:11:40PM +0100, Andreas Barth wrote:
* Sven Luther ([EMAIL PROTECTED]) [051229 13:05]:
On Thu, Dec 29, 2005 at 12:15:53PM +0100, Andreas Barth wrote:
* Sven Luther ([EMAIL PROTECTED]) [051229 11:47]:
The main problem are the too strict rules for building in
On Thursday 29 December 2005 13:04, Sven Luther wrote:
To add to that the fact that with a minimal rebuild of support tools
(yaird and backported udev for me), the etch/sid/experimental kernels
install just fine on a sarge system. I run all my sarge systems like
this, and it works just fine.
Hi,
* Andreas Barth ([EMAIL PROTECTED]) [051229 13:12]:
* Sven Luther ([EMAIL PROTECTED]) [051229 13:05]:
- Any security issues that happen need to be resolved - so we should
limit the number of versions we offer.
Indeed, so the best is to have it be identic to either the etch or the
* Frans Pop ([EMAIL PROTECTED]) [051229 13:29]:
[...]
I think the whole issue of introducing a new kernel in Sarge is being
hopelessly underestimated here.
I fully agree with Frans. It's a non-trivial task, and if we really go
this way (and there are good reasons to go this way), it'll be a
Sven Luther wrote:
Obviously, from a kernel maintainer perpespective, the one that makes more
sense is the latest one we are working on, which will always be the more
actively maintained one and as a consequence the one of more interest to the
users, not to mention the fact that for the users
Frans Pop wrote:
Also, using 2.6.12/14/15 in Sarge (volatile) IMO means that the kernel
team will need to commit to maintaining that version with regard to
security updates, just as for 2.6.8.
Continuously making the latest kernel available for Sarge through volatile
IMO is not an option,
cher Laurent!
On Thu, 29 Dec 2005, Laurent Neiger wrote:
first of all many thanks for your so quick answer.
:)
Unfortunately, upgrading to 2.6.15 didn't solve my problem.
Messages in /var/log/dmesg (or boot or syslog) are just the same, there
is an error while loading the ali5451 module.
On Thu, Dec 29, 2005 at 01:31:08PM +0100, Andreas Barth wrote:
Hi,
* Andreas Barth ([EMAIL PROTECTED]) [051229 13:12]:
* Sven Luther ([EMAIL PROTECTED]) [051229 13:05]:
- Any security issues that happen need to be resolved - so we should
limit the number of versions we offer.
On Thu, Dec 29, 2005 at 01:29:13PM +0100, Frans Pop wrote:
On Thursday 29 December 2005 13:04, Sven Luther wrote:
To add to that the fact that with a minimal rebuild of support tools
(yaird and backported udev for me), the etch/sid/experimental kernels
install just fine on a sarge system. I
On Thu, Dec 29, 2005 at 07:56:18AM -0500, Joey Hess wrote:
Sven Luther wrote:
Obviously, from a kernel maintainer perpespective, the one that makes more
sense is the latest one we are working on, which will always be the more
actively maintained one and as a consequence the one of more
* Joey Hess ([EMAIL PROTECTED]) [051229 14:03]:
Frans Pop wrote:
Also, using 2.6.12/14/15 in Sarge (volatile) IMO means that the kernel
team will need to commit to maintaining that version with regard to
security updates, just as for 2.6.8.
Continuously making the latest kernel
On Thu, Dec 29, 2005 at 08:01:34AM -0500, Joey Hess wrote:
Frans Pop wrote:
Also, using 2.6.12/14/15 in Sarge (volatile) IMO means that the kernel
team will need to commit to maintaining that version with regard to
security updates, just as for 2.6.8.
Continuously making the latest
On Thu, 29 Dec 2005, Andreas Barth wrote:
* Sven Luther ([EMAIL PROTECTED]) [051229 11:47]:
The main problem are the too strict rules for building in volatile, which
stop
us from uploading the etch/sid kernels and associated packages to it.
Actually, I think we should first consider
On Thu, Dec 29, 2005 at 03:02:28PM +0100, maximilian attems wrote:
On Thu, 29 Dec 2005, Andreas Barth wrote:
* Sven Luther ([EMAIL PROTECTED]) [051229 11:47]:
The main problem are the too strict rules for building in volatile, which
stop
us from uploading the etch/sid kernels and
initramfs-tools_0.46_i386.changes uploaded successfully to localhost
along with the files:
initramfs-tools_0.46.dsc
initramfs-tools_0.46.tar.gz
initramfs-tools_0.46_all.deb
Greetings,
Your Debian queue daemon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
(CC to d-kernel and yaird-devel for comments. Topic is a question in
Debian Installer regarding the initramfs generator to use.
For the start of the thread see:
http://lists.debian.org/debian-boot/2005/12/msg01228.html)
On Thursday 29 December 2005 09:07, Christian Perrier wrote:
by which
Hi,
I needed to compile a module for linux-kernel-2.4, and find out this
couple of patches wich fix thoses errors
http://user.it.uu.se/~mikpe/linux/patches/2.4/patch-gcc4-fixes-v12-2.4.32
On Thu, Dec 29, 2005 at 04:01:15PM +0100, Frans Pop wrote:
(CC to d-kernel and yaird-devel for comments. Topic is a question in
Debian Installer regarding the initramfs generator to use.
For the start of the thread see:
http://lists.debian.org/debian-boot/2005/12/msg01228.html)
On
On Thu, Dec 29, 2005 at 04:18:04PM +0100, Maximilian Attems wrote:
On Thu, Dec 29, 2005 at 04:01:15PM +0100, Frans Pop wrote:
(CC to d-kernel and yaird-devel for comments. Topic is a question in
Debian Installer regarding the initramfs generator to use.
For the start of the thread see:
tags 336103 moreinfo
thanks
please try against latest initramfs-tools version 0.46
atm in incoming.debian.org
and report back if the dma issue is fixed, ide-generic
will be loaded as last with it so this should be fixed.
please use a clean /etc/mkinitramfs/modules and
update-initramfs -u
--
(Please do not CC me; I'm subscribed to all lists relevant here)
On Thursday 29 December 2005 16:34, Sven Luther wrote:
I would have thought it the other way around, there is no reason to use
initramfs-tools for a new install, since we are then not upgrading from
2.4 kernels.
That is not a
Hi,
maximilian attems wrote:
cher Laurent!
And furthermore you know french ! Whaoo :-)
hmm that is an usb driver.
we only disabled CONFIG_USB_BANDWIDTH two days ago,
so not yet uploaded, might be related.
Ho yes, possible...
please monitor experimental and feedback if next kernel upload
On Thu, Dec 29, 2005 at 04:48:09PM +0100, Frans Pop wrote:
(Please do not CC me; I'm subscribed to all lists relevant here)
On Thursday 29 December 2005 16:34, Sven Luther wrote:
I would have thought it the other way around, there is no reason to use
initramfs-tools for a new install,
On Thursday 29 December 2005 17:27, Sven Luther wrote:
What if we defaulted to yaird, we know that yaird, by design, will fail
at install time and not at boot time, and give an error message, which
we can grab and append to the log messages or whatever.
It does not in all cases, like for
On Thu, Dec 29, 2005 at 05:47:41PM +0100, Frans Pop wrote:
On Thursday 29 December 2005 17:27, Sven Luther wrote:
What if we defaulted to yaird, we know that yaird, by design, will fail
at install time and not at boot time, and give an error message, which
we can grab and append to the log
On Thursday 29 December 2005 18:39, Ross Boylan wrote:
On Thu, Dec 29, 2005 at 04:01:15PM +0100, Frans Pop wrote:
Here are the settings I propose to upload the new version of
base-installer with:
- Question asked at medium priority
- Default generator settings (based on [1] and klibc
Thanks, Luis. I'm forwarding your information to the bug so that it'll not
get lost. I'll also write to debian-sparc list, a few people have reported
that corruption there recently, so they will probably willing to test it
out.
Best regards,
Jurij Smakov
Subject: kernel-image-2.6.8-2-686: USB driver ehci_hcd fails to enter ACPI S3
state on IBM Thinkpad T40
Package: kernel-image-2.6.8-2-686
Version: 2.6.8-16sarge1
Severity: normal
*** Please type your report below this line ***
When running ACPI, attempting to enter S3 sleep state is not
Frans Pop wrote:
Hmm. I think it is on the same level as offering static network
configuration over DHCP or, maybe better, (not) loading some modules
during hardware detection.
The main advantage of the patch as I see it is its flexibility: it allows
both us and derivatives to set things
Subject: kernel-image-2.6.8-2-686: e1000 driver stops working after ACPI
suspend/resume cycle on IBM Thinkpad T40
Package: kernel-image-2.6.8-2-686
Version: 2.6.8-16sarge1
Severity: normal
*** Please type your report below this line ***
After resuming operation from an ACPI S3 suspend, system is
Hello,
I would like to get on with the preparations of 2.6.15-rc7 and
schedule an upload to experimental for tomorrow evening UTC.
The following architectures need their configs still to be
updated:
alpha
hppa
m68k
s390
Anyone objecting against this schedule?
It still would be great to
On Thu, Dec 29, 2005 at 11:28:59PM +0100, Frederik Schueler wrote:
The following architectures need their configs still to be
updated:
hppa
I can update hppa's... Could someone remind me how one goes about
doing it?
Cheers,
Kyle
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Package: linux-image-2.6.14-2-386
Version: 2.6.14-6
Severity: normal
I'm in the habit of using alt-left arrow or alt-right arrow to move
between virtual consoles at the linux console.
With this kernel, if I am in tty1 and I alt-left, I get to a blank
console (with a cursor at the top). If I then
[EMAIL PROTECTED] wrote:
2.6.15 should work with older udev.
Not really. udev versions older than 072 do not support the new nested
classes used by the input subsystem in kernels = 2.6.15.
The effect is that device nodes in /dev/input/ will not be created, and
the respective drivers will not be
Hello,
On Thu, Dec 29, 2005 at 06:20:56PM -0500, Kyle McMartin wrote:
I can update hppa's... Could someone remind me how one goes about
doing it?
you need split-config from trunk/scripts/ which probably won't work out
of the box because of the debian architecture name and the kernel one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Dec 2005 17:47:41 +0100
Frans Pop [EMAIL PROTECTED] wrote:
On Thursday 29 December 2005 17:27, Sven Luther wrote:
What if we defaulted to yaird, we know that yaird, by design, will
fail at install time and not at boot time, and give
On Fri, Dec 30, 2005 at 12:56:26AM +0100, Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
2.6.15 should work with older udev.
Not really. udev versions older than 072 do not support the new nested
classes used by the input subsystem in kernels = 2.6.15.
The effect is that device nodes in
On Thu, Dec 29, 2005 at 03:49:42PM -0500, Joey Hess wrote:
Frans Pop wrote:
Hmm. I think it is on the same level as offering static network
configuration over DHCP or, maybe better, (not) loading some modules
during hardware detection.
The main advantage of the patch as I see it is
51 matches
Mail list logo
