redhat-cluster: strange build failure, please check chroot
Hi! http://buildd.debian.org/fetch.cgi?pkg=redhat-clusterver=2.20080801-2arch=powerpcstamp=1220111899file=log redhat-cluster fails only on powerpc, with a funny dhshlibs error: dh_shlibdeps -a -l/build/buildd/redhat-cluster-2.20080801/debian/tmp/usr/lib dpkg-shlibdeps: failure: couldn't find library libcpg.so.2 needed by debian/cman/usr/sbin/gfs_controld (its RPATH is ''). Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. dh_shlibdeps: command returned error code 512 libcpg.so.2 is in the package libopenais2, which is installed, otherwhise the build would already have failed while linking some binaries. I do not know what to do about this, other than asking you to check the chroot, ans see what is wrong. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#494308: binary firmware in drivers/net/e100.c
Hi, I already waited for this. On Fri, Aug 08, 2008 at 12:21:45PM +, Robert Millan wrote: drivers/net/e100.c (licensed under GPLv2) contains three chunks of binary firmware, such as: [...] You don't expect us to remove the e100 driver, do you? signature.asc Description: Digital signature
Re: binary firmware (Re: Processed: tagging 493925, tagging 494007, tagging 494009, tagging 494010)
Hi, Mine is that it should be useful to people fully committed to freedom who would rather trash their hardware than run a propietary driver that might depend on hom much you paid for that hardware, and on whether you have the choice to not use it, because there might not be anything comparable not non-free. So my conclussion is that untill we can fix the problems, the compromise that would fall within the letter and spirit of the SC is to provide two versions of the package to our users. One that is 100% free and one that is, at least, legally distributable. 1. We removed all not distributable blobs during the last freeze. 2. The remaining ones are either distributable in main, or in the firmware-nonfree package. If you think one of the remaining firmwares is licensed in a way not acceptable for main, please send in tested patches against the driver in linux-2.6 fixing it to request the firmware from userland, and the needed patch for firmware-nonfree with the corresponding counterpart. Regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: NR_CPUS in debian linux-images
Hi,
from cujrrent intel and amd roadmaps, expect 4-way and 8-way 12 core
boxes during the lenny life cycle.
I think NR_CPUS should really be set to 96, at least.
On Tue, Jul 29, 2008 at 10:25:32AM +0200, maximilian attems wrote:
we came to this issue:
10:13 waldi 1345623 3148364 417112 4911099 4aeffb x86_64-255/vmlinux
10:13 waldi 1339887 380556 273880 1994323 1e6e53 x86_64-32/vmlinux
10:13 waldi only change is the number of cpus *gna*
10:16 waldi struct irq_cfg irq_cfg[NR_IRQS] __read_mostly = {
10:18 waldi yeah, 2.5MiB just for the interrups
10:19 waldi #define NR_IRQS (256 + (32 * NR_CPUS))
10:29 waldi and because some parts have static initializers, it can't be
moved
into the bss section
the debian installer cares about the image size.
What is the actual limit?
Not raising this setting means loosing even more on the enterprise and
HPC terrain.
Best regards
Frederik Schüler
--
ENOSIG
signature.asc
Description: Digital signature
Bug#492173: linux-image-2.6.25-2-486: Dual-core, second core not detected (AMD64x2, running 2.6.25-2-486 kernel)
Hi! On Thu, Jul 24, 2008 at 02:55:45AM -0700, Jack T Mudge III wrote: I am running on an AMD 64 dual-core CPU, and only the first core is detected. For me, this has had a significant impact on performance (the previous kernel, 2.6.24-486, did not have this problem). that is a 32bit kernel for CPUs older than pentium 3, you should really use the amd64 flavour or the amd64 port at all. Best regards Frederik Schüler signature.asc Description: Digital signature
Re: gcc 4.3
Hi! On Tue, Jun 10, 2008 at 09:01:59AM +0200, Bastian Blank wrote: On Mon, Jun 09, 2008 at 11:51:28PM +0200, maximilian attems wrote: planing to switch x86 to it for 2.6.26. compiles, boots and works fine here. NACK. Too late. I'd like to see this for amd64 too, but I guess we are indeed too late. Are we really releasing with .26? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Memory model
Hi! On Sun, Jun 08, 2008 at 12:33:06AM +0200, maximilian attems wrote: afais fedora defaults to x86_64 SPARSEMEM also we had this as default since allmost ever, you'll only find *one* changelog entry by fs for a bootup fixup change. Did the default change to SPARSEMEM some time ago? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#479773: linux-2.6 [etch]: please add 3ware-9690SA support
Package: linux-image-2.6.18-6-amd64 Version: 2.6.18.dfsg.1-18etch3 Severity: whishlist Hello, please add support for the 3ware 9690SA SAS HBA. Found in git: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=0e78d158b67fba3977f577f293c323359d80dd0e;hp=6826ee4fdbe24c7aab56ce833ef94be81d190587 applies cleanly and fixes another issue too. I am preparing a backport, I'll report here if it builds and runs. Best regards Frederik Schüler -- ENOSIG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474960: linux-modules-extra-2.6: please add back iscsitarget module
Package: linux-modules-extra-2.6 Version: 2.6.24-6 Severity: wishlist Hello, can you please add back iscsitarget-module? The .24 FTBFS is fixed. Best regards Frederik Schüler -- ENOSIG
Bug#471398: ccs: /etc/cluster/cluster.conf: file not found (broken on clean install)
fixed 471398 2.20071214-1 thanks Hello, Package: cman Version: 1.03.00-2 you really should use RHCS2, and not these old packages. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#461839: ping
Hi Christian, how is it, do you have something already? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Future of the linux udebs
Hi, On Sat, Feb 16, 2008 at 10:52:17PM -0200, Otavio Salvador wrote: Please read the thread we had about 2.6.24 kernel testing migration... this is what worries me. I don't want to reopen that discussion here, and I see your argument. There are really good reasons to do beta1 with .24, and good reasons for .22 too. In such a case we might need someone to arbitrate, the release managers come to mind. I personally have a good relation with all active people in debian-kernel but I think that we might have a policy to avoid problems to happen. Good will isn't enough, IMO. We should decide case by case, considering what is best to get closer to the release. If adapting the concerned installer components to .24 takes too long and requires developers to focus on other things than stabilizing the code for beta1, we should indeed go with .22 for it, and so we can test 2.6.24 on a stabilized installer in beta2. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Future of the linux udebs
Hello, On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote: Bastian Blank [EMAIL PROTECTED] writes: - Is impossible to release d-i with a different kernel from sid without a lot of hassle - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i development is affected This last item is where I worry a lot. Obviously, kernel team want to put newest kernel on sid however, when he does it, d-i will be forced to change it too. Coordination is already needed now, and will be needed even more when this change is implemented. If this means waiting with a new upstream kernel version for a week or two until the next beta of d-i is done, we will of course wait, no one wants to break d-i development by purpose. For it to work testing images, _before_ the kernel upload to happen, would be required to at least reduce the risk of a kernel upload to stop all d-i development until it gets fixed. We have the kernel-snapshots archive to test new images before uploading them. This infrastructure could be extended, by adding buildds for all missing architectures, and whatever else is needed to get daily d-i snapshots built with these kernels. Another thihk that I see as a _must_ is that d-i team could nack a kernel upload. This is requred since d-i won't be allowed to diverge from sid kernels anymore (I mean during development) and those migrations would need to be much more coordinated with d-i RM and d-i porters. Nobody will insist on uploading a new kernel version if this breaks the release schedule, just think of 2.6.19, which never was uploaded to the archive because we where in the middle of releasing etch. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Beta1 missing decisions and possible timeline
Hi, On Fri, Feb 01, 2008 at 09:51:07PM -0500, Joey Hess wrote: It's far to early to switch d-i to 2.6.24, especially since it drops support for most of /proc/acpi, including the parts used by laptop-detect. I still think this switch was an extremely premature and really, really bad idea. We need either to turn the acpi proc interface back on before .24 migrates to testing, or we track a .24 with this change outside of the archive, which is a no go for me. So, let's reenable CONFIG_ACPI_PROCFS_POWER, please. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Setting ACPI_SYSFS_POWER broke all battery status applets
Hi, the final 2.6.24 upload has ACPI_SYSFS_POWER activated instead of ACPI_PROCFS_POWER, causing all applets using hal (#462723), and those parsing proc directly (/usr/bin/acpi, wmacpi...) to fail reading the battery status. This makes .24 pretty useless on laptops. I suggest we revert this change ASAP (I tend to upload -2 on monday evening UTC), until the concerned packages are fixed to be able to use both interfaces. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#460846: redhat-cluster-suite: Depends on non-existant package clvm
block 460846 453320 thanks Hi, On Tue, Jan 15, 2008 at 10:37:18AM +0100, Aurelien Jarno wrote: redhat-cluster-suite depends on clvm which does not exists anymore in unstable. The lvm2 packages in testing are pretty outdated, as soon as 2.02.29-1 migrated there will be a new upload with clvm enabled. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: 2.6.23 upload to p-u
Hello, On Fri, Jan 11, 2008 at 11:46:11AM -0700, dann frazier wrote: * Go with 2.6.22 for now - its more stable than 2.6.23 and is a known quantity. I could get a branch going and start on any security fixes, and upload sometime soon, perhaps Wednesday? OK * Encourage users to test 2.6.24 rc releases - maks wants to make rcs available in experimental, and try for a quick upload to sid once upstream releases. Yes, we should aim at .24. * 4.0r3 is intended to happen in February, and mainly to fix issues with 4.0r2 - 4.0r4 would be the next candidate for etchnahalf. That should be possible, with .24 * Revisit the 2.6.22 decision once 2.6.24 has been in sid for 2 weeks. If 4.0r4 is still far enough out (e.g., if 4.0r3 hasn't happened by this point), and no major issues have been uncovered so far, it seems reasonable to switch. Sounds like a good plan =) Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: 2.6.24-rc7 experimental upload
Hi! On Fri, Jan 11, 2008 at 05:50:51PM +0100, maximilian attems wrote: to get wider testing of the current fine trunk, (seems to close a bunch of bugs ;) i announce an 2.6.24-rc7 upload for tomorrow morning. headers on amd64 are fixed, so go on :) if you prefer that it should hit unstable please voice. How far is -final away? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: [RFR] templates://redhat-cluster/{cman.templates}
Hi! First of all thanks for bringing this up, the package indeed needs i this kind of review. On Mon, Jan 07, 2008 at 07:32:20AM +0100, Christian Perrier wrote: I think that ALL packages are missing a common paragraph describing *what* Redhat cluster suite is. Anyone feeling like proposing one? RHCS is a cluster management infrastructure, which allows to build highly available N-node clusters with services and IP takeover on top of shared FC/iSCSI storage devices. something like that? + state transitions. Another part of CMAN is a service manager that + handles service groups. rgmanager handles service groups, not cman. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: redhat-cluster_2.20071022-1_amd64.changes REJECTED
Hi Jörg, On Tue, Dec 25, 2007 at 11:59:43PM +, Joerg Jaspert wrote: rejected [...] Bummer, I'll fix that copyright file ASAP. missing source for scnap/doc/csnap.ps This is going to be funny. A ps2txt dump of it is not enough source, is it? ;-) Best Regards Frederik -- ENOSIG signature.asc Description: Digital signature
Re: 2.6.23-2 upload
Hi *, On Wed, Dec 19, 2007 at 02:11:56PM +0100, maximilian attems wrote: announcing upload for friday of linux-2.6 trunk, remaining issues yes please, it is needed for the redhat-cluster-suite update. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#455264: openais: add ais user
Hi, On Sun, Dec 09, 2007 at 07:52:04PM +0100, Guido Guenther wrote: There is currently no user of this except cman. Please provide a rational why the package should generate something which is not used? Because people want to run aisexec without cman and aisexec wants the ais user by default. For what purpose? Does the future openais based heartbeat implementation require an aisexec user? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: openais and redhat-cluster
Hi, On Mon, Dec 03, 2007 at 06:13:47PM +0100, Guido Guenther wrote: I've pushed these here: git://git.debian.org/git/users/agx/redhat-cluster/redhat-cluster.git http://git.debian.org/?p=users/agx/redhat-cluster/redhat-cluster.git Looks like we did most of the work twice, did we? I am almost done preparing a redhat-cluster v2 package based on the Ubuntu stuff by Fabio M. Di Nitto, please find it in kernel svn. What's left is mostly fixing some manpages and writing a whole bunch of new ones. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: .config 2.6.24 i386/amd64 discussions
Hello, On Sat, Dec 01, 2007 at 03:56:01PM -0800, Steve Langasek wrote: FWIW, I think desktop and server are misleading descriptions here. It's my impression that there are lots of servers in production that would also benefit from power savings as a result of tickless. I sincerely doubt it. Current servers with dualcore opterons or quadcore xeons pull between, 200-400W idle. Add more FB-dimms, and you get more 5W each. A tickless kernel, wich might reduce the consumption by best-case 1W, is just a joke in this case. OTOH of course, if you have a laptop consuming 10-15W, and get it down by 1W, I'd love to enable tickless, thats some 10-20 minutes of battery time. Having servers downclock the CPU when idle is a good idea, especially if you have active/failover systems where the second box just waits for the first one to fail. But this is cpufreq, not tickless or HZ. Perhaps standard and performance would be better descriptors here? Which being what? Given the nature of the settings, powersave and standard could be better names. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: .config 2.6.24 i386/amd64 discussions
Hello, How is the performance impact of HZ_1000 and tickless versus HZ_100? If the impact is as big as the HZ_100 vs HZ_1000 one, I think it's time to have a desktop/laptop and a server kernel image for amd64. The desktop image would get HZ_1000, tickless and preemption. The server image would get HZ_100, no preemption, 255 CPUs support, and xen/vserver flavours. Best regards Frederik Schüler On Wed, Nov 28, 2007 at 03:18:01PM +0100, maximilian attems wrote: now that both amd64 and i386 have a tickless kernel it makes sense to enable CONFIG_HZ_1000 for both. the current consumption is no longer a trouble and we gain better interactive response. the timer interrupts should no longer reduce server perf. back in the early 2.6 game i disabled preempt, due to strange driver bugs poping up, now that this seems to have been cleared upstream all major distros ship with the PREEMPT_VOLUNTARY on, PREEMPT_BKL -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ENOSIG signature.asc Description: Digital signature
Re: Firmwares left
Hi, On Tue, Sep 25, 2007 at 10:47:02PM +0200, Holger Levsen wrote: On Tuesday 25 September 2007 21:08, Frederik Schueler wrote: As for the rest: our priority is free software, who cares about users? I guess you're serious with the rest of this email, but not with this part. Are you? I am not. Maybe the sarcasm was inapropriate, after all we have been through with this topic... :-/ Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Firmwares left
Hello, as far as the GPL and BSD licensed firmwares are concerned, the licenses of these firmwares are compliant with the DFSG and will not be castrated from the kernel, see the GR007/2006 discussion. As for the rest: our priority is free software, who cares about users? tg3: Drop. The firmware should be pruned and the driver deactivated until someone shows up with a patch upstream accepts. acenic: Drop. The firmware source available at http://alteon.shareable.org/ is - unlike to what was written during the firmware discussion last year - NOT free: ~ $ head -5 tmp/acenic/src/nic/fw2/common/fwmain.c /* * COPYRIGHT NOTICE * Copyright (c) Alteon Networks, Inc. 1996 * All rights reserved */ file: drivers/atm/pca200e.data file: drivers/atm/pca200e_ecd.data file: drivers/atm/sba200e_ecd.data file: drivers/char/ip2/fip_firm.h file: drivers/media/dvb/ttusb-budget/dvb-ttusb-dspbootcode.h file: drivers/net/hamradio/yam1200.h file: drivers/net/hamradio/yam9600.h file: drivers/net/myri_code.h file: drivers/scsi/qlogicpti_asm.c file: sound/pci/cs46xx/cs46xx_image.h file: sound/pci/cs46xx/imgs/cwc4630.h file: sound/pci/cs46xx/imgs/cwcasync.h file: sound/pci/cs46xx/imgs/cwcbinhack.h file: sound/pci/cs46xx/imgs/cwcdma.h file: sound/pci/cs46xx/imgs/cwcsnoop.h Drop. And for those affected by this driver carnage: I feel with you, a couple of boxes I take care of are going to need new NICs. Regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#317258: [stable] kernel upload to p-u
On Fri, Sep 14, 2007 at 03:10:44PM +0200, Holger Levsen wrote: On Friday 14 September 2007 14:57, Bastian Blank wrote: The patch needs to be applied upstream until it can appear again. Why? I mean, I agree for sid, but I don't see the point in not fixing this in stable. Care to elaborate? By policy, all patches we apply beyond the obvious Debian stuff, XEN and vserver must be backports, read they must go through the upstream quality assurance, and if they got accepted upstream, we can consider applying them on the current Debian kernel. For this special case, the issue is open since sarge, and the patch was either NACKed upstream, or never submitted, I don't remember. However, in the first case we won't apply it in it's current state, it needs to be fixed so upstream accepts it. If it was never submitted, this should be done now, and we will happily apply it as soon as it got blessed. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: [stable] kernel upload to p-u
Hello, I think we should add patches to update the forcedeth and e1000 drivers to the latest version, too. Those are many changes, but also many new boxes require those new drivers: obviously most nvidia based athlon and opteron boards, and many xeon board (supermicro, tyan). What is the chance to get these drivers, backported from 2.6.22 or .23 into stable? I know we most fear regressions here, how extensive must the tests be to get it in? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Debian's Linux kernel continues to regress on freedom
Hello, On Wed, Sep 12, 2007 at 12:39:05AM -0400, Nathanael Nerode wrote: The most recent linux-source-2.6.22 contains the following files: drivers/media/video/dabfirmware.h # CONFIG_USB_DABUSB is not set drivers/net/drgs_firmware.c # CONFIG_DGRS is not set drivers/usb/misc/emi26_fw.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa*_fw.h (11 files) # CONFIG_USB_SERIAL_KEYSPAN is not set drivers/net/tokenring/smctr_firmware.h CONFIG_SMCTR=m drivers/net/appletalk/cops_ltdrv.h drivers/net/appletalk/cops_ffdrv.h # CONFIG_COPS is not set drivers/net/tokenring/3c359_microcode.h # CONFIG_3C359 is not set In other words, *all* of the above drivers. It's even worse than that. Look at the information about drgs: So among them, one driver is activated, which I just deactivated in SVN. We will prune these drivers again from the lenny release kernel if there has not been found a different solution until then. So, I may repeat ANOTHER time so maybe NOW you get the point: help having the vendors re-release the drivers as GPL with sources, or have the drivers removed upstream if they are dead and should not be distributed anymore, but stop wasting our time with such upsetting and resource-consuming threads. Regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Reducing number of i386 linux images
On Wed, Aug 22, 2007 at 09:18:44AM +0200, maximilian attems wrote: - Drop k7. ack 486 image is fine for those and the hardware is no longer so wide spread. There are a whole lot of k7 boxes out there. I would not like to use the 486 flavour on my K7-smp servers, but I can run some benchmarks to verify performance penalities, if you point me to one suited for the task. I think if we are really going to drop k7, then we might tune some settings in the 686 flavour to support both CPU worlds equally good (or bad). But I guess In the end, it's all about cache line alignment, and the 686 flavour will perform more or less good enough on k7, allowing us to drop the other. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Reorganizing packages
Hello, On Wed, Aug 22, 2007 at 02:11:48AM -0700, Steve Langasek wrote: I object; if and when there ever is a new upstream kernel branch that we want to track separately this would have to be reverted, and in the meantime it would cause more confusion and work because of the need to shuffle the transition packages for users to get a smooth upgrade from etch. Hmm, anyone heard of a planned 2.7 or 2.8 tree? My last infos where 2.6 is being kept for the time being. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#421816: Status of openais ITP?
Hello, I would like to get something done in this matter, but there has not been any response nor activity since a couple of weeks. What is the status of this ITP? I had a look at the packages on mentors, and I think they are of poor quality, using CDBS and shipping an unecessary postinst script obviously belonging into another package. Please have a look at the kernel-team svn: svn://svn.debian.org/kernel/dists/trunk/redhat-cluster/openais/debian feel free to send patches if you think something is missing, or ACK an upload so we can preapare a release ASAP. Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
[etch] driver updates for 2.6.18?
Hello, I would like to update a few drivers in 2.6.18 for the next point release of etch: - e1000 (PCIe NICs support) - forcedeth (newer onboard NICs stop working on load) - 3w-9xxx (9650 controllers support) I guess there are a couple more drivers requiring an update. Before the release of Etch, we discussed the possibility of a kernel upgrade during the Etch life cycle. I wonder if we should backport drivers at all, or start working on releasing 2.6.22 or .23 for etch? We need to upgrade kernel udebs and with them the installer anyway, to benefit from the new drivers. OTOH a new upstream release means new regressions and a lot more testing. How should we proceed? Best regards Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Bug#436320: ITP: tgt - Linux target framework user-space tools
Package: wnpp Severity: wishlist Owner: Debian Kernel Team debian-kernel@lists.debian.org * Package name: tgt Version : 20070807.1 Upstream Author : [EMAIL PROTECTED] * URL : git://git.kernel.org/pub/scm/linux/kernel/git/tomo/tgt.git * License : GPLv2 Programming Lang: C Description : Linux target framework Linux target framework (tgt) aims to simplify various SCSI target driver (iSCSI, Fibre Channel, SRP, etc) creation and maintenance. Tgt consists of kernel modules, user-space daemon, and user-space tools. Some target drivers uses all of them and some use only user-space daemon and tools (i.e. they completely runs in user space). This package contains the user-space daemon and tools, a recent Linux kernel is required for the modules. Currently, tgt supports three target drivers: - IBM VIO server (ibmvstgt) - iSCSI - Xen vscsifront/back -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-2-vserver-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash signature.asc Description: Digital signature
Bug#421816: status?
Hello, what is the status of this ITP? OpenAIS is a required component for the new upstream version of the redhat cluster suite. We would like to update rh-cluster ASAP as the current version does not work with kernels newer than 2.6.20, and for this we want to have the maintainership of all concerned packages in the kernel team. So, please hand the package over. Thanks in advice Frederik Schüler -- ENOSIG signature.asc Description: Digital signature
Re: Which kernel should I use on a Dual Processor 10 GB RAM Intel server?
Hi, this box should support a 64bit kernel, check /proc/cpuinfo for the lm flag. On Thu, Apr 26, 2007 at 11:34:32AM +0200, Oliver König wrote: I have got a Dell Poweredge 2850 Rackserver with two 3.0 GHZ Xeon CPUs and 10 GB of RAM running Debian Sarge and kernel 2.4.27 (SMP). The system recognizes Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: 2.6.21-rc5
Hi, On Sat, Mar 31, 2007 at 07:22:38PM +0200, maximilian attems wrote: any voices against basing trunk on latest upstream? have an i386 working tree to commit. should 2.6.20 first be copied to sid? IMHO we should upload 2.6.20.4 to unstable, and 2.6.21-rc to experimental. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: QLogic drivers
Hello, On Thu, Mar 01, 2007 at 05:26:38PM -0800, David Wagner wrote: I'm trying to get in sync with which QLogic driver (Fibre Channel or iSCSI) versions (if any) are presently included in Debian releases. qla2xxx driven FC HBAs work fine, but you will need the firmware-qlogic package from non-free to get them working correctly. The qla4xxx driver for qlogic iSCSI devices is not included in 2.6.18, and therefore the corresponding devices are not supported by etch (now). AFAIK this driver was merged in 2.6.19. For future releases, are the drivers obtained from whatever is in the kernel tree? Plans exist to update the kernel in a future point release, in order to support newer hardware. But the qla4xxx drivers require a firmware blob, which will not be added to etch - if it will be packaged at all due to the restrictive licensing. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#410010: linux-image-2.6.18-3-amd64: Panic When BNX2 Ring Buffer Fills
[EMAIL PROTECTED] Bcc: Frederik Schueler freddy Subject: Re: Bug#410010: linux-image-2.6.18-3-amd64: Panic When BNX2 Ring Buffer Fills Reply-To: In-Reply-To: [EMAIL PROTECTED] severity 410010 important thanks Hello, On Tue, Feb 06, 2007 at 08:51:58PM -0500, Steaphan Greene wrote: The Linux kernel in Etch does not yet contain the following patch: http://www.mail-archive.com/netdev@vger.kernel.org/msg28143.html I'll have a look at this, thanks. I will ping you in this bug again when we have a snapshot to test. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#406769: linux-image-2.6.18-3-amd64: rdtsc instruction does not serialise on core2 family
tags 406769 pending thanks Hello, thanks for the report. On Sat, Jan 13, 2007 at 08:39:38PM +, Simon Mackinlay wrote: commit e4a835d383dc58212a9648ef905cb8087e0c4ab2 Author: Arjan van de Ven [EMAIL PROTECTED] Date: Mon Dec 11 21:45:01 2006 +0100 this changeset is included in 2.6.18.6 which is already in svn. You could run a snapshot kernel until the new version is uploaded, to be found using deb http://kernel-archive.buildserver.net/debian-kernel sid main Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
linux-2.6 build problems due to kernel-package
Hello, Looking at what happened to the last 2.6.20rc4 snapshots - build logs are here: http://stats.buildserver.net/build.php?arch=pkg=linux-2.6 I suggest we get rid of kernel-package in the linux-2.6 build process ASAP, because it keeps breaking linux-2.6 builds on most if not every upstream release(-candidate). Yes, after the release, of course :-) Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Solving the linux-2.6 firmware issue
Hello, On Sat, Jan 06, 2007 at 10:43:27AM +0100, Marc Haber wrote: So keyspan USB devices will be useless with Debian kernels in the very near future, since there is no alternative to the kernel driver? The keyspan drivers where already disabled since years. To be precise, since when the firmware discussion appeared the first time before the release of Sarge, so nothing really changed here (the firmwares just where in the 2.6.18 tarball for a couple of months now, after the kernel-team uploaded an unpruned tarball). Check the license of the firmwares in a vanilla kernel, and if you want to suffer some severe pain, just search in an lkml archive for the ancient discussion on this topic. Now, removing all these drivers is a workaround so we can release ASAP. The real solution needs to be addressed after the release, as was already stated in the discussion prior to the GR: - have vendors re-release the drivers including the complete source of the firmwares under a DFSG compatible license or - patch the drivers to use request_firmware(), and have vendors relicense the firmwares so we can at least ship the drivers in the modules-nonfree package These should be the priorities, too. It is preferable to have a completely free driver including firmware source and build tool-chain inside the kernel tree, like the aic7xxx driver for example. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Solving the linux-2.6 firmware issue
Hello, On Sat, Jan 06, 2007 at 05:27:22AM +0100, Frans Pop wrote: Did you check for packages that have a dependency or build dependency on linux-2.6? They'd have to be re-uploaded too... we rename the source package, not the binary packages. No need to change anything anywhere, we just want a new tarball in the archive :-) The only real drawback will be the bugreports getting attached to linux-2.6.18 instead of linux-2.6 (like we already had with .16). Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Solving the linux-2.6 firmware issue
Hello, On Sat, Jan 06, 2007 at 01:52:24PM -0800, Steve Langasek wrote: That's a big drawback. Please change the *version* of the package instead of changing the source package *name*. DOes everything from the ftp/archive management tools to kernel-package cope wiuth this? if yes, we can go this way. Renaming the source package is known to work, thus we chose that option in the first place. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Solving the linux-2.6 firmware issue
Hello, On Sat, Jan 06, 2007 at 01:19:01PM -0800, Jeff Carr wrote: This doesn't have anything to do with legality. You can legally distribute these drivers. in [EMAIL PROTECTED] Steve Langasek clearly states in the name of the release team which drivers have to be dealt with for the release, and since the kernel team does not have the time and manpower to contact all vendors or patch all drivers BEFORE the release, we remove these drivers. GR2006-07 specifically allows the exception for them. That's what the debian developers voted to allow. Am I reading the results wrong? http://www.debian.org/vote/2006/vote_007 If you think the release team is wrong, please discuss this with them. And please send only the result to -kernel, not the whole discussion, thank you - I am not the only one who killfiles everything firmware. What legal advice did you receive that made you determine that it is illegal to distribute them? IANAL, and I am the wrong one to address, see above. sorry. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Solving the linux-2.6 firmware issue
Hello, Today Bastian Blank and I finished the preparations to release the next linux-2.6 package with an orig.tar.gz complying with the GR2006-007. The following drivers will be completely removed from the next upload, because they contain legally not distributable components: dabus cops dgrs 3c359 smctr emi26 emi62 keyspan As we need to upload a new orig.tar.gz file, we need to rename the source package. Among the various possibilities, I think calling it linux-2.6.18 like we did with linux-2.6.16 seems the best choice, and there will not be any need to cope with problems which may arise if the name contains more dashes or a + sign etc. After etch is out, the next version (probably 2.6.20) will of course be called linux-2.6 again. Does this create any trouble, beside the package having to go through the NEW queue? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Bug#404143: Fans unreliable under load, permanent memory leak
Hello, On Sun, Dec 24, 2006 at 02:02:58PM +0100, Moritz Muehlenhoff wrote: Do you intent to disable ACPI entirely for all systems? It appears to me that the affected HP models could be disabled on a per-case basis using drivers/acpi/blacklist.c This looks like a good idea to me, do we know which models are affected? OTOH, I doubt we have a complete list of affected models, and who knows what problems may arise for yet to be released laptops... Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Bug#404143: Fans unreliable under load, permanent memory leak
Hi *, this is indeed a severe issue which requires all our attention and care to solve or circumvent in order for nobodies boxes to get any harm, you know how expensive these laptops are. I basically see 3 solutions/workarounds: 1. the brutal one: deactivate ACPI in 2.6.18, have the bios keep control of the fans - better a noisy laptop until I upgrade the kernel than a fried box. 2. port 2.6.19 ACPI - noop because way too much work, unless someone crazy enough to accomplish this task. 3. go for 2.6.19 Documenting arbitrary breakage in the release notes is not a solution, just consider how well manuals are usually read (if at all). Users will end with damaged hardware and blame us for it. We released woody with disabled ide dma due to somewhat similar issues (boxes hanging), so disabling ACPI in 2.6.18 and going for a 2.6.19 based 4.0r1 ASAP seems the best thing to me personally, but this is of course up for discussion. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Scheduling linux-2.6 2.6.18-9
Hello, I would like to schedule the upload of the next linux-2.6 2.6.18 version, with the following changes: 1. new vserver patch, breaks ABI 2. new Xen patch 3. Activate PAE on i386 Xen subarch, breaks ABI 4. arm changes 5. 2.6.18.5 ABI breaking patch (Honour source routing for LVS-NAT) This update bears 3 ABI breaking changes. While the vserver patch might be adaptable, the PAE migration of i386 Xen is not. But we need this change as a workaround for #399113, otherwise the i386 Xen kernels will be broken in the release, and require an immediate update. And since we are already planning an ABI bump, we can add the missing changeset of 2.6.18.5, too. 2 more things are outstanding: 1. a new orig.tar.gz without undistributable firmwares, in order to satisfy the recent GR on this issue 2. amd64 kernels for i386 We still have some work to do, in order to get these done in time. Question towards the boot and release teams: is this OK with you? I know this means a further delay of etch because of another round of udebs and various changes in the installer configs, but the Xen issue is odd and really needs a fix. The upload should be scheduled for Tuesday, unless someone vetoes. If you have any last minute changes which are that important they cannot wait for the first point release kernel, please list them here so we can discuss them. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#402701: linux-image-2.6.18-3-amd64: Nvidia driver does no longer work on amd64-Debian due to IOMMU config
Hello, On Tue, Dec 12, 2006 at 07:44:04AM +0100, Joerg Morbitzer wrote: and disable IOMMU in the kernel config. After compiling the kernel the Nvidia driver works like expected again. No way. All AMD 64bit systems have an IOMMU to access the memory beyound 4GiB without requiring software buffer bouncing (like i386 does for the upper emory, and PAE for the 4G+ region on i386). IOMMU is required for 4G+ systems and is a great feature. The nvidia drivers are buggy, you should bug them. Disabling IOMMU is out of question. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Schedule for linux-2.6 2.6.18-4
Hello, We have an urgent fix for ppc pending, thus I would like to upload ASAP with what we have now, and make another upload when the other stuff is done. Read: we do an urgency=high upload of 2.6.18 today, if this is ok for everyone... comments? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Schedule for linux-2.6 2.6.18-4
Hello Jurij, On Tue, Oct 31, 2006 at 07:35:49AM -0800, Jurij Smakov wrote: I have one important fix in the pipe (boot failure on SunBlade1000). A patch for it was posted recently, and I've just received a confirmation that it fixes the problem. I'll build a test kernel tonight and make sure that it boots fine on my boxes, after that it can go in. Please don't upload before I committed it. How is the status of this? We need to upload urgently due to a ppc issue. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Schedule for linux-2.6 2.6.18-4
Hello, On Wed, Nov 01, 2006 at 07:23:04PM +0100, Frans Pop wrote: urgency=high is bogus as that only affects migration to testing and would only be needed if 2.6.18 were already in testing. OK. What do you think about another 2.6.17 release through t-p-u then, to fix the ppc issue in testing? does it make sense at all, considering the current planning (RC1, 2.6.18)? Personally I'd say the new 2.6.18 needs at least the normal period for testing in unstable given the number of issues in the current version. I agree. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#379090: Still no news on 64bit i386 kernels
Hello, On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote: Can someone from the kernel team comment on whether there are problems with this particular patch that have not yet been noted in the bug report? If there aren't any known objections, I could review the patch myself and look at committing it. Adding amd64 as subarch to i386 would mean 3 additional flavors to build, raising the overall build-time of that package by 1.5-2h. Additionally, I don't know in what state the current cross-build env for i386 is, and building 64bit kernels on i386 might produce abi-incompatible kernels causing even more problems. IMHO the best solution would be to repackage the amd64 debs into i386 ones. This can be trivially done and should not cause any regressions. The real solution for this still is multiarch. I haven't heard much of it since a couple of months, is anyone still actively working on it? Best regards Frederik Schueler signature.asc Description: Digital signature
Schedule for linux-2.6 2.6.18-4
Fellow kernel-team members, it has been a while since our last upload, and the issues are cumulating. We have a total of 8 RC bugs we need to take care before the release, and another dozen of driver issues we should try to sort out. IMHO, the most pressing issues are: - the ext3 corruption (#392818) - the need to rebuild using a newer kernel-package (#395110) - the broken ABI - renaming the orig.tar.gz in order to remove the 8 firmwares as discussed with the release managers - alpha gcc-4.1 migration I personally have somewhat lost the overview on on open issues being busy with RL work the past 2 weeks, so I would like everyone of you to compile a short list of things you have on your agenda for 2.6.18-4, and generally before the release. Then, we should schedule 2.6.18-4 for upload sometime this week. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Schedule for linux-2.6 2.6.18-4
Hey, On Mon, Oct 30, 2006 at 04:56:17PM +0100, Norbert Tretkowski wrote: It seems that there's no ABI bump for -4 wanted, so no way to move alpha to gcc-4.1, I already reverted my earlier commit. We need to bump the ABI anyway because of changes in -3, and your changes where planned for this release too, so please add them back. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Schedule for linux-2.6 2.6.18-4
Hello, On Mon, Oct 30, 2006 at 04:41:32PM +, Oleg Verych wrote: I will not resend, please find my message to you, Frederik, for 18-3: Message-ID: [EMAIL PROTECTED] http://permalink.gmane.org/gmane.linux.debian.devel.kernel/23077 Yes, driver backports are a topic too. We wanted to discuss this on the last kernel-team meeting, but never came to this. I think PCIID updates are fine, and important new drivers needed for installation, like network sata scsi or ata drivers. But this is just my opinion, we might want to find a consensus in the team on this. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [kernel] r7653 - in dists/trunk/linux-2.6/debian: . patches/bugfix patches/bugfix/sparc patches/features patches/series templates
Hi, On Fri, Oct 27, 2006 at 10:46:05AM +0200, maximilian attems wrote: On Fri, Oct 27, 2006 at 08:37:38AM +, Bastian Blank wrote: Revert revisions 7641 to 7652. Unchecked changes. big NACK, that is _not_ an explanation and i'm happily running ii linux-image-2.6.18-1-686 2.6.18-4~snapshot.7648 7652 failed everywhere, see http://stats.buildserver.net/build.php?arch=pkg=linux-2.6 Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#395031: Kernel complains about DMA
Hello, On Tue, Oct 24, 2006 at 04:30:50PM +0200, Panagiotis Issaris wrote: Oct 24 11:00:25 localhost kernel: CMD643: IDE controller at PCI slot :00:08.0 Oct 24 11:00:25 localhost kernel: CMD643: chipset revision 0 Oct 24 11:00:25 localhost kernel: CMD643: not 100%% native mode: will probe irqs later Oct 24 11:00:25 localhost kernel: CMD643: simplex device: DMA forced ^^ Oct 24 11:00:25 localhost kernel: ide0: BM-DMA at 0xfe00-0xfe07, BIOS settings: hda:pio, hdb:pio Oct 24 11:00:25 localhost kernel: ide1: BM-DMA at 0xfe08-0xfe0f, BIOS settings: hdc:pio, hdd:pio I doubt this box will do DMA, ever. AFAIK the chipset just does not support it. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#393329: After seemingly successful install on Turion X2 system, freeze on boot
Hello, On Thu, Oct 19, 2006 at 07:22:23AM -0400, Carl Fink wrote: Is there, perhaps, a debugging kernel I could test that logs everything? If there isn't a prebuilt one, I might just compile one this weekend. you should give an amd64 kernel a try. Install it with dpkg --force-architecture. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#393304: APIC Error on CPU0: 00(00)
Hello, On Sun, Oct 15, 2006 at 08:54:15PM -0400, [EMAIL PROTECTED] wrote: Package: kernel-image-2.6.8-12-amd64-k8 Version: 2.6.8-16sarge4 Install System: Compaq Persario v5000. Chip: Turion 64 linux 2.6.8 is presumably much older than this box, and support is expected to be broken. Please use a recent kernel from either unstable or backports.org. Best regards Frederik Schueler -- ENOSIG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: seconds searched for override of resolution 007 needed. (Was: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.)
Hello, I second the following proposal: On Sun, Oct 15, 2006 at 10:07:02AM +0200, Sven Luther wrote: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 0. This resolution overrides the resolution just voted (http://www.debian.org/vote/2006/vote_007). 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#393958: linux-2.6: Please enable CONFIG_VSERVER_HARDCPU for vserver flavour(s)
Hello, On Thu, Oct 19, 2006 at 01:36:13AM +0800, Andrew Lee wrote: Please enable CONFIG_VSERVER_HARDCPU for vserver flavour(s). this change is already in svn and pending for the next upload. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Kernel width HIGMEM64G=y kills my adaptec hw-raid
Hello, On Tue, Oct 17, 2006 at 09:58:16AM +0200, [EMAIL PROTECTED] wrote: I think I found a bug in kernel-source-2.6.8-16sarge4. I'm trying to compile it width HIGHMEM64G support as I have 12Gbyte RAM. 2.6.8 is _old_. Can you please give a try to 2.6.17-2-686-bigmem from backports.org, or 2.6.18-1-686-bigmem from unstable, and see if that works for you? The -bigmem flavour has PAE activated and supports up to 64G ram. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [PROPOSAL] Final consensual proposal for the problematic firmware issue in the linux kernel sources.
Hello, sorry for being late on this, I took a couple of days off from everything firmware and this got inbetween. The Proposal worked out by Sven covers the consensual position of the kernel team, as discussed on the last kernel team meeting. I think this GR should be voted upon, as it considers all aspects of the issue. I hope we can vote on this despite the already running GRs, thus I second the following proposal: === START OF PROPOSAL === Definition: For the purpose of this resolution, the firmware mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. END OF PROPOSAL Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Scheduling linux-2.6 2.6.18-3
Hello, I would like to schedule the upload of linux-2.6 2.6.18-3 for next Thursday, 12th October. Two big issues are still open: - hppa FTBFS - alpha gcc-4.0 build dependency according to [EMAIL PROTECTED], 2.6.17 builds fine on alpha with gcc-4.1 with the minor changes applied. This needs to be ported to 2.6.18. The firmware issue is still open, too; we will wait for the GRs to be done though, before doing anything in this concern. As usual, if someone needs more time for pending changes, drop a line. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Processing of linux-latest-2.6_3_multi.changes
Hello, not all architectures have the kernel-image-2.6* transitional packages, namely arm armeb hppa m68k mips mipsel please add them to linux-latest-2.6 in trunk, in debian/templates/control.extra.in Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#390791: mkinitramfs doesn't include required firmware
Hello, On Mon, Oct 02, 2006 at 10:52:39PM -0400, Michael Shuey wrote: The qla2xxx driver gets loaded during the initramfs, but it's completely non-functional. I need to manually remove it and re-insert it after booting (since /lib/firmware exists in the full userland) before the driver will actually work. Did you install the firmware on your own, or from the firmware-qlogic package in non-free? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: 2.6.12 smp for i686?
On Thu, Sep 28, 2006 at 05:33:50PM +0200, Folkert van Heusden wrote: [EMAIL PROTECTED]:~$ apt-cache search kernel | grep 2.6.18 [EMAIL PROTECTED]:~$ (using unstable) Can't find it? It's called linux-image-* now instead of kernel-image-*, and the dummy-packages for migration still point to 2.6.17. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
scheduling linux-2.6 2.6.18-2
Hello, I would like to schedule the upload of linux-2.6 2.6.18-2 for tomorrow, Thursday 27th. This upload fixes the hppa FTBFS, the alpha-smp RC bug and the ppc/prep headers. Additionally, the xen-vserver subarch is back for amd64 and i386. As usual, if someone has more pending changes, raise your voice if you need more time so we can reschedule. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hello, On Mon, Sep 25, 2006 at 01:30:34PM -0400, Nathanael Nerode wrote: I emailed the contact address at Intel about e100, but it seems to forward to tech support. We'll see if anything comes back. what did you write them? IMHO, the topmost priority should be to get DFSG-free sources and an in-tree build infrastructure for the firmwares, like the aic7xxx driver. We should ask the vendors to relicense the blob and implement request_firmware only if they strictly refuse to provide sources. It also would be interesting to know if the blobs are actually code or register bank settings, as they don't need to be removed in the latter case, not being software at all. Maybe we should prepare a document template which we can send to all vendors, listing the reasons for our actions and possible actions we see they could take, everything in a friendly legalese so we can expect a real answer. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hello, On Sun, Sep 24, 2006 at 11:25:15AM -0400, Nathanael Nerode wrote: If the firmware-loading tg3 driver is present in the next kernel package version, I will believe that the kernel team is acting in good faith to try to satisfy the Social Contract. According to the kernel-team patch policy, this patch needs to be either a backport from a newer version, or a patch submitted and accepted upstream. Where can I find the current version of your patch? AFAIK it was rejected upstream because some functionality was broken, this regression needs be fixed and the patch resubmitted in order for us to consider an inclusion. Then, firmware-loading support in d-i is still missing, this issue should be be fixed too before we consider the patch. I have a board with tg3, so I can perform the needed testing. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: proposal: kernel team IRC meeting on Saturday, 30th September 16:00 UTC
Hello, On Sun, Sep 24, 2006 at 11:42:48AM -0400, Nathanael Nerode wrote: (It's an egregious case, because the vast majority of tg3 users don't need firmware at all. Including the firmware in main in order to support network installs by the tiny number of users who do need it -- I have heard of three such users ever -- can't be considered sufficiently important to break the 100% free promise for, can it? Furthermore, this is a case where the kernel team has *regressed* from a previous release.) on my old workplace, I came across a dozen of DELL poweredge which ALL needed the firmware to work, guess my face when I wanted to install sarge on those. But yes, most tg3 nics do not need the firmware. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hi, On Sun, Sep 24, 2006 at 01:08:10PM -0400, Nathanael Nerode wrote: Today I sent an email asking upstream to remove dgrs based on its uselessness; we'll see what happens. Thanks. We should consider removing it, too then. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#389232: linux-image-2.6-amd64: mounting xfs filesystem causes kernel oops
reassign 389232 linux-2.6 thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Hello, On Thu, Sep 21, 2006 at 02:53:21PM +0200, Jonas Smedegaard wrote: I honestly believe that moving linux-2.6 to non-free hurts our users more than stripping non-free parts of the Debian-precompiled kernel. of course. Also, section 4 of the SC talks equally about users and free software, not users above free software. And free software above the needs of our users neither. And exactly this is what it is all about: find a way to satisfy BOTH priorities, not just one. As long as there is no working alternative to shipping firmwares in main, removing them is simply wrong. working together with upstream and the vendors to fix the issue is what we should do, not ripping the blobs aout of the kernel and forgetting about their existence. Guess which Distribution users who made a poor buying choice will not use again. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
proposal: kernel team IRC meeting on Saturday, 30th September 16:00 UTC
Hello, I would like to propose an IRC meeting for all kernel team members, to discuss where we stand and what we want to do in the future, concerning kernel firmwares. The meeting should take place in #debian-kernel on irc.debian.org on Saturday, 30th September 16:00 UTC Topic: 1. Find a common platform for all kernel-team members concerning firmware blobs. Is the scheduled time OK for everyone? Does anyone have additional topics to discuss? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hello, On Fri, Sep 22, 2006 at 03:13:14PM +0200, Jonas Smedegaard wrote: And exactly this is what it is all about: find a way to satisfy BOTH priorities, not just one. No. It is about the definition of our users. If our users are dependent on non-free software, then we indirectly say in our social contract that free and non-free software is of equal concern to us. this is what section 5 of the social contract is about. let me cite the relevant part: Thus, although non-free works are not a part of Debian, we support their use and provide infrastructure for non-free packages I claim that our users does not include users of non-free software. This is a contradiction to the social contract. I would even say that such users are free-riders of free software, if their use is dependent on our system which is 100% free software. This is insulting. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#388553: Kernel 2.6.16 with possible malfunction
Hello, the 2.6.17 kernels already migrated into testing, can you please try to reproduce this with linux-image-2.6.17-2-k7? On Thu, Sep 21, 2006 at 09:32:03AM +0200, Stephan Trebs wrote: Package: linux-image-2.6.16-2-k7 Version: 2.6.16-18 Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Preparing linux-2.6 2.6.18-1
Hi, On Wed, Sep 20, 2006 at 06:16:32PM -0700, Steve Langasek wrote: On Wed, Sep 20, 2006 at 03:38:50PM +0200, Frederik Schueler wrote: Second: this release contains ALL binary firmware blobs shipped upstream, even those we kept pruning since the day Herbert Xu removed them the first time in 2004. What in the world? Why would you do that anyway? because removing firmwares without an adequate alternative means not considering the needs of our users which rely on these firmware blobs to run their hardware, and thus IMHO conflicts with section 4 of the social contract. Neither is introducing regressions in the freeness of our kernel packages relative to sarge. pruning the firmware without an alternative was wrong in the first place, this step just fixes that error. Indeed, taking such a step is likely to lead many voters to think that the only way to prevent the kernel team from filling our kernel packages with as much non-free code as they can stuff into it is by voting down any GRs that would relax our stance on firmware. *THAT* would cause release delays. This would be a gross overreaction, and if this happens, I will opt for moving linux-2.6 to non-free until the firmware issue is sorted out *completely* with upstream and the hardware vendors. We need to find a balance between the needs of our users and free software. Ripping non-free bits out is wrong, as long as there are no alternatives, and keeping non-free stuff in main without working on a real alternative is of course wrong too. But, with the firmware-nonfree package, we have already started to work on it, although things have to go through upstream. basically, the solution looks as follows, for every single firmware-needing driver: - best case, the firmware source is fully disclosed and relicensed in a DFSG compatible way. - worst case, the firmware is licensed as distributable in non-free, and the driver loads it from userspace. this means: vendors need to be contacted and convinced to relicense and disclose the sources, alternatively those non-distributable blobs need to be relicensed, and for all drivers needing non-free firmwares a patch has to be written, which must be of such a good quality that upstream accepts it. This way, the firmware issue is solved for the free software community as a whole, and not only for Debian. If the release and debian-installer teams don't object, we will upload an unpruned linux-2.6 2.6.18-1 to unstable today. I do object to the un-pruning of non-free material from the kernel packages without giving the project a chance first to consider how this changes the status wrt the DFSG. In particular, this totally undermines any claim that Debian is asymptotically approaching DFSG compliance in its releases. This is why we wanted to wait for the GR outcome, but looking at -vote I guess we will delay the release considerably if we do so. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Preparing linux-2.6 2.6.18-1
Hello, Linux 2.6.18 has been released, and it looks like we can do a first upload today. First, the migration status and plan looks as follows: - linux-2.6 2.6.17-9 has already migrated to testing and can be updated through t-p-u. - after linux-latest-2.6 migrates into testing later today, we will upload a new linux-latest-2.6 pointing to 2.6.18 to unstable. - the kernel udebs in unstable are 2.6.17 and need manual intervention to migrate. - it should be ok to remove the linux-2.6.16 packages after we receive confirmation that d-i works well with 2.6.17 in testing. Considering this, an upload of linux-2.6 2.6.18-1 to unstable should not delay any D-I plans, and we we should be able to proceed. Second: this release contains ALL binary firmware blobs shipped upstream, even those we kept pruning since the day Herbert Xu removed them the first time in 2004. Initially, we wanted to wait for a positive GR vote outcome before doing this step, but as every day existing GR proposals are changed and new ones made, this seems to be going to be delayed indefinitely, which is not acceptable from a release point of view. Only the qla2xxx firmwares have been removed upstream and in order to operate these cards, our users need the firmware deb/udeb from non-free. Further work in this direction is scheduled for 2.6.19, after Etch has been released. Third: we will make at least one other round of NEW, as xen and vserver patches are currently missing, so there is no need to hurry for ABI changes or new flavors. We still have enough time to add everything we want to have at release time. I know this is pretty short-term, but does anyone need more time to add urgent changes which should be in the 0-day upload of 2.6.18? The architectures taking part in the snapshot buildd network (amd64 i386 powerpc s390 sparc) should be in a releasable state, while for the others, the build system has been changed to not fail if missing options are not set, but to pick the upstream default - this will hopefully help in building those architectures, which haven't been updated yet. If the release and debian-installer teams don't object, we will upload an unpruned linux-2.6 2.6.18-1 to unstable today. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
scheduling linux-2.6 version 2.6.17-9
Hello, I would like to upload linux-2.6 2.6.17-9 tomorrow, wednesday 13th. It includes 2.6.17.12 and .13, among some other small fixes. Does anyone have pending changes which need more time? If so, please raiso your voice so we can reschedule. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: kernel build dependency on gcc-4.0?
Hello, On Tue, Sep 05, 2006 at 09:55:09AM +0200, Matthias Klose wrote: Will gcc-4.0 be dropped as a build dependency for etch, or be kept? It will be dropped. Currently, only hppa and alpha still build-depend on gcc-4.0. This will be changed with linux-2.6 2.6.18-1 (and maybe in 2.6.17 too, if we do another ABI bump), as soon as we get there. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [amd64] What happened to the agpgart module?
Hello, On Thu, Aug 31, 2006 at 04:11:21PM +0200, Free Ekanayaka wrote: it seems that in the latest linux-image packages for amd64 the agpgart module is missing (at least in the 2.6.17 series), preventing DRI from loading for 3D acceleration support, see this bug report it's builtin now by default if you activate GART_IOMMU, the iommu on K8 (which you usually want to activate). Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Scheduling linux-2.6 2.6.17-8
Hello, I would like to schedule the next upload of linux-2.6, version 2.6.17-8 for tomorrow Thursday 31st. Thanks to Kyle the build failures on alpha hppa ia64 mips and mipsel should be fixed now. If this version builds and works on all architectures, I would like to call it a testing candidate and have it moved to Etch soon, and start concentrating on 2.6.18, which was already begun in trunk. If someone has pending changes and needs more time, please drop a line so we can reschedule accordingly. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
kernel firmwares: GR proposal
Overview: The Linux kernel source contains device drivers that ship with firmware files provided by the hardware manufacturer. They are uploaded during the driver initialization to the corresponding hardware device. Some of these binary image files are provided as a hexdump of register bank settings, others consist in fact of compiled binary code which is executed on the hardware device. Any device driver in the Linux kernel is freely available in source format and licensed under the GPL2. For many device drivers with attached firmware, the firmware image is freely distributable along with the corresponding driver. The most common source format for firmwares is the hexdump char array. It is almost impossible to distinguish between register dumps and binary code without asking the device manufacturer who provided the firmware. Removing every firmware which is distributed as hexdump only will cripple the kernel to an extent where it becomes unusable for most of our users, because popular network and scsi devices are among the drivers in question. Without these drivers, the user's system might not be installable at all. The current situation: We achieved a lot of progress compared with the situation in 2.6.8 (the kernel that shipped with sarge). We were able to convince upstream that a firmware loader is a good thing, and that firmware and kernel code should be separated. This firmware loader was added in 2.6.13, and meanwhile, more than 40 drivers have been converted to the new infrastructure. However, this is not yet finished, and some important drivers still use the old method. There will be a day where we can drop the remaining legacy, but we are not there yet. Also, though the firmware loader allows us to put the firmware where it belongs to (main or non-free, depending on the case), the installer can as of now only take udebs from main. Fixing this is not too hard, but it is doubtful whether we can fix this in time for etch, and we do not want to depend on that (and even then, we still would have non-free firmware, see above). But since there is lots of hardware which needs firmware for correct operation, the installer would not work for mainstream hardware otherwise. There are two ways how to deal with it: 1. Accept these issues as transitional issues for now; or 2. Delay etch for some serious time. In our social contract, we promised that the users and the free software community are our priorities. We firmly believe that our users profit very much from releasing etch in time, and that this is important enough that we can accept the transitional status with having a few firmware images left in main that should belong somewhere else. Of course, everyone who wants to make the number of such firmware images as small as possible is welcome to help converting old firmware loaders to the new standard, and working on the Debian installer. We are happy if this issues become smaller or even vanishes, but we do not want this to be a release blocker. So, we propose this GR: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. We want to emphasize that the success of this GR is considered as necessary by the kernel and release team for successfully delivering etch in time (and to allow us a successful planning of that). on behalf of the kernel- and release team Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Scheduling linux-2.6 2.6.17-8
Hi, On Wed, Aug 30, 2006 at 05:59:42PM -0400, Kyle McMartin wrote: If each arch maintainer could give the kernel a testbuild, that would be great. Ideally, we should have a snapshot buildd for every architecture, so far only i386 sparc s390 ppc and amd64 are available: http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/ Please contact Bastian if you want to add a buildd for your architecture. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
release plan: please fix fix linux-2.6 2.6.17 on alpha hppa ia64 mips mipsel
Fellow kernel team members, please have a look at your architecture and fix it as soon as possible: according to http://buildd.debian.org/~jeroen/status/package.php?p=linux-2.6 the following architectures are broken: alpha hppa ia64 mips mipsel we cannot move 2.6.17 into testing as long as these issues are not fixed, so please hurry up :-) Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#381951: [kernel] r7232 - in dists/sid/linux-2.6/debian: arch/i386
Hi, On Wed, Aug 23, 2006 at 02:48:58PM -0600, dann frazier wrote: heh - nothing passive-aggressive intended in my message, just making sure it wasn't an accident :) ok ;) btw, did you see my note #381951 about the additional space requirements for that option? fjp was asking joeyh's opinion last I saw. but, I don't think it'll harm anything to go ahead and do a release with it, we could always back it out later. I agree, we should reconsider only if the size increase causes trouble with D-I. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#292061: closed by Nathanael Nerode [EMAIL PROTECTED] (PREEMPT will remain enabled)
reopen 292061 thanks Who gives you the authority to close this bug? Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Preparing 2.6.17-7
Hello, the next 2.6.17 upload, version 2.6.17-7 should become a candidate for testing. I would like to schedule the upload for Wednesday, Aug. 23. amd64 and i386 will go through NEW again, due to the added xen images. we have 4 RC bugs left, of which 2 need immediate attention: #342246: [ia64 headers] arch/ia64/modules.lds: No such file or directory #369517: linux-image-2.6.16-1-alpha-smp: undefined scsi symbols; fails to allocate percpu data The other two RC bugs concern firmware, and will be addressed after a solution for the firmware issue has been found. Unfortunately, alpha seems rather unmaintained lately. We cannot support it anymore this way, and may remove it in a future upload. As usual, if more time is needed for anything pending, we will of course reschedule. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Bug#383707: linux-image-2.6.17-2-amd64: Please enable CONFIG_R8169_VLAN on amd64
Hello, On Fri, Aug 18, 2006 at 11:18:49PM +0200, Aurelien Jarno wrote: CONFIG_R8169_VLAN is enabled on all architectures that have the r8169 module, but amd64. Could you please fix that. Thanks. fixed in svn. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Kernel schedule proposal for Etch
Hello, we should finally agree on which kernel version we want to release etch with, and on an appropriate timeframe. The goal should be obvious: release Etch on December, 4th. All kernel team members I asked so far would prefer a release with 2.6.18, which is likely to be released upstream within the next 4 weeks. The Debian installer team obviously would like as much time as possible to find out and fix all emerging bugs. Trying to put both requirements together, the kernel release schedule could look as follows: today: start migration of 2.6.17 kernel and udebs to testing 15.09: upload 2.6.18 to unstable [1] 01.10: migrate 2.6.18 kernel and udebs to testing 04.11: freeze kernel - No more changes to the testing version. Start of security support for the kernel on security.d.o [2] 04.12: release I would like to keep the non-free firmware discussion as a separate topic, thus it is not considerer in this schedule. I'd like some feedback from both the installer and release team if they think this is a feasible way for further action; if so, I'll also contact the security team for begin of security support. Best regards Frederik Schueler [1] The 2.6.18 release obviously depends on the upstream schedule, but 4 weeks from now is realistic considering the 2.6.18-rc4 status. [2] Kernel freeze as in: security fixes will go into a branch targeted at security.d.o and proposed-updates. We won't touch the kernel in Etch after the freeze, but for extreme security issues affecting the installation process, like remote root exploits. All other issues will be addressed as needed in a security update and future point releases. -- ENOSIG signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hallo, On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote: We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. then, please, send patches. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hello, On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote: These are fine words, but how do you think they can translate into reality ? We don't currently have the ressources to do it the way it should be done, and evne if we did, the deficiencies of d-i will make the work we do useless. Sven, can you please finally STOP flaming against the debian-installer team, thank you. But then, you could help, and put your actions where your mouth is, by helping in the elaboration of an exhaustive list of such problematic firmware hexdumps, together with their licencing conditions, their copyright holder, and a summary of what the module is good for. I agree, everyone who wants to see the firmware issue solved should either start doing something about it or be silent. here is an outdated wiki document, where to start with: http://wiki.debian.org/KernelFirmwareLicensing Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: linux-2.6 - compiler
Hello, On Mon, Aug 07, 2006 at 10:19:41AM +0200, Norbert Tretkowski wrote: At least alpha seems to be in an unmaintained state, and this have to be solved quickly. Aha. How is the alpha-vserver flavour coming along? ;-) Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: patch reorganization
Hello, I think reorganising the patches starting with 2.6.18 is a good idea, especially when I look at the tons of patches we had in some of the past releases. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Preparing the next linux-2.6 2.6.17 upload: ABI bump?
Hello, we have several changes pending which require an ABI bump, or at least would cause the next upload to go through NEW: - xen images - merge of amd64 k8 and p4 flavours into one generic - smp-alternatives for amd64, dropping the UP flavours - change default compiler to gcc-4.1 for some architectures I would like to schedule the upload for Wednesday, 9th August. This should leave enough time to implement and test all changes apropriately. Please post other changes you want to implement, which require an ABI bump or will cause the package to go through NEW (eg new flavours). Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: which kernel version for etch
On Sun, Jul 16, 2006 at 10:59:05AM +0200, Andreas Barth wrote: our original plan has been to release the d-i RC on 14th August, and freeze the kernel for this on July 30th. Is this plan still current? If so, can we expect an acceptable kernel on these days? We should try to meet the original schedule as close as possible, in order to release in December. Due to various problems, 2.6.16 has not made it into testing yet, sadly postponing the BETA3 release of D-I. The two local root vulnerabilities have delayed this even more now, but latest Linux-2.6.16 was uploaded with urgency=high including all security fixes and should enter testing ASAP. The plan also included a small window around October 15th to allow an ABI bump / a new kernel version into etch - I hope this is still ok for all involved. Looking at the 2.6.16.x ABI change history and considering our open topics with the 2.6.17 package we want to complete before kernel freeze, there will probably be a few more ABI bumps before the package is finally ready. We probably will need some flexibility here, especially in the light of the last two security issues. But this should be discussed when at the appropriate time. So far, we can only say: one ABI bump will probably not be enough. Please note that from the release team's side, there is no requirement to freeze the kernel in any other way than to allow the installer at this time, so making the time span between freeze and d-i RC shorter won't get an objection from us if the installer team is happy. Great. We will coordinate the next steps after beta3 is done. I would like to point out the we will not allow a release of Etch with a vulnerable kernel, as it happened with Sarge, and from discussions on IRC I am sure this is a consensus. Updating and building the kernel images, udebs and the installer currently takes approximately one week round trip time. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
