Bug#383807: Missing PCI IDs in the sata_via driver

[Julien Louis]

On Sat, Aug 19, 2006 at 08:26:33PM +0200, Martin Michlmayr wrote:
> > The ubuntu dapper kernel include them and seems to work fine with the 
> > following
> > line :
> > { 0x1106, 0x0591, PCI_ANY_ID, PCI_ANY_ID, 0, 0, vt6420 },
> 
> Someone submitted a patch to the kernel folks to add this but there
> was no answer.  I'll ping them.
> 
> See http://www.spinics.net/lists/linux-ide/msg04388.html
 
This patch has been applied in the 2.6.18 source tree. Can you apply
this patch on the 2.6.17 source tree if it's the kernel that will be
shipped by etch ?

-- 
Je n'aime pas travailler, mais j'admets que les autres travaillent.
-+- Arthur Adamov (1908-1970) -+-


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

Bug#387168: Missing SATA support for VIA VT8251 based boards

[Marc 'HE' Brockschmidt]

Heya,

I just needed to download grml to install my new box, which is based on
the VT8251 chipset. Please include the driver in the d-i kernel for
etch, thanks.

Marc, this is my PERSONAL needy self, not the release assistant one
-- 
BOFH #335:
the AA battery in the wallclock sends magnetic interference


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

mkvmlinuz_24_powerpc.changes ACCEPTED

[Debian Installer]

Accepted:
mkvmlinuz_24.dsc
  to pool/main/m/mkvmlinuz/mkvmlinuz_24.dsc
mkvmlinuz_24.tar.gz
  to pool/main/m/mkvmlinuz/mkvmlinuz_24.tar.gz
mkvmlinuz_24_powerpc.deb
  to pool/main/m/mkvmlinuz/mkvmlinuz_24_powerpc.deb


Override entries for your package:
mkvmlinuz_24.dsc - source devel
mkvmlinuz_24_powerpc.deb - optional devel

Announcing to debian-devel-changes@lists.debian.org


Thank you for your contribution to Debian.


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

Re: Preparing linux-2.6 2.6.18-1

[Sven Luther]

On Sat, Sep 23, 2006 at 05:24:22PM +0200, Norbert Tretkowski wrote:
> * Frederik Schueler wrote:
> > Linux 2.6.18 has been released, and it looks like we can do a first
> > upload today. 
> 
> Is there an .orig.tar.gz already?

Sure, it was at http://kernel-archive.buildserver.net/debian-kernel since the
first day of its release.

BTW, i got users asking me about when and if 2.6.18 will enter unstable, seems
users where spoiled by our same-day uploads :)

Friendly,

Sven Luther


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

Bug#389064: linux-image-2.6.17-2-k7: Sporadic Keyboard Freezes for some applications

[Edgar Ibsen]

Package: linux-image-2.6.17-2-k7
Severity: important


The only reason that I submitted this bug under this package is because 
upgrading from 2.6.15 to 2.6.17 seems to cause this bug; I don't 
remember any instances of it when I was using 2.6.15, but since I've 
upgraded to 2.6.17 two days ago I've experienced many instances of 
this bug. I've also verified this bug on two computers with widely different
hardware (except for the processor, which are both K7s). The reason that 
I only upgraded to 2.6.17 two days ago on this computer is because I 
have to use a hacked debian kernel (I need a PowerNow! hack that, of course,
requires custom coding and compilation, so I'm usually too lazy to upgrade it),
but the other computer that I've verified this bug on uses the pre-compiled 
kernel package, so I don't think the hack has anything to do with it.

Basically, there are times when suddenly I can no longer type into 
some applications. I use KDE primarily, but I have also tried XFCE, and 
interestingly enough they are subtly different. With KDE (running an KDE 
app, in this case KVIrc), the app will just ignore (freeze) all keyboard 
input suddenly. With XFCE (running the same KDE app), the app will 
usually just temporarily freeze keyboard input for a few seconds, and then
allow input, though there are rare times when even under XFCE the keyboard
input is completely frozen. In such cases the only way to make the app
accept keyboard input again is to restart the app.

This seems to happen in many apps (and since I use KDE apps 
almost exclusively...). The apps I know of that commonly exhibit 
this bug (and are basically the only ones requiring lots of user input 
that I use), is Yakuake and KVIrc. I end up having to restart Yakuake 
more than 10 times over the course of a day (using F12 a lot seems to 
trigger the bug in many cases, but the bug will NOT appear if the 
only thing you do is open Yakuake and press F12 repeatedly, you have 
to actually use Yakuake for a while; same goes for other apps).

While this bug is probably going to be very hard to actually fix
(since even after so many encounters with the bug I still can't figure 
out exactly what triggers it), it is a VERY incovenient bug that may 
even result in data loss.

Thanks.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: config change: old ptys

[Bastian Blank]

On Sat, Sep 23, 2006 at 05:28:09PM +0200, Bastian Blank wrote:
> Will anyone object if I lower the count of old-style ptys to 16? Or
> should we finaly disable it completely?

Some arches already disabled it.

Bastian

-- 
Not one hundred percent efficient, of course ... but nothing ever is.
-- Kirk, "Metamorphosis", stardate 3219.8


signature.asc
Description: Digital signature

config change: old ptys

[Bastian Blank]

Hi folks

Will anyone object if I lower the count of old-style ptys to 16? Or
should we finaly disable it completely?

Bastian

-- 
The face of war has never changed.  Surely it is more logical to heal
than to kill.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5


signature.asc
Description: Digital signature

Re: Preparing linux-2.6 2.6.18-1

[Norbert Tretkowski]

* Frederik Schueler wrote:
> Linux 2.6.18 has been released, and it looks like we can do a first
> upload today. 

Is there an .orig.tar.gz already?

Norbert


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

Bug#361684: is unuseable on HP OmniBook 4150 on batteries

[maximilian attems]

please keep bugreport on cc :)

