Bug#312973: kernel-image-2.6.11-1-686: system clock drifts ahead of hardware clock
Package: kernel-image-2.6.11-1-686 Version: 2.6.11-5 Severity: important After upgrading from kernel-image-2.6.8-1-686, the system clock drifts ahead of the hardware clock approximately two minutes per hour, sometimes more. It's not uncommon for it to drift 2 full hours in 7 hours' time. I recently tested again with 2.6.8, and it does not drift even after about half an hour of operation. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.11-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information --- [This E-mail scanned for viruses by Declude Virus] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Suspend2 patch, mkinitrd / mkinitramfs ?
I'm looking at the stuff that Martin Krafft did for the Debian mkinitrd setup to go with the kernel-patch-suspend2 (Debian experimental) enabled kernels. Nice work, Martin; I did not know you could add conffiles to a kernel like that with a patch. Very good. Many of the things being done by the mkinitrd script (/usr/share/doc/kernel-patch-suspend2/mkinitrd-script) are indeed kludgy. On my laptop, I'm doing similar things to make resume happen for my hand compiled suspend2 kernels. I started from the same source Martin began with, the www.suspend2.net WiKi. I also have a script that adds 855resolution and a script to run it to the initrd, since my laptop with i855GM came with a 1400x1050 LCD (probably by mistake -- the manufacturer spec says 1024x768 -- I lucked out; the X server log told me what it really is) but the VBIOS has no mode for it. Additionally, the Linux mtrr system sets up the caching incorrectly, and I must add a script that sets the mtrr correctly; otherwise, the machine runs very slowly when it has 1Gib RAM installed and CONFIG_HIGHMEM is enabled. The thing is, that due to the design of mkinitrd and the standard linuxrc it ships with, several of these mkinitrd scripts need to modify the linuxrc script. I must be careful to ensure that they happen in the right order. For instance, the mtrr hack must be first, and the 855resolution hack must happen prior to resume from suspend, or the X server can't switch back to graphics mode, and bails out. What would fix this is to have the linuxrc script run some _early_ hooks from a 'run-parts' style directory. I think they should be able to run between the "call /loadmodules" and the "call /script", but certainly _before_ the "do_swsusp". Perhaps the "do_swsusp" should be extended to support Suspend2? It really is superior in several ways to the suspend already built into the kernel. I certainly hope that Suspend2 eventually is merged into the mainstream kernel. I believe they are working toward that goal right now. Q: Is there a revision control repository of the initrd-tools that I can use to keep track of it's development, especially if a transition to initramfs is planned? I tried to change the mkinitrd command to a shell script that created a compressed CPIO archive, but it did not work right. The 855resolution hack did not seem to "take", but worse, the 'mtrr' hack did not work... I think it's becuase the kernel does it's thing after the initramfs is finished. -- Karl Hegbloom <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312901: CD/DVD burning doesn't work with kernel-image-2.6.11-1-k7 and ide-scsi
On Fri, Jun 10, 2005 at 07:13:57PM +0200, Luca wrote: > Package: kernel-image-2.6.11-1-k7 > Version: 2.6.11-5 > > I tried burning a DVD with K3B 0.11.20 with the ide-scsi module loaded > and my system froze (perhaps a kernel panic?). I tried another time, and > my computer froze again. That didn't happen with kernel 2.6.8, or with > kernel 2.6.11 without ide-scsi. My understanding is that ide-scsi is severly obsoleted in later 2.6 kernels, and will soon go away, so please don't use it, and everything should be fine, as you noticed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-source-2.4.{24,25,26} in etch?
On Wed, Jun 08, 2005 at 08:30:18PM +0200, Jeroen van Wolffelaar wrote:
> (note, I'm not subscribed)
>
> Hi,
>
> kernel-source-2.4.{24,25,26} just made it into Etch -- I'm sure that was
> not really intentional, and those can rather be removed from unstable?
> If so, please do file a bug (one listing all three would do) on
> ftp.debian.org.
I believe there was partially such a bug report against some of those
packages. There still are 2.4.26 apus kernels in the archive last i checked.
> Second point -- would there be any easy way you can think of some
> non-ftpmaster involving way to prevent this from happening in the
> future? Like, making the kernel-source-2.4 and kernel-source-2.6
> package, building kernel-source-2.{4,6}.X binary package? I do think you
> only need one major kernel line version simultaneously, right?
Yes and no. but let's sort out the metapackages thingy once the common kernel
package is out. We need to unify the different kernel-latest thingies too, so
this could easily be added, but it is still not enough, since having 2.6.12 in
the archive is not a reason for immediate dropping of 2.6.11, since there is
likely to be a transition period where it is meaningfull to provide our users
with both, in order to more easily check newly introduced bugs or regressions.
> If that's not possible, for whatever reason I'm sure you're much more
> familiar with than I am, of course then it's not possible, and instead
> removal requests can best be filed every time a transition to a new
> minor kernel version is completed.
The main problem is that usually such removal requests got processed ages
after the request. This is changing now with the new more dynamic ftp-master
team, but i guess a request for removal get's easily lost in the noise or
something, not sure how you see that on your side ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux kernel and packages providing kernel-source
On Thu, Jun 09, 2005 at 09:55:05PM -0400, Jurij Smakov wrote: > On Thu, 9 Jun 2005, Aurelien Jarno wrote: > > >Hi all, > > > >The Linux kernel source packages are all providing a virtual package > >called kernel-source, so that other packages such as kernel patches can > >depend on them. The freebsd kernel (kfreebsd5-source) was recently > >included in Debian (mainly for the GNU/kFreeBSd port) and also provides > >kernel-source. > > > >This seems to confuse the users (what I understand) as we received a bug > >telling that aptitude proposes to install kfreebsd5-source when installing > >a kernel-patch. > > > >That's why we've deciced to provide the freebsd-kernel-source virtual > >package instead of kernel-source. > > > >I think it would be nice that the Linux kernel-source packages follow this > >policy, and thus provide linux-kernel-source. I don't say all package > >should be reuploaded, but maybe in a first time, the newest uploads could > >provide both kernel-source and linux-kernel-source, and the kernel patches > >depends on kernel-source | linux-kernel-source. Then in a second time it > >would be possible to remove references to kernel-source. > > > >I would like to have your comments on that. > > > >Bye, > >Aurelien > > Hi Aurelien, > > The kernel team is currently planning a transition to a different naming > and packaging scheme. Anticipating the inclusion of freebsd and hurd > kernels into the distribution we have pretty much agreed that future > kernel packages are going to be called linux-source, linux-headers, > linux-image and so on. It would be nice if you could adopt the same naming > scheme for freebsd packages (freebsd-source, freebsd-image, etc). It will > then be consistent everywhere and will allow to avoid the namespace > clashes. Notice that i believe the source package should be linux-kernel, and not linux-source. Would make more sense that way. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 01:35:26PM -0700, Steve Langasek wrote: > On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > > Or should i rely on the ubuntu toolchain, and use that to upload kernels > > to sid in the near future ? > > *NO.* There is no excuse for uploading packages to unstable/main that can't > be built using Debian! So, when will i get a biarch toolchain in debian ? The alternative being naturally to maintain a fork in people.debian.org, which could be done, but will be a mess or whatever. At least having the stuff in experimental ASAP would be a first step, but i have not yet gotten any feedback on this, nor any plan to get it implemented or whatever. In any case, i do *not* plan to do any further upload of sid kernels without pure 64bit support. BTW, it seems that as a result of our little support on this, IBM has apparently donated a couple of boxes to debian, or at least thought so, who ended up being the augsbourg university ones. I would love to know who inside debian was involved in this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311357: kernel-image-2.6.8-2: via-rhine fails to reserve I/O region, no networking available
Horms wrote: tag 311357 +pending thanks Hi, I think I have isolated the patch that caused this problem, I have put up some test 2.6.8 images that do not include the patch in question. http://debian.vergenet.net/testing/ Thanks. I can confirm that via-rhine is working with my card again! Craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
CS00003271 - Please review your case resolution - (Resolved)
Below is a response to your case number CS3271 submitted to Broadcom NIC Technology Support. Case Title: GPLed driver and binary-only firmware blobs. Response from Broadcom: This can be downloaded from the following Link: http://www.kernel.org/git/?p=linux/kernel/git/davem/tg3-2.6.git;a=commitdiff;h=49cabf49abd7676d026a61baabf5aae9337a82be 2) Acenic is not supported by us, this was the Alteon's product. This case will be closed in seven days, if you need more information regarding this case, please reply to this e-mail within next seven days, otherwise you are required to open a new case through the web form @ http://www.broadcom.com Thank you, Broadcom NIC Technology Support Team == CONFIDENTIALITY AND PRIVILEGE NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, contain proprietary or confidential information and information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please destroy the original transmission and its attachments without reading or saving in any manner. Thank you.
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > Or should i rely on the ubuntu toolchain, and use that to upload kernels > to sid in the near future ? *NO.* There is no excuse for uploading packages to unstable/main that can't be built using Debian! -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: does not remove capabilities
also sprach Jurij Smakov <[EMAIL PROTECTED]> [2005.06.10.0258 +0200]: > In order for the capability stuff to function the capability.ko > module should be loaded. The situation you describe indeed occurs > when capability.ko is not loaded into the kernel. So I would say > that this is lcap bug, as it is fails to inform the user that > capabilities cannot be removed. Yes, I agree with you. Alternatively, it should just load the module if not present. > I have also tried it with capability module loaded, and then the > command 'lcap CAP_SYS_MODULE' strips _all_ the capabilities, so it > seems to be broken in more than one way. After that loading the > modules is, in fact, impossible. I'll file the bug against lcap > once I have a confirmation that it indeed misbehaves. I can confirm this behaviour on both, Debian sid with 2.6.11 and lcap 0.0.6, and SuSE 9.2 with 2.6.8 and lcap 0.0.3. Cheers, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! "in any hierarchy, each individual rises to his own level of incompetence, and then remains there." -- murphy (after dr. laurence j. peter) signature.asc Description: Digital signature
We guarantee 100% authentic software.
Get latest version, cds and download under $99 http://tbfpl.sze7d9a3pkahpba.henogenyhb.com The Price Of Freedom Is Eternal Vigilance. Badness is only spoiled goodness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:45:08PM +0200, Christoph Hellwig wrote: > On Fri, Jun 10, 2005 at 07:36:08PM +0200, Sven Luther wrote: > > On Fri, Jun 10, 2005 at 07:16:02PM +0200, Christoph Hellwig wrote: > > > On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > > > > timeframe to get a ppc64 biarch toolchain in sid or even experimental ? > > > > Or > > > > should i rely on the ubuntu toolchain, and use that to upload kernels > > > > to sid > > > > in the near future ? Together with a statically built procps naturally ? > > > > > > The sid procpc works just fine with ppc64 kernel, no need to mess with > > > it at all. > > > > Oh, fine, so there is no risk of overflow of the process id. > > The process id in Linux is always 32bits, and unless you tweak > /proc/sys/kernel/pid-max the actual range used is even smaller. > > > What about the sarge procps ? > > It shouldn't be any different. I have been running ppc64 kernels with > sarge for a long time. And if there's a bug in procps somewhere where > it can't deal with some fields beeing bigger in 64bit kernels that > should be fixed in procps instead of needing another set of binaries. Ok, fine with me, you are the expert. Did you try already the kernels and stuff i announced on : http://people.debian.org/~luther/ppc64/PPC64.README It didn't get the interest i expected, but maybe just because people didn't really notice. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:36:08PM +0200, Sven Luther wrote: > On Fri, Jun 10, 2005 at 07:16:02PM +0200, Christoph Hellwig wrote: > > On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > > > timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or > > > should i rely on the ubuntu toolchain, and use that to upload kernels to > > > sid > > > in the near future ? Together with a statically built procps naturally ? > > > > The sid procpc works just fine with ppc64 kernel, no need to mess with > > it at all. > > Oh, fine, so there is no risk of overflow of the process id. The process id in Linux is always 32bits, and unless you tweak /proc/sys/kernel/pid-max the actual range used is even smaller. > What about the sarge procps ? It shouldn't be any different. I have been running ppc64 kernels with sarge for a long time. And if there's a bug in procps somewhere where it can't deal with some fields beeing bigger in 64bit kernels that should be fixed in procps instead of needing another set of binaries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:16:02PM +0200, Christoph Hellwig wrote: > On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > > timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or > > should i rely on the ubuntu toolchain, and use that to upload kernels to sid > > in the near future ? Together with a statically built procps naturally ? > > The sid procpc works just fine with ppc64 kernel, no need to mess with > it at all. Oh, fine, so there is no risk of overflow of the process id. What about the sarge procps ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312901: CD/DVD burning doesn't work with kernel-image-2.6.11-1-k7 and ide-scsi
Package: kernel-image-2.6.11-1-k7 Version: 2.6.11-5 I tried burning a DVD with K3B 0.11.20 with the ide-scsi module loaded and my system froze (perhaps a kernel panic?). I tried another time, and my computer froze again. That didn't happen with kernel 2.6.8, or with kernel 2.6.11 without ide-scsi. My burner is a Liteon 851s. My motherboard is an Asus A7V880 (KT880), and DMA is enabled. C library: Version: 2.3.2.ds1-22 Interrupts: 0: 30312748IO-APIC-edge timer 1: 4638IO-APIC-edge i8042 8: 4IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 80817IO-APIC-edge i8042 14: 6805IO-APIC-edge ide0 15:296IO-APIC-edge ide1 169: 23836 IO-APIC-level libata 177: 91567 IO-APIC-level SysKonnect SK-98xx, DC30plus[0] 185: 3 IO-APIC-level ohci1394 193: 92 IO-APIC-level uhci_hcd, uhci_hcd, uhci_hcd, uhci_hcd, ehci_hcd 201:3019848 IO-APIC-level EMU10K1, nvidia NMI: 0 LOC: 30314907 ERR: 0 MIS: 0 I/O Ports: -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial 0480-0487 : pnp 00:09 0800-0803 : PM1a_EVT_BLK 0804-0805 : PM1a_CNT_BLK 0808-080b : PM_TMR 0820-0823 : GPE0_BLK 0c00-0c7f : pnp 00:09 0c00-0c07 : it87 0cf8-0cff : PCI conf1 e400-e4ff : :00:09.0 e400-e4ff : SysKonnect SK-98xx e800-e8ff : :00:0f.0 e800-e8ff : sata_via eea0-eebf : :00:10.0 eea0-eebf : uhci_hcd eec0-eedf : :00:10.1 eec0-eedf : uhci_hcd ef00-ef1f : :00:10.2 ef00-ef1f : uhci_hcd ef20-ef3f : :00:10.3 ef20-ef3f : uhci_hcd ef40-ef5f : :00:0d.0 ef40-ef5f : EMU10K1 ef88-ef8f : :00:0d.1 ef88-ef8f : emu10k1-gp ef90-ef9f : :00:0f.0 ef90-ef9f : sata_via efa0-efa7 : :00:0f.0 efa0-efa7 : sata_via efa8-efab : :00:0f.0 efa8-efab : sata_via efac-efaf : :00:0f.0 efac-efaf : sata_via efe0-efe7 : :00:0f.0 efe0-efe7 : sata_via fc00-fc0f : :00:0f.1 fc00-fc07 : ide0 fc08-fc0f : ide1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ppc64 biarch toolchain and 64bit powerpc kernels ...
On Fri, Jun 10, 2005 at 07:09:51PM +0200, Sven Luther wrote: > timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or > should i rely on the ubuntu toolchain, and use that to upload kernels to sid > in the near future ? Together with a statically built procps naturally ? The sid procpc works just fine with ppc64 kernel, no need to mess with it at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ppc64 biarch toolchain and 64bit powerpc kernels ...
Hello, Now that sarge is released, and we are concentrating on the upcoming etch release, as shown with the new c++ toolchain announcement from doko, i plan to retire the 32bit kernels for power3 and power4, and to pass as soon as possible to 64bit kernels for those arches. I have already built a -pseries version, which altough not power4 optimized, will run on everything but legacy iseries (those predating the power5 ones), which was successfully tested on both pmacs G5 (a dying race now it seems though), and IBM power5 boxes (altough the ones with logical partitions still seem to be somewhat buggy). And plan to do a -legacy-iseries build as well as a power4 optimized version in the near future. These kernels where built in a sarge chroot using the ubuntu biarch ppc64 toolchain, and i am already building .udebs for those kernels, as well as daily d-i images, and have an unofficial .udeb archive which will provide those .udebs. I lacked time to patch base-installer and net-fetcher or whatever it is called to get the .udebs from there though, and would like these packages to get integrated in sid and then etch as fast as possible, to make testing of this stuff easier. So, i would like to ask the debian toolchain maintainers what is the expected timeframe to get a ppc64 biarch toolchain in sid or even experimental ? Or should i rely on the ubuntu toolchain, and use that to upload kernels to sid in the near future ? Together with a statically built procps naturally ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229757: Download + CDS all OS and all under $15-$99 just
Any Software just in under $15-$99, Xp-adobe etc http://ftbxj.vkzsgudosndkswd.goodingdn.com A signature always reveals a man's character- and sometimes even his name. Was it doubted that those who corrupt their own bodies conceal themselves? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312871: initrd-tools: please provide support for udev _and_ selinux
Package: initrd-tools Version: 0.1.77 Severity: wishlist just like is done in FC2 and above's initrd, please could you consider putting uclib'd udev into the initrd, and then making sure that the programs in it are selinux-enabled / aware? i had to make a pig's ear of debian/selinux when udev is installed because of tmpfs extended attributes, because of mounting /dev, because the recreation of the non-persistent entries in /dev end up with the wrong selinux attributes, i had to run "restorecon" on every single entry **AFTER** udev had run... it was awful. such a mess, and the boot-time is adversely affected, too. oh - and as for /.dev - CHRIST what an awful mess, and the selinux maintainers on www.nsa.gov won't even LISTEN about supporting correct restoration of file contexts in /.dev, so if you accidentally end up losing the file contexts on anything in /.dev - YOU CAN'T BOOT THE MACHINE. [some types of filesystem corruption can result in extended attributes being truncated. if that happens to anything in /.dev, you are xed for a boot. at least with /dev being managed by udev, the selinux file contexts on your device inodes get recreated!] i can't remember the details, but the half-way-house solution of debian at the moment (where /dev is managed by and created by an initscript /etc/init.d/udev) is a bolloxed up idea. Fedora's solution - start udev from the initrd: correct. Gentoo's solution - don't _have_ an initrd: correct. Debian's solution - start up initially in a half-cocked environment, move /dev out the way to /.dev and then start udev later: total bollocks. l. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux highfield 2.6.11-1-686 #1 Fri May 20 07:34:54 UTC 2005 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.1GNU cpio -- a program to manage ar ii cramfsprogs 1.1-4 Tools for CramFs (Compressed ROM F ii dash 0.4.21 The Debian Almquist Shell ii fileutils 5.2.1-2The GNU file management utilities ii util-linux2.12-6 Miscellaneous system utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#67718: What IS OEM software and why do you care?
LOWEST PRICE GUARANTEED! download and Buy Cds http://bsu.cjyrftcnrmu19dc.scombronebf.com The quality will remain when the price is forgotten. Reality is what won't go away when you stop beliving in it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312687: linux terminal doesn't reset colors on logout
On Thursday 09 June 2005 18:34, you wrote: | On Thu, 2005-09-06 at 17:07 +0200, Siward de Groot wrote: | >when i log in on a VT as root and su to siward, | > then siward's .bashrc changes colors of text in VT, | | The cause is: | alias ls='ls -color' No, it's not ; my .bashrc ouputs ansi color escapes, because i like to have a white background in an xterm. In a linux term these don't work (i get grey on black), so that's how i noticed it doesnt reset colors. It just didn't seem right to not reset colors on logout. | > If you decide not to fix this (it's only a feature request after all), | >could you point me to the sources that control | >linux terminal's colour behaviour ? | | See above. Another reason i asked this is that when i use modified colors in a term, and i start a program that also modifies colors, there's no way for such a program to reset colors to what they were before, because it has no way of finding out what they were, at least no way that i know of. | BTW ... I never su to 'user' from root ... my first account is always| | admin, from which I use 'sudo' to admin the box. A matter of taste, i guess, i just log in as root, su to xuser , and startx, If there's anything i want to do in the terminal (mount for example), i usually need root for it. It's just a single-user box. Thanks for your reply. Siward de Groot (home.wanadoo.nl/siward) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311357: kernel-image-2.6.8-2: via-rhine fails to reserve I/O region, no networking available
tag 311357 +pending thanks Hi, I think I have isolated the patch that caused this problem, I have put up some test 2.6.8 images that do not include the patch in question. http://debian.vergenet.net/testing/ -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#311357: kernel-image-2.6.8-2: via-rhine fails to reserve I/O region, no networking available
Processing commands for [EMAIL PROTECTED]: > tag 311357 +pending Bug#311357: kernel-image-2.6.8-2: via-rhine fails to reserve I/O region, no networking available There were no tags set. Tags added: pending > 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#312845: Sarge Crashed by Evolution (?)
Package: kernel-image-2.6.11-1-k7 Version: 2.6.11-5 I apologise in advance for the paucity of information here but I see no point in wasting excess bandwidth with log files etc until I have some idea what you need. Briefly, I have been running this kernel since the morning of June 6th and it crashed once in the evening but I was not logged in and my daughter was using several apps at once. I posted a message to the debian-kernel list at that time but it was ignored. This morning it crashed again with only evolution in use and it spontaneously rebooted a few minutes later. Crashes: Jun 06 22:23 Jun 10 08:05 Jun 10 08:11 Here (using less with line-numbering on) is part of the kern.log from the Jun 06 event (I already posted a bit more of this to debian-kernel). There seems to be potentially useful debugging info here. There are no such entries for Jun 10 but the reset switch was hit much sooner for the first one (after verifying that the network card was not responding) and the second was spontaneous. Thankfully evo has not died again so I can send :-). Login via gdm/event start: --- 730 Jun 6 19:30:48 cal kernel: nfs warning: mount version older than kernel731 Jun 6 20:28:23 cal kernel: apm: BIOS version 1.2 Flags 0x03 (Driver ver731 sion 1.16ac) 732 Jun 6 20:28:23 cal kernel: apm: disabled on user request. 733 Jun 6 20:28:23 cal kernel: agpgart: Found an AGP 3.5 compliant device a733 t :00:00.0. 734 Jun 6 20:28:23 cal kernel: agpgart: Putting AGP V3 device at :00:00734 .0 into 4x mode 735 Jun 6 20:28:23 cal kernel: agpgart: Putting AGP V3 device at :01:00735 .0 into 4x mode 736 Jun 6 20:28:23 cal kernel: [drm] Loading R200 Microcode 737 Jun 6 20:28:38 cal kernel: nfs warning: mount version older than kernel738 Jun 6 22:23:27 cal kernel: scheduling while atomic: metacity/0x1e00738 /7039 739 Jun 6 22:23:27 cal kernel: [schedule+1206/1216] schedule +0x4b6/0x4c0 740 Jun 6 22:23:27 cal kernel: [__get_free_pages+51/64] __get_free_pages+0740 x33/0x40 741 Jun 6 22:23:27 cal kernel: [schedule_timeout+181/192] schedule_timeout741 +0xb5/0xc0 End of event/reboot: --- 2407 Jun 6 22:24:01 cal kernel: [__pollwait+0/208] __pollwait +0x0/0xd0 2408 Jun 6 22:24:01 cal kernel: [syscall_call+7/11] syscall_call +0x7/0xb 2409 Jun 6 22:39:11 cal kernel: klogd 1.4.1#17, log source = /proc/kmsg star 2409 ted. 2410 Jun 6 22:39:11 cal kernel: Inspecting /boot/System.map-2.6.11-1-k7 --- Reference to previous report: On Wed, 2005-01-06 at 17:01 +0200, maximilian attems wrote: > reassign 311507 alsa-base > stop > > as indicated in a response to that message try newer kernel from unstable. -- --gh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#312699: Please have hotplug rescan the scsi bus for scsi loads.
On Fri, Jun 10, 2005 at 05:53:30PM +0900, Horms wrote: > > This works just fine when you use a 2.6 kernel. With the 2.4 kernel > > even the manual scan is extremly dangerous. > > I notice from the initial bug report that the kernel in question here is > 2.4.27, which I guess means a hotplug script is in order. Marco, do you > have any advice on how this should be done? As said even a hotplug script on 2.4.x would be dangerous. Anything that requires hotplugging or rescanning of scsi devices should absolutely use 2.6.x. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312687: linux terminal doesn't reset colors on logout
On Thu, Jun 09, 2005 at 12:34:43PM -0400, Guy Hulbert wrote: > On Thu, 2005-09-06 at 17:07 +0200, Siward de Groot wrote: > > Package: kernel-image-2.6-386 > > Version: 101 > > Severity: wishlist > > > > Hello kernel maintainers, > > > >when i log in on a VT as root and su to siward, > > then siward's .bashrc changes colors of text in VT, > > The cause is: > alias ls='ls -color' > just comment this out. You can modify /etc/skel/.bashrc > to make sure it doesn't come back. I am closing this bug, as I agree it is a userspace configuration issue, not a kernel problem. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312457: kernel-source-2.6.11: Enable CONFIG_AUDIT in kernel configuration, it's needed for SELinux
On Wed, Jun 08, 2005 at 11:36:43AM +0200, Isaac Clerencia wrote: > Package: kernel-source-2.6.11 > Version: 2.6.11-5 > Severity: wishlist > > SELinux needs CONFIG_AUDIT enabled in kernel configuration (General > section) to be able to log. A non-logging SELinux is in fact quite > useless so it would be really nice to have CONFIG_AUDIT enabled in next > kernels. > > Best regards That looks like it would change the Kernel ABI. So we should probably hold off until either it is changed for some other (security) reason (change + change = change), or until 2.6.12. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312457: kernel-source-2.6.11: Enable CONFIG_AUDIT in kernel configuration, it's needed for SELinux
On Friday, 10 June 2005 10:12, Horms wrote: > That looks like it would change the Kernel ABI. > So we should probably hold off until either it is > changed for some other (security) reason (change + change = change), > or until 2.6.12. Yeah, sure. I didn't wanted it changed for the current kernel ;) -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: <[EMAIL PROTECTED]> | Debian: <[EMAIL PROTECTED]> pgpkaXO7gdhC9.pgp Description: PGP signature
Bug#312687: marked as done (linux terminal doesn't reset colors on logout)
Your message dated Fri, 10 Jun 2005 17:45:59 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#312687: linux terminal doesn't reset colors on logout 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; 9 Jun 2005 15:08:12 + >From [EMAIL PROTECTED] Thu Jun 09 08:08:12 2005 Return-path: <[EMAIL PROTECTED]> Received: from master.debian.org [146.82.138.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DgOdf-000182-00; Thu, 09 Jun 2005 08:08:12 -0700 Received: from smtp06.wanadoo.nl [194.134.35.146] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DgOde-0002An-00; Thu, 09 Jun 2005 10:08:10 -0500 Received: from c3eea29e7.cable.wanadoo.nl (c3eea29e7.cable.wanadoo.nl [62.234.41.231]) by smtp6.wanadoo.nl (Postfix) with ESMTP id F171445907 for <[EMAIL PROTECTED]>; Thu, 9 Jun 2005 17:08:09 +0200 (CEST) From: Siward de Groot <[EMAIL PROTECTED]> Organization: org To: "B. Bunny" <[EMAIL PROTECTED]> Subject: linux terminal doesn't reset colors on logout Date: Thu, 9 Jun 2005 17:07:57 +0200 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] 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-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6-386 Version: 101 Severity: wishlist Hello kernel maintainers, when i log in on a VT as root and su to siward, then siward's .bashrc changes colors of text in VT, if siward exits, so i become root again, colors remain those of siward. Exiting, so login prompt comes up, doesn't reset colors either, so it looks like it could be abused on real terminals to set color to black on black, but i'm not sure, as i don't have real terminals. This is not really a problem for me, but it seems kinda stupid to reset colors as part of PS1, so maybe you would like to improve this ? Maybe with environment variables TERMFG and TERMBG, each set to ascii of hex values of rgb of color and terminal setting these to correct values whenever color changes, and resetting colors when a subshell exits but resetting envvars to new colors when a normal program exits, to allow color-setting programs ? I hope this is doable. Anyway, a reset to standard (white on black) for login should be possible. While i'm talking to you, i would like to mention that i am getting errorrmessages like : "atkbd.c: spurious ack on atikbd0/seria0. Some program, like XFree86, might be trying to access hardware directly." But it's not XFree doing that, it's mc (which i invoke and quit immediately, because it resets colors). And you'll need to change the 'XFree86' anyway, when etch uses X.org . If you decide not to fix this (it's only a feature request after all), could you point me to the sources that control linux terminal's colour behaviour ? Anyway, thanks for maintaining the thing (and all the other things you maintain ofcourse). have fun ! Siward de Groot (home.wanadoo.nl/siward) --- Received: (at 312687-done) by bugs.debian.org; 10 Jun 2005 10:48:21 + >From [EMAIL PROTECTED] Fri Jun 10 03:48:21 2005 Return-path: <[EMAIL PROTECTED]> Received: from koto.vergenet.net [210.128.90.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1Dgh3k-0005xZ-00; Fri, 10 Jun 2005 03:48:20 -0700 Received: by koto.vergenet.net (Postfix, from userid 7100) id 4DC7434030; Fri, 10 Jun 2005 19:19:59 +0900 (JST) Date: Fri, 10 Jun 2005 17:45:59 +0900 From: Horms <[EMAIL PROTECTED]> To: Guy Hulbert <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Cc: Siward de Groot <[EMAIL PROTECTED]>, "B. Bunny" <[EMAIL PROTECTED]> Subject: Re: Bug#312687: linux terminal doesn't reset colors on logout Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> X-Cluestick: seven User-Agent: Mutt/1.5.9i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin
Re: Bug#312699: Please have hotplug rescan the scsi bus for scsi loads.
On Jun 10, Horms <[EMAIL PROTECTED]> wrote: > > > I'd start with the kernel. If the kernel people say that this cannot be > > > fixed in the driver then you could write a script for > > > /etc/hotplug.d/ieee1394/ . > I notice from the initial bug report that the kernel in question here is > 2.4.27, which I guess means a hotplug script is in order. Marco, do you > have any advice on how this should be done? As I wrote, add a script to /etc/hotplug.d/ieee1394/. Make it log the environment and you will see which variables you can test for. But as hch explained, bus rescans can crash the system so I will not add such a script to the package (and I do not want to waste time supporting 2.4 kernels anyway). -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#312699: Please have hotplug rescan the scsi bus for scsi loads.
reassign 312699 hotplug thanks On Thu, Jun 09, 2005 at 10:00:02PM +0200, Christoph Hellwig wrote: > On Thu, Jun 09, 2005 at 07:14:22PM +0200, Marco d'Itri wrote: > > reassign 312699 kernel > > thanks > > > > On Jun 09, "Michael Heldebrant Ph.D" <[EMAIL PROTECTED]> wrote: > > > > > For a Dell Latitude X200 laptop and docking station is is necessary to > > > manually run scsiadd -s to enable the cdrom drive through the firewire > > > interface. Is there a way to intelligently rescan the scsi bus when > > > potential scsi devices may enter and leave the system or should I look > > > into reporting a bug against the sbp2 kernel module? > > I'd start with the kernel. If the kernel people say that this cannot be > > fixed in the driver then you could write a script for > > /etc/hotplug.d/ieee1394/ . > > If you can make it run scsiadd only on this specific system then I could > > add it to the hotplug package. > > This works just fine when you use a 2.6 kernel. With the 2.4 kernel > even the manual scan is extremly dangerous. I notice from the initial bug report that the kernel in question here is 2.4.27, which I guess means a hotplug script is in order. Marco, do you have any advice on how this should be done? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel-source-2.4.{24,25,26} in etch?
On Wed, Jun 08, 2005 at 08:30:18PM +0200, Jeroen van Wolffelaar wrote:
> (note, I'm not subscribed)
>
> Hi,
>
> kernel-source-2.4.{24,25,26} just made it into Etch -- I'm sure that was
> not really intentional, and those can rather be removed from unstable?
> If so, please do file a bug (one listing all three would do) on
> ftp.debian.org.
2.4.25 seems to be needed for some architectures, but 2.4.24 and 2.4.26 should
probably go. Can you file a bug for this?
2.6.10 should also be killed, but there needs to be an hppa update
before that can happen.
http://people.debian.org/~dannf/kernel-stats/kernel-avail.html
> Second point -- would there be any easy way you can think of some
> non-ftpmaster involving way to prevent this from happening in the
> future? Like, making the kernel-source-2.4 and kernel-source-2.6
> package, building kernel-source-2.{4,6}.X binary package? I do think you
> only need one major kernel line version simultaneously, right?
We have found there is such a need in the past and right now too.
> If that's not possible, for whatever reason I'm sure you're much more
> familiar with than I am, of course then it's not possible, and instead
> removal requests can best be filed every time a transition to a new
> minor kernel version is completed.
Thats pretty much where we are now. This has proved to be
quite a bit of overhead, because of the sheer number of
kernel source packages (one for the source and then one for each
arhitecture) per kernel version. We are working on consolidating
this to a single package for all architectures supported by the kernel
team (anything outside the kernel team is beyond out control anyway)
and this should aleveiate this problem.
--
Horms
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
