Re: Installer Profiles
Windowmaker! 2¢ Yeah. I also think there should be the choice (I use KDE). likes. (Most of the people will choose Gnome or KDE, I think). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] mass kernel udeb update and preparations for RC1
(Reply-to set to debian-boot; please only add relevant port if needed.) /me wonders why there have been almost no reactions to this mail The first part is mostly information (though a cool or thanks would be appreciated), but the second part has some issues that need attention. Have D-I porters actually read the mail? Is it useful that I send such mails at all? On Sunday 17 September 2006 14:28, Frans Pop wrote: Dear (d-i) porters, First mass upload of kernel udebs = Today I have uploaded kernel udeb updates to 2.6.17-9 _for all arches_. This is the first time using the 'massbuild' [1] script I wrote recently. Effectively this means that d-i porters won't really have to worry anymore about updating kernel udebs after uploads by the kernel team. Only if the kernel major/minor changes will I request porters to do the upload themselves. For stable releases (including ABI changes) I intend to do these mass builds and do the uploads myself. Hopefully this will help the speed with which kernel udebs are updated and allow you all to spend more time testing d-i ;-) Of course porters are still responsible for maintaining which modules will be included for each arch/flavor. If you have changes between kernel major/minor releases you can either commit them and upload, or commit them as UNRELEASED and they will be automatically included in the next mass build. The massbuild script can be used for single-arch builds too. Its main advantage is that kernel images don't need to be installed and the certainty that the correct kernel version will be used. Feel free to contact me to help you get started. Some comments on today's upload: - I have used the last released version of kernel-wedge and will normally do that in the future too - I have not really checked or tested the udebs [2], so there could be some surprises; please be alert for them - m68k: I had to update the dependencies from kernel-image to linux-image The road to RC1 === We are slowly moving towards RC1. I plan to post an initial planning later this week. As we get closer to Etch, testing the installer for all arches gets to be more important. Any time you can spend on that is very much appreciated. There are some issues that need attention: * type of initrd used Some arches have already switched to using initramfs for d-i initrds, other arches are still using cramfs or ext2. Please check if a change could/should be made for your architecture. * 2.4 support now officially dropped Starting with RC1 d-i will no longer support 2.4 based installations. All arches have been switched now and some cleanup has been started; more cleanup is expected and this may cause unexpected breakage. * support for non-devfs device names Colin Watson has committed a series of changes to make d-i support non-devfs device names. We will be slowly moving away from using devfs names, but the most intrusive work will be postponed until after Etch. Please check for unexpected breakage though. * partman-auto using LVM and crypto partman-auto-lvm now has been available for some time, but is still not available for all arches. LVM support is a prerequisite for partman-auto-crypto support which will be uploaded soon. Note: swap on LVM should be possible now and is even required for partman-auto-crypto. If you would like to add support for it, please see [3]. Feel free to contact me or David Härdeman (Alphix) for help. * mips: keyboard issues We've had a report about a dead keyboard on installation (#382983). This needs to be investigated. * powerpc: oldworld boot problems with recent kernels If there are other architecture specific issues that we should be aware of, please let me know. Cheers, FJP [1] http://svn.debian.org/wsvn/d-i/people/fjp/massbuild?op=filerev=0sc=0 [2] The script does have a number of sanity checks though. [3] http://lists.debian.org/debian-boot/2006/01/msg01054.html pgppzIdIeFXKd.pgp Description: PGP signature
Re: One more time, openoffice :)
Rafael Rodríguez wrote: Hi, there are experimental ubuntu amd64-native packages for OpenOffice according to [1]. Apart from that, a couple of days ago non-official packages (re-built from the debian unstable sources) were posted in this list, but I haven't had the time to test them quite a lot. In fact, I have a bug: the first time I start OpenOffice, it crashes, but the second time it works... ?¿ By now, you do not need to modify anymore the debian/rules file. The amd64 architecture is compiling fine automatically and produce all the needed packages. But the software is still quite unstable and need to be tested and debugged. Anyway, anyone knows the state of the former and the latter, or the plans? Rene, are you alive? ;) I guess now it's building fine and we need to fix all these pointers problems (last time I ran it I was hitting a double free problem). Just to recall the process to compile it: First of all, few links about OpenOffice: http://www.openoffice.org/ http://wiki.services.openoffice.org/wiki/Porting_to_x86-64_(AMD64,_EM64T) http://openoffice.debian.net/ http://packages.qa.debian.org/o/openoffice.org.html Preparing to compile (to be done once): 1) Add the following line to your /etc/apt/sources.list: deb-src ftp://ftp.debian.org/debian/ experimental main contrib 2) Update: su -c 'apt-get update' 3) Get the packages needed to compile openoffice.org: su -c 'apt-get build-dep -t experimental openoffice.org' Note: The package boost-build is needed but might not be in the list of the build-dep (install it by hand if needed) Once you got all these done, we can get the source and compile it: 1) Get the source from the experimental Debian repository (getting the sources from the experimental makes it sure to track bugs on the very last version): apt-get source -t experimental openoffice.org 2) Move to the build directory: cd openoffice-* 3) Build the package (this might take quite a while): dpkg-buildpackage -rfakeroot -us -uc Regards -- Emmanuel Fleury | Office: 261 Associate Professor, | Phone: +33 (0)5 40 00 69 34 LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69 351, Cours de la Libération | email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fglrx 8.29.6 and Xorg 7.1.1 :: ABI major version mismatch
On Thu, Sep 21, 2006 at 03:10:14PM -0700, Max A. wrote: fglrx 8.29.6 claims to support Xorg 7.1 http://www2.ati.com/drivers/linux/linux_8.29.6.html But I cannot get it work because of the following error: (II) LoadModule: fglrx (II) Loading /usr/lib/xorg/modules/drivers/fglrx_drv.so (II) Module fglrx: vendor=FireGL - ATI Technologies Inc. compiled for 6.8.99.8, module version = 8.29.6 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 0.7 (EE) module ABI major version (0) doesn't match the server's version (1) (II) UnloadModule: fglrx (II) Unloading /usr/lib/xorg/modules/drivers/fglrx_drv.so (EE) Failed to load module fglrx (module requirement mismatch, 0) Does anybody know how to fix that? They also claim: * Attempting to install the ATI Proprietary Linux driver on distributions that have updated certain 3D components outside of the stock XOrg 6.8.2 may result in the driver not initializing 3D applications properly. Further details can be found in topic number 737-20868 Well it could be a problem here given 7.1 has many updates over the 6.8.2 they compile against. Certianly nvidia made some fixes in their last release to support 7.1. * Loading the XVideo Extension on 64-bit Xorg 6.9+ systems causes the X Server to segfault on launch with ATI Radeon X1K products. Further details and the workaround can be found in topic number 737-22837 This may be a problem given this is 64bit. I don't see anywhere which ATI you are using * Users with X Server X.org 7.1 can not play any video using XV. The ATI AVIVO Video adaptor is not present. Further details and the workaround can be found in topic number 737-22852 I am guessing this isn't the problem. Of course none of those issues really sound like they should give an abi error. Any change you are running with the old kernel module loaded and trying to use the new driver? Which version of the kernel module do you have loaded? A quick google search brought up this: http://www.mail-archive.com/debian-x@lists.debian.org/msg49143.html so perhaps all you need is a newer version of the package in question. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Thu, Sep 21, 2006 at 09:18:50PM -0400, [EMAIL PROTECTED] wrote: I'm building my new computer and am ready to look at boards. I've settled on AMD AM2 socket. I don't do games but would like to transfer videos to DVD and watch DVDs (edit out commercials?) and other home use type stuff. For this, I want a good selection of USB, more than one SATA, firewire, etc. In fact, the n3400B is only short the eSATA to match the features that I would use of the ASIS Crosshair (apparently a gamers' heaven). The Asus boards have always treated me well (although I have only ever bought the higher end models), and anything with an nvidia chipset generally does well with linux. Via can be a bit tricky although it will usually end up working within a few months (2.6.18 added support for the most recent via chipsets), and ati is simply a nightmare with linux. Is esata necesary? Is it supported by linux (I don't think hotplug is implemented for sata yet, although people are working on it). I want a solid reliable board as I usually only get a new computer every 10 years or so. I understand that Tyan boards are very good and generally well supported in Linux. So far I've found the Tomcat n3400B and the h1000s. The Tyan website under 'drivers' has them listed specifically for RHES and SLES. How does this translate to using these boards under Debian? For etch, probably not a problem. For sarge (which is about as old as RHES's last release I suspect) you would probably have driver problems due to the hardware being much newer than the kernel. It really just depends on what components does it use and whether the kernel has drivers for those in the release you decide to use. I've been trying to answer this myself using Google without success. Has anyone used either of these boards? Well I only use Asus boards myself. I have never used a tyan, although they do seem to have a good reputation (and they can run linuxbios apparently). -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fglrx 8.29.6 and Xorg 7.1.1 :: ABI major version mismatch
On 9/22/06, Lennart Sorensen [EMAIL PROTECTED] wrote: Of course none of those issues really sound like they should give an abi error. Any change you are running with the old kernel module loaded and trying to use the new driver? Which version of the kernel module do you have loaded? I did not try older versions of fglrx with Xorg 7.1. Update to Xorg 7.1 in debian/unstable coincided with the release 8.29.6 of fglrx driver from ATI. So I tried them together but with no luck. The kernel module was freshly compiled one from the fglrx 8.29.6 distribution. A quick google search brought up this: http://www.mail-archive.com/debian-x@lists.debian.org/msg49143.html so perhaps all you need is a newer version of the package in question. But that bugreport is about the opensource driver ati not about the proprietary driver fglrx. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Friday 22 September 2006 16:13, Lennart Sorensen wrote: Well I only use Asus boards myself. I have never used a tyan, although they do seem to have a good reputation (and they can run linuxbios apparently). I run debian amd64 etch on tyan S2895 K8WE. Everything fine, in particular a real raid1 (debian software), although I can say little about the X-system, which (although it worked finely) I have no more installed in a new installation. I do not need it. That new installation (kernel 17-2) because the Maxtor HD proved incompatible - probably with nvidia chipsets on the mainboard. One of the disks (not always the same) from time to time halted, although raid1 reconstructed it, so that when restarting the machine nothing wrong could be detected. With WD Raptor in place of Maxtor nothing wrong has happened in about ten days of uninterrupted work (I can say that because halting of one Maxtor had negative impact on calculations with mpqc2.3.1). If anything, I was unhappy with Tyan Europe. Asking them about their raid - which had nothing to do with linux although I mentioned debian linux somewhere - the answer was we do not answer linux questions or about so. My mail to Tyan Taiwan - complaining about that answer by Tyan Europe - remained unanswered. Therefore, do not expect support by Tyan if you use linux. I can not rule out that problems may arise from that Tyan way of doing. I wonder whether Extremadura is going to Tyan at all. I would not if I had to buy a new motherboard (this is no comparison with other motherboards, I am no expert). cheers francesco pietra -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Fri, Sep 22, 2006 at 10:13:32AM -0400, Lennart Sorensen wrote: On Thu, Sep 21, 2006 at 09:18:50PM -0400, [EMAIL PROTECTED] wrote: I'm building my new computer and am ready to look at boards. I've settled on AMD AM2 socket. The Asus boards have always treated me well (although I have only ever bought the higher end models), and anything with an nvidia chipset generally does well with linux. Via can be a bit tricky although it will usually end up working within a few months (2.6.18 added support for the most recent via chipsets), and ati is simply a nightmare with linux. Is esata necesary? Is it supported by linux (I don't think hotplug is implemented for sata yet, although people are working on it). I want a solid reliable board as I usually only get a new computer every 10 years or so. I understand that Tyan boards are very good and generally well supported in Linux. So far I've found the Tomcat n3400B and the h1000s. The Tyan website under 'drivers' has them listed specifically for RHES and SLES. How does this translate to using these boards under Debian? For etch, probably not a problem. For sarge (which is about as old as RHES's last release I suspect) you would probably have driver problems due to the hardware being much newer than the kernel. It really just depends on what components does it use and whether the kernel has drivers for those in the release you decide to use. Well I only use Asus boards myself. I have never used a tyan, although they do seem to have a good reputation (and they can run linuxbios apparently). -- Len Sorensen Thanks Len, I hadn't heard of Tyan (I haven't looked at boards before; the last computer I bought was an IBM 486 in 1993) but it was recommended to me on this forum. Asus seems to cater to the gaming crowd while Tyan seems to cater to the server/workstation crowd and it is this latter which more closely matches my use of a computer. Both the Asus Crosshair (nVidia 590 SLI chipset) and the Tyan Tomcat n3400B have a MSRP about the same at $200. The Tyan gives me video while the Asus would mean I'd have to get a display card as well. eSATA isn't necessary right now, and I could add a card later. Since I only buy a new computer every decade or two, I'm trying to think ahead (as much as is possible with computers). eSATA seems to be the up-and-coming way to connect external storage instead of SCSI (expensive) or USB (slower). My concern here is how to backup in the future, but that's a problem for later. I don't need hotplug. The Tyan also has a serial port. While I can add a USB serial port, I don't think I can use one for a serial console. Depending on how I'm using a computer, I sometimes like to use a serial console and keep messages from showing up on the VCs (if I am still using video). I guess thats a bit old-fashioned of me, but then again, 99% of what I do is text-based (why can't lynx do javascript?). Given the price similarity, I'm assuming at this point that while Asus puts the value in making it stable for overclocking, Tyan puts the value in making it stable for the long-run. Whatever board I go with, it will be mounted in a CoolerMaster stacker with cross-flow fan with drives in the 4-in-3 fan cooled modules. The processor will be the last thing I buy because of all the components in a computer, the processor drops in price fastest. Comments on my assumptions are greatly appreciated. Thanks, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Can't capture sound thru the mic input
Hi. I was using the mic without problems until some days ago when it stopped working. I've checked and tried everything with the mixer, the configuration that always had worked now it doesn't. I have an NForce4 chipset using the intel8x0 alsa driver. I have debian unstable and update almost daily. Anyone else? Do you know what might be happening? Best regards. -- Bernardo Arlandis Mañó -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Fri, Sep 22, 2006 at 01:00:27PM -0400, Lennart Sorensen wrote: On Fri, Sep 22, 2006 at 12:27:38PM -0400, [EMAIL PROTECTED] wrote: Well if you don't need video for anything other than the console and setting up, then onboard video certainly makes sense. Unfortunately it appears you have to get either firewire and audio or on onboard video on the tyan. Not sure why the one with onboard video has no firewire. Of course you may decide it makes more sense to add a seperate firewire card since then you can get 800Mbps firewire, rather than have to add a video card. The tyan also uses the nforce pro chipset, rather than a consumer level chipset. The Tyan Tomcat n3400B (S2925) has both video and 2 firewire (and floppy, ,4 USB, 1 serial, 1 paralell, sound, 2 GB LAN, 6 SATA 3.0, 1 IDE). I'll use the video for most things most of the time and for Xwidown running Mozilla, Xcdroast, and eventually video editing, only having to add a capture card (or USB dongle?). Given the price similarity, I'm assuming at this point that while Asus puts the value in making it stable for overclocking, Tyan puts the value in making it stable for the long-run. Whatever board I go with, it will be mounted in a CoolerMaster stacker with cross-flow fan with drives in the 4-in-3 fan cooled modules. The processor will be the last thing I buy because of all the components in a computer, the processor drops in price fastest. Comments on my assumptions are greatly appreciated. Well I see no problem with either. -- Len Sorensen The Tyan Tomcat n3400B s2925 uses the nVIDIA nForce Pro 3400 chipset (it also mentions SMSC DME 5017, but I don't recognize that). Is there any reason to think that it wouldn't work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsibscribe
Re: Can't capture sound thru the mic input
Bernardo Arlandis Mañó escribió: Hi. I was using the mic without problems until some days ago when it stopped working. I've checked and tried everything with the mixer, the configuration that always had worked now it doesn't. I have an NForce4 chipset using the intel8x0 alsa driver. I have debian unstable and update almost daily. Anyone else? Do you know what might be happening? Best regards. I just found that setting Mic Select to Mic 2 and enabling Capture recording now it works. Something must have changed so that I had to touch these settings I've never have even seen before. Any info somewhere about the mixer settings and especially about Capture? I hope it helps anybody. -- Bernardo Arlandis Mañó -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Fri, Sep 22, 2006 at 02:16:52PM -0400, [EMAIL PROTECTED] wrote: The Tyan Tomcat n3400B (S2925) has both video and 2 firewire (and floppy, ,4 USB, 1 serial, 1 paralell, sound, 2 GB LAN, 6 SATA 3.0, 1 IDE). I'll use the video for most things most of the time and for Xwidown running Mozilla, Xcdroast, and eventually video editing, only having to add a capture card (or USB dongle?). Hmm, looked at the page: http://www.tyan.com/products/html/tomcatn3400b.html I get the impression from the two SKU lines, that you either get firewire and audio, or you get graphics, but that there is no SKU that has both. Maybe the page is wrong and they have more SKUs or I just don't understand what they are trying to say. The Tyan Tomcat n3400B s2925 uses the nVIDIA nForce Pro 3400 chipset (it also mentions SMSC DME 5017, but I don't recognize that). The SMSC is just a super io chip. Those are usually generic (parallel and serial ports are generic on PCs really.) Is there any reason to think that it wouldn't work? The ones I can easily find for sale are: http://www.8anet.com/merchant.ihtml?pid=28lastcatid=5step=4 S2925A2NRF http://www.8anet.com/merchant.ihtml?pid=29lastcatid=5step=4 S2925G2NR As for as I can tell in the product codes, A = audio, G = graphics, N = networking, R = raid, F = firewire. Which ones have you found for sale? -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: One more time, openoffice :)
On Thursday 21 September 2006 17:41, Emmanuel Fleury wrote: Rafael Rodríguez wrote: Hi, there are experimental ubuntu amd64-native packages for OpenOffice according to [1]. Apart from that, a couple of days ago non-official packages (re-built from the debian unstable sources) were posted in this list, but I haven't had the time to test them quite a lot. In fact, I have a bug: the first time I start OpenOffice, it crashes, but the second time it works... ?¿ By now, you do not need to modify anymore the debian/rules file. The amd64 architecture is compiling fine automatically and produce all the needed packages. But the software is still quite unstable and need to be tested and debugged. Anyway, anyone knows the state of the former and the latter, or the plans? Rene, are you alive? ;) I guess now it's building fine and we need to fix all these pointers problems (last time I ran it I was hitting a double free problem). Just to recall the process to compile it: First of all, few links about OpenOffice: http://www.openoffice.org/ http://wiki.services.openoffice.org/wiki/Porting_to_x86-64_(AMD64,_EM64T) http://openoffice.debian.net/ http://packages.qa.debian.org/o/openoffice.org.html Preparing to compile (to be done once): 1) Add the following line to your /etc/apt/sources.list: deb-src ftp://ftp.debian.org/debian/ experimental main contrib 2) Update: su -c 'apt-get update' 3) Get the packages needed to compile openoffice.org: su -c 'apt-get build-dep -t experimental openoffice.org' Note: The package boost-build is needed but might not be in the list of the build-dep (install it by hand if needed) At this point i get: c64:~# apt-get install -t experimental boost-build Reading package lists... Done Building dependency tree... Done boost-build is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded. c64:~# apt-get build-dep -t experimental openoffice.org Reading package lists... Done Building dependency tree... Done E: Build-dependencies for openoffice.org could not be satisfied. Any ideas? Mzzl Henk Once you got all these done, we can get the source and compile it: 1) Get the source from the experimental Debian repository (getting the sources from the experimental makes it sure to track bugs on the very last version): apt-get source -t experimental openoffice.org 2) Move to the build directory: cd openoffice-* 3) Build the package (this might take quite a while): dpkg-buildpackage -rfakeroot -us -uc Regards -- Emmanuel Fleury | Office: 261 Associate Professor, | Phone: +33 (0)5 40 00 69 34 LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69 351, Cours de la Libération | email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury
Re: tyan board
I received this from the Tyan automated tech support mail system. They say that the nVidia nForce chipset isn't supported in Debian. Does anybody know from the Debian perspective if this is true? What OS's are currently supported by the nVidia nForce Chipset? Here is a listing of the OS's that will/won't and will be supported for these motherboard: Yes: Workstation and Advanced Server RHEL3 Update 4 (No update 1, 2 or 3) Workstation and Advanced Server RHEL4 SuSE 9.1, 9.2 and 9.3 (64-bt) No: No RedHat 32-bit Distributions No SuSE 32-bit Distributions No Debian, Gentuu, Fedora Core or Turbo Linux No FreeBSD I take it that this refers to current Debian 3.1. Since 4.0 isn't released yet but will include an AMD64 specific version, will it then work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cfs reports Input/Output error
Hi, I'm using cfs on an amd64 (sid). The Cryptographic File System (cfs) deb package used to work fine. Haven't used it for a while on amd64 (only on i386) and now... it doesn't work. I can manage to mount the encrypted directory by doing: $ cfssh directory The problem is when I try to see what's inside the directory: $ ls ls: reading directory .: Input/output error $ echo * * My guess is that this is a problem with the way things are mounted, not ls. I've tried to do an strace on this, but didn't get anything. Any ideas on how to fix this. Cheers, Sergio. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tyan board
On Fri, Sep 22, 2006 at 04:32:30PM -0400, [EMAIL PROTECTED] wrote: I received this from the Tyan automated tech support mail system. They say that the nVidia nForce chipset isn't supported in Debian. Does anybody know from the Debian perspective if this is true? In sarge that is probably true. In etch it almost certainly isn't. Support depends on the kernel version, not the distribution. The nforce pro 3400 is as far as I can tell a modification of the MCP51/MCP55 series chipset, which I believe is what the 570/590 is. So it is basicly an nforce 5 series chipset with some server oriented specs. The nforce2 works with sarge (I have multiple machines with it), the nforce 3 works with sarge (my wife's laptop has that chipset), and the nforce 4 might work with sarge, but might not work perfectly. A newer 2.6 kernel works fine with it. The nforce pro 3400 chipset in this case. Of course this does appear to be one amazingly new chipset, and hence may not be fully supported yet, although if they claim RHEL can boot on it, I expect anything with a recent kernel should too. Drivers for any fake raid or other such device on the other hand may be harder to get. As for what actually supports that board, I can't really find anything, since it appears to be much too new for anyone to actually have one yet. I take it that this refers to current Debian 3.1. Since 4.0 isn't released yet but will include an AMD64 specific version, will it then work? I would think so. Just because they won't support it, doesn't mean it won't work. Redhat and Suse don't get to have their own kernels with special drivers other people don't get (unless they add binary only drivers seperately for some things). Dell also doesn't support Debian, but lots of people use it anyhow. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] mass kernel udeb update and preparations for RC1
On Fri, Sep 22, 2006 at 02:31:43PM +0200, Frans Pop wrote: (Reply-to set to debian-boot; please only add relevant port if needed.) /me wonders why there have been almost no reactions to this mail The first part is mostly information (though a cool or thanks would be appreciated), but the second part has some issues that need attention. Have D-I porters actually read the mail? Is it useful that I send such mails at all? I was happy to hear about it. About the only reponse I have is thanks! :) Stephen (for m68k) On Sunday 17 September 2006 14:28, Frans Pop wrote: Dear (d-i) porters, First mass upload of kernel udebs = Today I have uploaded kernel udeb updates to 2.6.17-9 _for all arches_. This is the first time using the 'massbuild' [1] script I wrote recently. Effectively this means that d-i porters won't really have to worry anymore about updating kernel udebs after uploads by the kernel team. Only if the kernel major/minor changes will I request porters to do the upload themselves. For stable releases (including ABI changes) I intend to do these mass builds and do the uploads myself. Hopefully this will help the speed with which kernel udebs are updated and allow you all to spend more time testing d-i ;-) Of course porters are still responsible for maintaining which modules will be included for each arch/flavor. If you have changes between kernel major/minor releases you can either commit them and upload, or commit them as UNRELEASED and they will be automatically included in the next mass build. The massbuild script can be used for single-arch builds too. Its main advantage is that kernel images don't need to be installed and the certainty that the correct kernel version will be used. Feel free to contact me to help you get started. Some comments on today's upload: - I have used the last released version of kernel-wedge and will normally do that in the future too - I have not really checked or tested the udebs [2], so there could be some surprises; please be alert for them - m68k: I had to update the dependencies from kernel-image to linux-image The road to RC1 === We are slowly moving towards RC1. I plan to post an initial planning later this week. As we get closer to Etch, testing the installer for all arches gets to be more important. Any time you can spend on that is very much appreciated. There are some issues that need attention: * type of initrd used Some arches have already switched to using initramfs for d-i initrds, other arches are still using cramfs or ext2. Please check if a change could/should be made for your architecture. * 2.4 support now officially dropped Starting with RC1 d-i will no longer support 2.4 based installations. All arches have been switched now and some cleanup has been started; more cleanup is expected and this may cause unexpected breakage. * support for non-devfs device names Colin Watson has committed a series of changes to make d-i support non-devfs device names. We will be slowly moving away from using devfs names, but the most intrusive work will be postponed until after Etch. Please check for unexpected breakage though. * partman-auto using LVM and crypto partman-auto-lvm now has been available for some time, but is still not available for all arches. LVM support is a prerequisite for partman-auto-crypto support which will be uploaded soon. Note: swap on LVM should be possible now and is even required for partman-auto-crypto. If you would like to add support for it, please see [3]. Feel free to contact me or David Härdeman (Alphix) for help. * mips: keyboard issues We've had a report about a dead keyboard on installation (#382983). This needs to be investigated. * powerpc: oldworld boot problems with recent kernels If there are other architecture specific issues that we should be aware of, please let me know. Cheers, FJP [1] http://svn.debian.org/wsvn/d-i/people/fjp/massbuild?op=filerev=0sc=0 [2] The script does have a number of sanity checks though. [3] http://lists.debian.org/debian-boot/2006/01/msg01054.html -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: tyan board
Sorry Len, I sent it directly to you instead of the list by accident. (I know, no excuse for hitting the wrong key in mutt). On Fri, Sep 22, 2006 at 05:56:23PM -0400, Lennart Sorensen wrote: Support depends on the kernel version, not the distribution. The nforce pro 3400 is as far as I can tell a modification of the MCP51/MCP55 series chipset, which I believe is what the 570/590 is. So it is basicly an nforce 5 series chipset with some server oriented specs. I expect anything with a recent kernel should too. Drivers for any fake raid or other such device on the other hand may be harder to get. Any raid I would do would probably be Linux kernel as I understand that its faster than most hardware-based. I'm not really interested in raid anyway; more interested in learning about logical volume management. As for what actually supports that board, I can't really find anything, since it appears to be much too new for anyone to actually have one yet. I've never tried to use a testing-level system. Once I get my CD-burner working on my 486, I'll try to get the current Debian testing CD. Thanks, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