On Sat, Sep 23, 2006 at 03:34:32PM +0200, Ronny Standtke wrote:
> > not reading the previous part of your bug report, i have no idea
> > what you mean by unusable,
> 
> FYI here is the previous part of my bug report:
> 
> If the notebook is booted when running on batteries the system is almost
> unuseable. The init process seems to hang right from the start but when you
> press some keys on the keyboard the system seems to "wake up" for some seconds
> and the init process continues bit by bit...
> 
> I tried to use acpi instead of apm (added the kernel boot option
> "acpi=off apm=on" and added apm to /etc/modules) but this was even worse:
> The system bootet without hammering on the keyboard but the timing was
> completely broken. The cursor frequency changed wildly depending on system
> load and the clock was running like crazy (ca. double speed) when opening 
> large applications.
> 

sounds strange, i have seen that once on a very broken motherboard.
are you sure your hardware is ok?
 
> > but you might be interested in testing 
> > linux images 2.6.18 from trunk and try out if acpi=off helps
> > http://wiki.debian.org/DebianKernel
> 
> OK, I will do that (next week).

please do as soon as possible as aboves will be etch kernel
and if you are still affected you need to report upstream soonest,
so we might get a fix for etch. (already late in the game)

regards

-- 
maks


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

Bug#361684: is unuseable on HP OmniBook 4150 on batteries

[maximilian attems]

On Sat, Sep 23, 2006 at 01:56:33PM +0200, Ronny Standtke wrote:
> I just want to add that I updated to the latest version of Debian testing 
> (linux-2.6.17) and the bug is still there: The notebook is unuseable when 
> running on batteries.

not reading the previous part of your bug report, i have no idea
what you mean by unusable, but you might be interested in testing
linux images 2.6.18 from trunk and try out if acpi=off helps
http://wiki.debian.org/DebianKernel

regards

-- 
maks


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

Bug#361684: is unuseable on HP OmniBook 4150 on batteries

[Ronny Standtke]

I just want to add that I updated to the latest version of Debian testing 
(linux-2.6.17) and the bug is still there: The notebook is unuseable when 
running on batteries.


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

Processed: found 378225 in 2.6.17-9

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.9.21
> found 378225 2.6.17-9
Bug#378225: suspend to memory broken in 2.6.17 on Dell Latitude C610
Bug marked as found in version 2.6.17-9.

>
End of message, 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: Preparing linux-2.6 2.6.18-1

[Steve Langasek]

[Dropping -release from cc anyway; there's no possible reason this needs to
be cross-posted to 4 lists]

On Fri, Sep 22, 2006 at 07:12:53AM +0200, Sven Luther wrote:
> On Thu, Sep 21, 2006 at 02:58:31AM -0500, Bill Allombert wrote:
> > On Thu, Sep 21, 2006 at 08:52:15AM +0200, Sven Luther wrote:
> > > There won't be any GR, there will be a new pet proposal until forever, and
> > > endless discussions as we start recalling the DPL, and bashing on the
> > > secretary and what not.

> > In the absence of GR, the current situation is that sourceless
> > firmwares are not allowed in main. This is the reason the RM
> > proposed this GR in the first place.

> The current consensus is that it is well among the power of the RMs to
> ignore a number of bugs for the sarge release, including this one.

I see no evidence that there is a consensus on this point.  Since it's the
RMs who have to make this decision to ignore these bugs, you're not going to
get very far if the RMs don't actually feel empowered to make this decision
on their own.

> > Re-adding them at this stage
> > 1) is against the current social contract

> Yes, but then so is shipping the firmware actually still in main,

So two bugs is better than one?

> and i guess one could evoke the "won't discriminate" clause of the
> SC/DFSG,

 That's not what the DFSG says.

> Now, as said, this is a step back to better jump, and the real solution on
> this is to follow on with what has been done (by upstream) on the qlogic
> drivers, whose firmware is actually already in non-free, even though d-i
> doesn't support it yet. This is an upstream work, and as thus will take time
> to come to debian, but we, the debian kernel team (or at least me and
> Frederik) take the engagement to work on this during etch+1 devel cycle.

