Re: SMP PReP (was Re: The powerpc port should be removed from etch release candidates ...)
On Wed, May 24, 2006 at 11:14:33PM -0500, Troy Benjegerdes wrote: > > > SMP never worked under Linux on those machines because the AIX boot > > > sequence to enable it was never successfully reverse-engineered. > > > > Ah, ok, then it makes no sense to build a special kernel for those, until > > more > > information is found about the above. > > I have a Motorola MTX PreP system with dual 604e's that I can test this > on. But you never managed to get SMP working on it, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools confdir mv
maximilian attems wrote:
> latest initramfs-tools mv /etc/mkinitramfs /etc/initramfs-tools
> for better consistency. (package on mentors not yet in unstable)
>
> d-i uses in base-installer as confdir /target/etc/mkinitramfs/
> in postinst. how should the transition happen?
> could we coordinate an base-installer upload with newer
> initramfs-tools 0.61?
base-installer can be modified to write to /etc/initramfs-tools if the
directory exists and fall back to the old /etc/mkinitramfs/modules
otherwise. Here's the patch that should do that (untested):
Index: debian/postinst
===
--- debian/postinst (revision 37577)
+++ debian/postinst (working copy)
@@ -541,7 +541,12 @@
}
addmodule_initramfs_tools () {
- CFILE='/target/etc/mkinitramfs/modules'
+ if [ -d /target/etc/initramfs-tools ]; then
+ CFILE='/target/etc/initramfs-tools/modules'
+ else
+ # old location
+ CFILE='/target/etc/mkinitramfs/modules'
+ fi
addmodule_easy "$1" "$2"
}
@@ -637,24 +642,8 @@
package="$generators"
fi
fi
- case "$package" in
- initramfs-tools)
- ramdiskconf=/target/etc/mkinitramfs/initramfs.conf
- ;;
- yaird)
- ramdiskconf=
- ;;
- "")
- : # Allow to fall back to initrd-tools for Sarge
installations
- ;;
- *)
- db_subst base-installer/initramfs/unsupported GENERATOR
"$package"
- exit_error base-installer/initramfs/unsupported
- ;;
- esac
else
package=initrd-tools
- ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf
fi
# Sarge does not have any initramfs generators, though custom images may
@@ -663,7 +652,6 @@
info "$package not available; falling back to
initrd-tools."
do_initramfs=no
package=initrd-tools
- ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf
else
# We can only get here if $do_initramfs=yes
exit_error base-installer/initramfs/no-generator
@@ -681,6 +669,28 @@
db_subst base-installer/kernel/failed-package-install
PACKAGE "$package"
exit_error base-installer/kernel/failed-package-install
fi
+
+ # Figure out how to configure the ramdisk creation tool.
+ case "$package" in
+ initramfs-tools)
+ ramdiskconf=/target/etc/mkinitramfs/initramfs.conf
+ ;;
+ yaird)
+ ramdiskconf=
+ ;;
+ initrd-tools)
+ if [ -d /target/etc/initramfs-tools ]; then
+
ramdiskconf=/target/etc/initramfs-tools/mkinitrd.conf
+ else
+ # old location
+ ramdiskconf=/target/etc/mkinitrd/mkinitrd.conf
+ fi
+ ;;
+ *)
+ db_subst base-installer/initramfs/unsupported GENERATOR
"$package"
+ exit_error base-installer/initramfs/unsupported
+ ;;
+ esac
# Add modules that have been queued for inclusion in the initrd
FIRSTMODULE=1
@@ -753,7 +763,7 @@
# Advance progress bar to 90% of allocated space for install_linux
update_progress 90 100
- # /proc/filesystems will accomodate this past the second bootup.
+ # /proc/filesystems will accomodate this when the initrd is rebuilt.
if [ "$do_initrd" = yes ] && [ "$do_initramfs" = no ]; then
sed -e 's/^ROOT=.*/ROOT=probe/' $ramdiskconf > $ramdiskconf.new
&&
mv $ramdiskconf.new $ramdiskconf
Index: debian/changelog
===
--- debian/changelog(revision 37577)
+++ debian/changelog(working copy)
@@ -1,8 +1,11 @@
base-installer (1.58) UNRELEASED; urgency=low
- * Remove some unncessary debug logging.
+ * Remove some unncessary debug logging.
+ * Support initramfs-tools renaming its confdir by testing which directory
+exists. Required moving some code around so it runs only after
+initramfs-tools is installed.
- -- Joey Hess <[EMAIL PROTECTED]> Wed, 24 May 2006 15:31:37 -0400
+ -- Joey Hess <[EMAIL PROTECTED]> Wed, 24 May 2006 15:38:33 -0400
base-installer (1.57) unstable; urgency=low
--
see shy jo
unsubscribe
-- Joao Emanuel Mensageiros MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] (se quiser me em envie o seu endereço do seu mensageiro para incluir) Contador counter.li.org: 398782
WPA / ipw2200 / kernel 2.6.16
Hi,
as maintainer of NetworkManager [1] and provided that we ship etch with
kernel 2.6.16 I'd like to see the attached patch applied to the Debian
kernel. The changes are rather simple and already contained in 2.6.17,
it makes the ipw2200 driver correctly announce its wext-v18
capabilities. This is important for NetworkManager, otherwise it refuses
to offer WPA connections, resulting in troubles for our users [2].
What are the plans for etch (2.6.16 or 2.6.17) and if 2.6.16, would you
consider to include the patch?
Cheers,
Michael
[1] http://packages.debian.org/unstable/net/network-manager
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368694
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
--- drivers/net/wireless/ipw2200.c.orig 2006-05-23 16:05:58.0 +0200
+++ drivers/net/wireless/ipw2200.c 2006-05-24 16:29:25.0 +0200
@@ -8387,7 +8387,7 @@
/* Set the Wireless Extension versions */
range->we_version_compiled = WIRELESS_EXT;
- range->we_version_source = 16;
+ range->we_version_source = 18;
i = 0;
if (priv->ieee->mode & (IEEE_B | IEEE_G)) {
@@ -8419,6 +8419,11 @@
IW_EVENT_CAPA_MASK(SIOCGIWAP));
range->event_capa[1] = IW_EVENT_CAPA_K_1;
+#if WIRELESS_EXT > 17
+ range->enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 |
+ IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP;
+#endif /* WIRELESS_EXT > 17 */
+
IPW_DEBUG_WX("GET Range\n");
return 0;
}
signature.asc
Description: OpenPGP digital signature
Re: WPA / ipw2200 / kernel 2.6.16
Michael Biebl wrote: > Hi, > > as maintainer of NetworkManager [1] and provided that we ship etch with > kernel 2.6.16 I'd like to see the attached patch applied to the Debian > kernel. The changes are rather simple and already contained in 2.6.17, > it makes the ipw2200 driver correctly announce its wext-v18 > capabilities. This is important for NetworkManager, otherwise it refuses > to offer WPA connections, resulting in troubles for our users [2]. > > What are the plans for etch (2.6.16 or 2.6.17) and if 2.6.16, would you > consider to include the patch? > Oh, forgot to add: Please CC me on replies as I'm not subscribed to debian-kernel. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#368788: system hangs at boot while "Restoring mixer settings: "
Package: kernel Version: kernel-image-2.6-686 i have installed debian sarge 3.1r0a with kernel 2.6 i686 default sometimes, when booting, debian hangs while displaying the line "Restoring mixer settings: " which belongs to aumix. i think it's a problem with the modules of the sound cards, not with aumix 2.8-15. i have two soundcards: below is the output of lspci and lspci -n :00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) :00:01.0 PCI bridge: Intel Corp. 82815 815 Chipset AGP Bridge (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) :00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) :00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) :00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) :00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02) :01:01.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) :01:04.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) :02:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82) :00:00.0 0600: 8086:1130 (rev 02) :00:01.0 0604: 8086:1131 (rev 02) :00:1e.0 0604: 8086:2418 (rev 02) :00:1f.0 0601: 8086:2410 (rev 02) :00:1f.1 0101: 8086:2411 (rev 02) :00:1f.2 0c03: 8086:2412 (rev 02) :00:1f.3 0c05: 8086:2413 (rev 02) :00:1f.5 0401: 8086:2415 (rev 02) :01:01.0 0401: 13f6:0111 (rev 10) :01:04.0 0200: 10b7:9200 (rev 78) :02:00.0 0300: 102b:0525 (rev 82) -- ___ Get your free email from http://www.keromail.com
Bug#349354: initramfs-tools - kernel -udev dependency loop
On Wed, 24 May 2006, Marco d'Itri wrote: > On May 15, Marco d'Itri <[EMAIL PROTECTED]> wrote: > > > These packages are not actually needed by udev, and again they may be > > unpacked in the wrong order. Next? i know that these packages are not needed by udev itself, they are going to be installed on an upgrade to a new linux-image > I am still waiting for your proposals. udev disables itself for 2.4 kernels, why can't it do that for 2.6.8? otherwise stick that super special config in one of the package you depend on aka initscripts or makedev or lsb-base.. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SMP PReP (was Re: The powerpc port should be removed from etch release candidates ...)
On Sun, May 21, 2006 at 05:00:15PM +0200, Sven Luther wrote: > On Fri, May 19, 2006 at 07:09:08PM -0700, Daniel Gimpelevich wrote: > > On Thu, 04 May 2006 23:41:28 +0200, Sven Luther wrote: > > > > > On Thu, May 04, 2006 at 10:52:49AM -0500, Olof Johansson wrote: > > >> On Thu, May 04, 2006 at 12:12:56PM +0200, Gabriel Paubert wrote: > > >> > On Thu, May 04, 2006 at 08:41:34AM +0200, Sven Luther wrote: > > >> > > On Thu, May 04, 2006 at 04:38:07PM +1000, Benjamin Herrenschmidt > > >> > > wrote: > > >> > > > > > >> > > > > Hey, cool. so ARCH=ppc will work both for apus and prep, and the > > >> > > > > rest should > > >> > > > > go with ARCH=powerpc. This is the case both for 2.6.16 and the > > >> > > > > upcoming > > >> > > > > 2.6.17, right ? > > >> > > > > > >> > > > I don't remember when he fixed it precisely but I think 2.6.16 got > > >> > > > it > > >> > > > yes. > > >> > > > > >> > > Do you know if there are SMP PReP machines around ? I think i will > > >> > > do only a > > >> > > UP -prep flavour. > > >> > > > >> > There were at least dual 604 PreP boards. > > >> > > >> The IBM 7043-240 is a dual-cpu system, I think it's PReP? > > > > > > Thanks for the info. > > > > > > Friendly, > > > > > > Sven Luther > > > > SMP never worked under Linux on those machines because the AIX boot > > sequence to enable it was never successfully reverse-engineered. > > Ah, ok, then it makes no sense to build a special kernel for those, until more > information is found about the above. I have a Motorola MTX PreP system with dual 604e's that I can test this on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SMP PReP (was Re: The powerpc port should be removed from etch release candidates ...)
On Thu, May 25, 2006 at 09:50:57AM +0200, Sven Luther wrote: > On Wed, May 24, 2006 at 11:14:33PM -0500, Troy Benjegerdes wrote: > > > > SMP never worked under Linux on those machines because the AIX boot > > > > sequence to enable it was never successfully reverse-engineered. > > > > > > Ah, ok, then it makes no sense to build a special kernel for those, until > > > more > > > information is found about the above. > > > > I have a Motorola MTX PreP system with dual 604e's that I can test this > > on. > > But you never managed to get SMP working on it, right ? SMP works but I was having problems where it would crash after 3 or 4 months of uptime in the software raid1 code. This was with 2.4 kernels though.. I have not tried a recent 2.6 kernel yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366507: Confirming with different chipset
I've recently acquired an IBM Thinkpad Dock II, which contains a different version of the Texas Instruments CardBus bridge to the one built into my laptop. These are the internal cardbus chips: :00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03) :00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03) These are the ones in the Dock: :08:02.0 CardBus bridge: Texas Instruments PCI1420 :08:02.1 CardBus bridge: Texas Instruments PCI1420 Everything works fine undocked. When docked, however, the yenta_socket produces an error (and traceback) similar to the original report, disabling the IRQ associated with one of the chips *internal* to the laptop. Even after the "nobody cared" I can use the cardbus slots not attached to that interrupt line. Similarly, 2.4.27 works fine with this arrangement. This is 2.6.15-1-686, but this happens also with 2.6.14, 2.6.16 and 2.6.17-rc3. I have also tried "iopoll" and the pwr_irqs_off option to the yenta_socket module. dmesg: Yenta: CardBus bridge found at :00:02.0 [1014:0130] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:02.0, mfunc 0x1000, devctl 0x66 Yenta: ISA IRQ mask 0x0018, PCI irq 5 Socket status: 3006 ACPI: PCI Interrupt :00:02.1[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ 9 Yenta: CardBus bridge found at :00:02.1 [1014:0130] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :00:02.1, mfunc 0x1000, devctl 0x66 Yenta: ISA IRQ mask 0x0018, PCI irq 9 Socket status: 3006 cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0xa00-0xaff: clean. ACPI: PCI Interrupt :08:02.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 Yenta: CardBus bridge found at :08:02.0 [1014:0148] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :08:02.0, mfunc 0x1002, devctl 0x66 irq 5: nobody cared (try booting with the "irqpoll" option) [] __report_bad_irq+0x31/0x73 [] note_interrupt+0x75/0x99 [] __do_IRQ+0x65/0x91 [] do_IRQ+0x1d/0x28 [] common_interrupt+0x1a/0x20 [] handle_IRQ_event+0x15/0x4c [] __do_IRQ+0x53/0x91 [] do_IRQ+0x1d/0x28 [] common_interrupt+0x1a/0x20 [] yenta_probe_cb_irq+0x85/0xd1 [yenta_socket] [] ti12xx_irqroute_func0+0x61/0x26f [yenta_socket] [] ti12xx_override+0xdb/0xfb [yenta_socket] [] yenta_probe+0x170/0x262 [yenta_socket] [] __pci_device_probe+0x32/0x41 [] pci_device_probe+0x1f/0x34 [] driver_probe_device+0x32/0x7c [] __driver_attach+0x0/0x36 [] __driver_attach+0x24/0x36 [] bus_for_each_dev+0x46/0x6c [] driver_attach+0x14/0x18 [] __driver_attach+0x0/0x36 [] bus_add_driver+0x54/0x96 [] __pci_register_driver+0x75/0x88 [] yenta_socket_init+0xf/0x12 [yenta_socket] [] sys_init_module+0xa5/0x164 [] sysenter_past_esp+0x54/0x75 handlers: [] (snd_cs46xx_interrupt+0x0/0x149 [snd_cs46xx]) [] (yenta_interrupt+0x0/0xb6 [yenta_socket]) Disabling IRQ #5 Yenta: ISA IRQ mask 0x0018, PCI irq 10 Socket status: 3006 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0x3800 - 0x3bff pcmcia: parent PCI bridge Memory window: 0x3c00 - 0x3fff cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0xa00-0xaff: clean. ACPI: PCI Interrupt :08:02.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10 Yenta: CardBus bridge found at :08:02.1 [1014:0148] Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket :08:02.1, mfunc 0x1002, devctl 0x66 Yenta: ISA IRQ mask 0x0018, PCI irq 10 Socket status: 3006 pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff cs: IO port probe 0x3000-0x3fff: clean. pcmcia: parent PCI bridge Memory window: 0x3800 - 0x3bff pcmcia: parent PCI bridge Memory window: 0x3c00 - 0x3fff cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7 cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0xa00-0xaff: clean. lspci -vv output: :00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- :00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping
Bug#368912: linux-2.6: missing debian/copyright information for Xen
Package: linux-2.6 Severity: important debian/copyright currently only lists the copyright, license and upstream URL for Linux proper. Given that Xen is now part of the package, its license (a BSD variant, which is GPL-compatible, but still), copyright and upstream URL (whatever that is) should also be included; at the very least the COPYING file from upstream should be included in the *-xen-* packages. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.11 Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SMP PReP (was Re: The powerpc port should be removed from etch release candidates ...)
On May 24, 2006, at 9:14 PM, Troy Benjegerdes wrote: On Sun, May 21, 2006 at 05:00:15PM +0200, Sven Luther wrote: On Fri, May 19, 2006 at 07:09:08PM -0700, Daniel Gimpelevich wrote: On Thu, 04 May 2006 23:41:28 +0200, Sven Luther wrote: On Thu, May 04, 2006 at 10:52:49AM -0500, Olof Johansson wrote: On Thu, May 04, 2006 at 12:12:56PM +0200, Gabriel Paubert wrote: On Thu, May 04, 2006 at 08:41:34AM +0200, Sven Luther wrote: On Thu, May 04, 2006 at 04:38:07PM +1000, Benjamin Herrenschmidt wrote: Hey, cool. so ARCH=ppc will work both for apus and prep, and the rest should go with ARCH=powerpc. This is the case both for 2.6.16 and the upcoming 2.6.17, right ? I don't remember when he fixed it precisely but I think 2.6.16 got it yes. Do you know if there are SMP PReP machines around ? I think i will do only a UP -prep flavour. There were at least dual 604 PreP boards. The IBM 7043-240 is a dual-cpu system, I think it's PReP? Thanks for the info. Friendly, Sven Luther SMP never worked under Linux on those machines because the AIX boot sequence to enable it was never successfully reverse-engineered. Ah, ok, then it makes no sense to build a special kernel for those, until more information is found about the above. I have a Motorola MTX PreP system with dual 604e's that I can test this on. I was referring to the IBM 7043. No idea how it applies to the MTX. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.4.27-2-586tsc wireless trouble
A recent Etch netinstall on a Compaq Armada 73xx leaves me with no working wireless. Something seems to be wrong with the modules. Help? --- etch-7300a:~# modprobe orinoco /lib/modules/2.4.27-2-586tsc/kernel/drivers/net/wireless/orinoco.o: /lib/modules/2.4.27-2-586tsc/kernel/drivers/net/wireless/orinoco.o: unresolved symbol ALIGN /lib/modules/2.4.27-2-586tsc/kernel/drivers/net/wireless/orinoco.o: insmod /lib/modules/2.4.27-2-586tsc/kernel/drivers/net/wireless/orinoco.o failed /lib/modules/2.4.27-2-586tsc/kernel/drivers/net/wireless/orinoco.o: insmod orinoco failed --- -- Willie, ONWARD! Through the fog! http://counter.li.org Linux registered user #228836 since 1995 Debian3.0/GNU/Linux system uptime 67 days 12 hours 30 minutes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349354: initramfs-tools - kernel -udev dependency loop
On May 25, maximilian attems <[EMAIL PROTECTED]> wrote: > > > These packages are not actually needed by udev, and again they may be > > > unpacked in the wrong order. Next? > i know that these packages are not needed by udev itself, > they are going to be installed on an upgrade to a new linux-image So what? udev still needs to check that they have been installed before it can continue. > udev disables itself for 2.4 kernels, why can't it do that for 2.6.8? It does, but people do not expect that an udev upgrade will disable it, and they are right. > otherwise stick that super special config in one of the package you depend > on aka initscripts or makedev or lsb-base.. I do not know what you are writing about. -- ciao, Marco signature.asc Description: Digital signature
Status of non-free firmware
Hi, at least I forgot what the current status is. For this reason, I'm asking where we are. Please don't take that as I trying to push you or something, but rather as a "please do cluebat me". :) And, I would be interested (if there exists or is not too much effort to create) in a list where blobs is marked as "essential" if some boards don't run/have cd/hard disk/network without, and where it's marked whether the firmware runs on the host CPU or somewhere else. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of non-free firmware
On Thu, May 25, 2006 at 03:51:02PM +0200, Andreas Barth wrote: > Hi, > > at least I forgot what the current status is. For this reason, I'm > asking where we are. Please don't take that as I trying to push you or > something, but rather as a "please do cluebat me". :) Current decision seem to re-add those firmwares whose licencing does not prohibit their licence again in main. There is a linux-non-free-modules or something such package, which build those modules in non-free, and which Bastian would be best placed to answer. There seem to be some progress on the d-i front to be able to load those non-free firmware from a second anna source, but this is not being used yet. > And, I would be interested (if there exists or is not too much effort to > create) in a list where blobs is marked as "essential" if some boards > don't run/have cd/hard disk/network without, and where it's marked > whether the firmware runs on the host CPU or somewhere else. What has this to do with anything ? none of those firmware run on the host CPU, but on the embedded arm or mips or whatever core embedded in the device. We have to face it, most modern computers with advanced I/O cards are actually non-symetric multi-processor machines, with the main processor doing the common task, and some specialized I/O processors doing I/O tasks. So, altough the firmware in question being non-free doesn't disrupt the kernel's GPL, it is still code without source and as thus non-free. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