If it is the consensus of the project that sourceless firmware doesn't
belong in main, this is a conscious regression in DFSG-compliance relative
to sarge.  I don't think that's acceptable.  We obviously do have the means
to remove this particular subset of non-free firmware from main (technically
imperfect though it may be), and of the firmware that was removed for sarge
the only one that was important enough to get me glared at personally was
qla2xxx -- so what are these other already-removed firmwares that are so
important to have re-added now?  (I did ask for a list, which no one has
provided yet; I can't find the pruning script in the kernel team's svn
repo, or I would look it up myself.)

> But due to everyone (including you), trying to pull the glory to themselves,
> and proposing their pet GR to muddle the issue, without any respect for the
> GRs proposed previously, and because of the loophole in the constitution,

I don't believe there is any loophole there.  The constitution defines what
it means for an amendment to be accepted, and it does not apply to
additional related resolution proposals, it only applies to amendments to a
resolution that are *accepted by the proposer*.  Which means independent
draft proposals are not supposed to reset the minimum discussion period.
(FWIW, it took a hint from AJ for me to recognize that this is what the
constitution actually says, but Ian Jackson -- original author of the
constitution -- has recently confirmed this understanding.)

Anyway, I think we'd be able to get to the point of holding a vote much
sooner if we weren't having distracting side discussions like this one.  I
know it's sucking up time that *I* would rather be spending examining the
various resolutions that are already out there.

> So, given the defaillance of the GR system, there is no point in worrying
> about the vote or not, and always remember, that debian was at the base, and
> still is to a mesure, a system where those who do the work get to do the
> decision, so you know what you have to do if you want those firmwares not to
> be in main :)

Well, all /I/ have to do to keep the reintroduced firmware blobs from being
in etch is to freeze the linux-2.6 package at 2.6.17 :/

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


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

Re: Let's vote ...

[Manoj Srivastava]

Hi,
On Fri, 22 Sep 2006 07:21:12 +0200, Sven Luther <[EMAIL PROTECTED]> said: 

> This issue remains, and it is still not solved. This has got the
> approval of Steve Langasek (who said that his proposal and this
> where orthogonal and a separate GR), of our DPL, who said he would
> postpone his own GR proposal for post etch, as well as the proposer
> of this GR.

> There also is clearly no amendment proposal of this GR, only of the
> various and numerous other GR proposals out there, and it is clear
> now that we either have to have a period of calm and reflection
> before going ahead, which is better done once etch is released, or
> sit back and see various well-thinking DDs filibustering the vote
> process upto irrelevance.

Have there been seconds for this proposal that I have missed?
 And, as to timing, I think that the  usual minimal  discussion and
 voting period applies, unless the DPL intervenes, of course.

manoj

-- 
"A dirty mind is a joy forever." Randy Kunkee
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#387781: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#387781: Install failed on SATA drive)

[Michael Burschik]

I can confirm that 2.6.18 detects the SATA disk.


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

Bug#375194: Can you test 2.6.18-rc7 ...

[Sven Luther]

On Tue, Sep 19, 2006 at 08:38:42PM +0200, maximilian attems wrote:
> On Tue, Sep 19, 2006 at 08:26:11PM +0300, Yavor Doganov wrote:
> > maximilian attems wrote:
> > > 
> > > ppc builds modular input i8042, so we need to try to modprobe it.
> > >
> > > is your root device there when you are dropped to the rescue shell?
> > 
> > The prompt is (initramfs), and trying
> > 
> > modprobe i8042
> > 
> > results in "FATAL: Error inserting i8042 ($path_to_i8042.ko): Device
> > or resource busy".
> 
> sure that is harmless.
>  
> > > what are your bootargs?
> > 
> > ramdisk_size=8192 video=atyfb:vmode:13,cmode:16
> 
> hmm what about passing an root bootarg??
> svenl i'm not familiar with that box, please explain how. :)

Probably in yaboot.conf's append= line, or quik's one if on old-world.

Friendly,

Sven Luther


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

Re: proposal: kernel team IRC meeting on Saturday, 30th September 16:00 UTC

[Sven Luther]

On Fri, Sep 22, 2006 at 08:56:58PM -0700, Jurij Smakov wrote:
> On Fri, Sep 22, 2006 at 01:37:18PM +0200, Frederik Schueler wrote:
> 
> > I would like to propose an IRC meeting for all kernel team members, to
> > discuss where we stand and what we want to do in the future, concerning
> > kernel firmwares. 
> > 
> > The meeting should take place in #debian-kernel on irc.debian.org on 
> > 
> > Saturday, 30th September 16:00 UTC
> 
> This time is fine with me, would be even better if it would be a couple of 
> hours 
> later.

Actually, now that i think of it, it would be best a bit later for me also,
since this would be 18h00 european time, and thus in the middle of the evening
meal, and the most critical time with the kids.

What about 18:00 UTC ? 

Friendly,

Sven Luther


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