Re: Incomplete log for linux 3.16.7-ckt4-1 on mips
* Ben Hutchings (b...@decadent.org.uk) [150118 14:23]: The attempted build of linux version 3.16.7-ckt4-1 on mips-aql-01 failed, but the log shown at https://buildd.debian.org/status/fetch.php?pkg=linuxarch=mipsver=3.16.7-ckt4-1stamp=1421462317 is incomplete so I have no idea why. Is there any more information you can retrieve that could explain the failure? Unfortunatly the log on the filesystem is incomplete as well. I'll schedule a rebuild. Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150118195920.go5...@mails.so.argh.org
sparc / Problems with 3.2-kernel
Hi, today I tried to resurrect our buildd on schroeder (which is from architecture sparc). While trying to do so, I had a couple of strange behaviours like vi freezing after 20-30 seconds, or I couldn't about tail with ctrl+c or suspend with ctrl+z. This didn't change after a reboot. Machine was running our official 3.2-kernel. After Martin rebooted the machine into oldstables 2.6.32 kernel, things are working as they should, and the buildd is up again. Question: Is this a known issue? How can we get a fix for that? (I would assume DSA will consider it a non-option to not be able to upgrade to our default kernels.) Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130602130209.gv28...@mails.so.argh.org
Bug#638068: unbootable initrds are RC
severity 638068 serious thanks Hi, AFAICS, we cannot release with an initramfs that generates unbootable initrds on one of our supported architectures. Setting this bug to serious for this reason. Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120528184248.gj13...@mails.so.argh.org
Re: amd64 as default architecture
* Marco d'Itri (m...@linux.it) [120520 17:31]: On May 20, Ben Hutchings b...@decadent.org.uk wrote: No, keep i386 userland only. Though we might consider reducing even that to a 'partial architecture' that has only libraries (similar to ia32-libs today, only cleaner). Don't you believe in x32? What do you mean, 'believe'? I'm aware it may allow some applications to be somewhat more efficient than either i386 or amd64. I doubt it's worth adding to the Debian archive, but if we did then I imagine it would also be as a partial architecture. I cannot see any use case, except supporting proprietary software, where a i386 userland-only port would be more useful of a x32 port (which would be userland-only by definition). Two issues: 1. Migration of existing systems is easier. 2. There are still machines bought new which aren't ready for x32. Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120520153906.gj2...@mails.so.argh.org
Bug#601911: Please add an meta-package for loongson2f
* Ben Hutchings (b...@decadent.org.uk) [101031 10:11]: On Sun, 2010-10-31 at 02:36 +0200, Andreas Barth wrote: Package: linux-2.6 Version: 2.6.36~rc6-1~experimental.1 Severity: wishlist Hi, could you please add an meta-package for the loongson-kernels (similar to e.g. linux-image-2.6-4kc-malta but for loongson2f not for malta)? This will be done automatically when linux-latest-2.6 is updated to point to the latest kernel version (rather than 2.6.32-5-*). Can't I get that in experimental even today? ;) (If it's too much effort, please just ignore it - I have one machine that is following experimental kernels) Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101031094019.gi2...@mails.so.argh.org
Bug#601911: Please add an meta-package for loongson2f
Package: linux-2.6 Version: 2.6.36~rc6-1~experimental.1 Severity: wishlist Hi, could you please add an meta-package for the loongson-kernels (similar to e.g. linux-image-2.6-4kc-malta but for loongson2f not for malta)? Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101031003601.gh2...@mails.so.argh.org
Bug#601148: Please add an kernel image for loongson 2e
* Ben Hutchings (b...@decadent.org.uk) [101024 01:49]: On Sat, 2010-10-23 at 21:53 +0200, Andreas Barth wrote: Package: linux-2.6 Version: 2.6.36~rc6-1~experimental.1 Hi, can you please add an kernel image for loongson 2e as well? The best seems to be to clone the working 2f configuration, and set CONFIG_LEMOTE_FULOONG2E instead of 2F. Rest should be identical (if there are issues, I'll of course follow up). Are these not similar enough to handle with just one flavour and maybe a few code changes? If I remember my discussions with Aurel correct, this is not possible. (Otherwise, I agree that would be a good thing.) Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101024085900.ge2...@mails.so.argh.org
Bug#601148: Please add an kernel image for loongson 2e
Package: linux-2.6 Version: 2.6.36~rc6-1~experimental.1 Hi, can you please add an kernel image for loongson 2e as well? The best seems to be to clone the working 2f configuration, and set CONFIG_LEMOTE_FULOONG2E instead of 2F. Rest should be identical (if there are issues, I'll of course follow up). Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101023195320.gb2...@mails.so.argh.org
Bug#583689: please add support for longsoon 2f
* Ben Hutchings (b...@decadent.org.uk) [100531 19:25]: Loongson: define rtc device on mc146818 compatible systems does not even seem to have been submitted yet. done, accepted by Ralf now: http://www.linux-mips.org/archives/linux-mips/2010-06/msg00036.html Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100602103049.gq2...@mails.so.argh.org
Bug#583689: please add support for longsoon 2f
* Ben Hutchings (b...@decadent.org.uk) [100531 19:25]: Loongson: define rtc device on mc146818 compatible systems does not even seem to have been submitted yet. I'll make sure it gets into the kernel. Also I can confirm that I definitly need this patch for the RTC to work. Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100531172654.gl2...@mails.so.argh.org
Re: Please reject linux-2.6 2.6.32-7
* Ben Hutchings (b...@decadent.org.uk) [100208 00:58]: On Sun, 2010-02-07 at 22:27 +0100, Torsten Werner wrote: Hi, Ben Hutchings schrieb: linux-2.6 version 2.6.32-7 includes an incomplete bug fix that will result in failure to boot 32-bit userland on a 64-bit kernel. fyi: aba come to #debian-buildd or #d-release and say us so. And tell the *** maintainer that they should do that. kernels waste lots of time, especially on the slow arches Sorry about that - I was about to catch my train to FOSDEM and just tried to limit the damage before leaving. Given more time to think about it I would have asked to cancel the builds too. Ok. Please just remember it next time (if there is a next time). Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading linux-2.6
* Julien Cristau (jcris...@debian.org) [100125 19:27]: On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, so I'm not sure what difference blocking the next one makes. That our testing users don't have to life with strange error messages they wouldn't get if the abi would be bumped properly. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading linux-2.6
* Ben Hutchings (b...@decadent.org.uk) [100125 20:14]: On Mon, Jan 25, 2010 at 08:02:31PM +0100, Andreas Barth wrote: * Julien Cristau (jcris...@debian.org) [100125 19:27]: On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, so I'm not sure what difference blocking the next one makes. That our testing users don't have to life with strange error messages they wouldn't get if the abi would be bumped properly. OK, maybe we should start numbering ABIs with this next version. I'd appreciate that very much. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552422: linux-2.6 2.6.31-1 FTBFS on mipsel
Package: linux-2.6 Version: 2.6.31-1 Severity: serious Hi, this package FTBFS on mipsel: MODPOST vmlinux.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 ld:arch/mips/kernel/vmlinux.lds:168: syntax error make[5]: *** [.tmp_vmlinux1] Error 1 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd-linux-2.6_2.6.31-1-mipsel-sv6ZWe/linux-2.6-2.6.31/debian/build/build_mipsel_none_4kc-malta' make[2]: *** [debian/stamps/build_mipsel_none_4kc-malta_plain] Error 2 make[2]: Leaving directory `/build/buildd-linux-2.6_2.6.31-1-mipsel-sv6ZWe/linux-2.6-2.6.31' make[1]: *** [build_mipsel_none_4kc-malta_real] Error 2 make: *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 make[1]: Leaving directory `/build/buildd-linux-2.6_2.6.31-1-mipsel-sv6ZWe/linux-2.6-2.6.31' Please see https://buildd.debian.org/fetch.cgi?pkg=linux-2.6ver=2.6.31-1arch=mipselstamp=1256513866file=log for the full build log. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of Linux 2.6.31
* Ben Hutchings (b...@decadent.org.uk) [091018 20:17]: There was a build failure for linux-2.6 on alpha which needs to be fixed somehow. Alpha is no longer an release architecture, so I doubt that the release team would care. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X.org plans for the squeeze cycle
* Bastian Blank (wa...@debian.org) [090909 12:37]: On Wed, Sep 09, 2009 at 11:37:18AM +0200, Julien Cristau wrote: One more thing. Intel plans to deprecate userspace mode setting with their Q4 2009 release (meaning December this year, so probably something we'll want for squeeze, depending on the freeze date you pick). Oh, no. Not again. It does not yet properly work without the new memory manager (#538442). And KMS is completely unusable currently on this kernels. If not at X side, is it a possibility to either (a) add the new memory manager to lenny (I assume not), or (b) tell the users you need to upgrade your kernel first (and make the new X pre-depending somehow on the kernel). Of course, this sounds to me like people need to do updates in console mode, which ... isn't the best either. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: No password prompt on ttyACM0
* Gert Doering (g...@greenie.muc.de) [090218 20:45]:
Hi,
On Wed, Feb 18, 2009 at 11:35:06AM -0700, Sam Noble wrote:
I'm using some Zoom 2985C USB modems (and a few other similar cdc_acm
USB modems) for out-of-band management on my Vyatta routers (Read
Debian Lenny/Testing Systems).
[..]
At -x9 debug level, the older systems logs look like this:
02/17 18:21:52 CM0 print welcome banner (/etc/issue.mgetty)
02/17 18:21:52 CM0 getlogname (FIDO AUTO_PPP), read:vyatta[0d]
02/17 18:22:00 CM0 input finished with '\r', setting ICRNL ONLCR
02/17 18:22:00 CM0 tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
02/17 18:22:00 CM0login: use login config file
/etc/mgetty/login.config
02/17 18:22:00 CM0 login: stat('/etc/mgetty/login.config') failed: No
such file or directory
02/17 18:22:00 CM0 login: fall back to /bin/login
02/17 18:22:00 CM0 calling login: cmd='/bin/login', argv[]='login
vyatta'
02/17 18:22:00 CM0 setenv: 'CALLER_ID=none'
02/17 18:22:00 CM0 setenv: 'CONNECT=115200'
02/17 18:22:00 CM0 setenv: 'DEVICE=ttyACM0'
02/17 18:22:00 # data dev=ttyACM0, pid=19074, caller='none',
conn='115200', name='', cmd='/bin/login', user='vyatta'
But the problem systems never get to the tio_get_rs232_lines:
[..]
I'm doing the dialing from minicom, And I've tried using the mgetty
version from the older systems on the new systems, but that seemed to
make no difference. I've also tried replacing the login deb with the one
from the older systems, but that also does not seem to make any
difference.
This hints more at problems with the USB tty drivers.
As in if an application does stupid things like 'query serial lines
status' then just hang, instead of returning useful information -
otherwise there would be something in the mgetty log.
Is debian using a modified kernel, or bog standard Linus distribution
kernel? You might want to try an off the shelf kernel...
Well, there is no real standard kernel. I would also recommend to
try a few different linux kernel versions (also older ones from
Debian).
I copied the debian kernel mailinglist, perhaps there's some good
input from there.
Cheers,
Andi
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#390724: Ooops on Xen reboot
* Moritz Muehlenhoff (j...@inutil.org) [081229 16:12]: On Mon, Oct 02, 2006 at 08:07:34PM +0200, Andreas Barth wrote: Package: linux-image-2.6.18-1-xen-amd64 Version: 2.6.18-2 Hi, on rebooting my Xen dom0, I got this error message. Does this error occur reproducibly with current Etch Xen kernels? I had all strange kinds of errors and oops with xen, but none is reproducible. Sorry. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#390724: Ooops on Xen reboot
* Moritz Muehlenhoff (j...@inutil.org) [081229 20:42]: On Mon, Dec 29, 2008 at 08:32:42PM +0100, Andreas Barth wrote: * Moritz Muehlenhoff (j...@inutil.org) [081229 16:12]: On Mon, Oct 02, 2006 at 08:07:34PM +0200, Andreas Barth wrote: Package: linux-image-2.6.18-1-xen-amd64 Version: 2.6.18-2 Hi, on rebooting my Xen dom0, I got this error message. Does this error occur reproducibly with current Etch Xen kernels? I had all strange kinds of errors and oops with xen, but none is reproducible. Sorry. So this is something that happened once and never again or does it happen occasionally, but only not reproducibly? I cannot remember of having seen this oops again - and the bug report is now more than 2 years old, so sorry if details disappeared. Cheers, Andi -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507994: Please include version 1.6 of hso.c
* Bastian Blank ([EMAIL PROTECTED]) [081206 20:20]: tags 507994 moreinfo thanks On Sat, Dec 06, 2008 at 07:12:29PM +0100, Andreas Barth wrote: (speaking as user of Debian only) please include the attached version of hso.c in the linux kernel. No. There is no sign that this version includes any changes done during the review by the Linux community before accepting this driver into the tree. Also the differences does not qualify at all for inclusion. Please specify a version from the Linux tree and if necessary the patches. Well, I'm sorry to say that it just works for me, while the 1.2-version doesn't. But if you don't want, we can wait till it gets included upstream (sooner or later it will), and then you can be happy. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.22-4
* Sven Luther ([EMAIL PROTECTED]) [070830 06:16]: I would like to know if this upload would include the efika patches that where included in the subversion repository after the 2.6.22-3 upload, or if you will silently disable them, after you kicked me out of the debian-kernel team without reasonable justification or even trying to speak to me. Sorry for following up so late on this bug report. I just asked on IRC: 16:25 aba can someone comment on http://bugs.debian.org/439006 16:25 aba (Efika and sony PS3 patches in linux-2.6) 16:49 waldi aba: both efika and ps3 support is maintained in the linus tree since a long time. so it is possible to fix serious problems with the linux upstream stable updates and don't need to duplicate the work. ps3 support was enabled by me for 2.6.26, so sven tried to fix not enabled things 16:49 aba waldi: so, are the issues reported there now already resolved? or are they not relevant anymore? or ...? 16:50 waldi sven did not further try to push massive patch sets, which was just about to be submitted to the ppc maintainer, for inclusion into linux-2.6 16:51 waldi the support is upstream and from what I know working, so: not relevant anymore Is this correct? If so, I would like to close this bug report now. Sorry for the late response. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
* Pierre Habouzit ([EMAIL PROTECTED]) [080707 19:48]: Changing kernel at this point of the release would be too destructive, so unless there is a big fat problem in the .25 that the .26 should fix and is unbackportable (does such a beast even exist ?) I'm rather opposed to it. Note that the asm/page.h mess is still not fixed thanks to hppa. Disclaimer: it's my own opinion, I did not check what other Release Team member think about this. I agree with you, at least with my current informations. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481945: chipset doesn't support ide-sata-devices (but only in ahci mode)
, Inc. VT8251 PCIE Root Port [1106:287d] Flags: bus master, fast devsel, latency 0 Bus: primary=80, secondary=81, subordinate=81, sec-latency=0 Capabilities: [40] Express Root Port (Slot-), MSI 00 Capabilities: [68] Power Management version 2 Capabilities: [70] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable+ Capabilities: [88] HyperTransport: MSI Mapping Enable- Fixed+ Capabilities: [90] Subsystem: Device [0004:] Kernel driver in use: pcieport-driver Kernel modules: shpchp 80:01.0 Audio device [0403]: VIA Technologies, Inc. VIA High Definition Audio Controller [1106:3288] Subsystem: VIA Technologies, Inc. VIA High Definition Audio Controller [1106:3288] Flags: bus master, fast devsel, latency 0, IRQ 22 Memory at febfc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Please feel free to close this bug report if you don't consider it too important. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.24-5
* dann frazier ([EMAIL PROTECTED]) [080325 00:41]: On Mon, Mar 24, 2008 at 11:25:08PM +0100, Bastian Blank wrote: On Mon, Mar 17, 2008 at 11:42:47AM +0100, Bastian Blank wrote: I intend to upload linux-2.6 2.6.24-5 tomorrow. It got rescheduled to tomorrow, 25.3. Thanks for the update Bastian. Note that aba asked for a postponement on IRC: aba dannf: I *assume* we'll have a testing migration soon, so please delay sid uploads until that happened ... I don't know if the RC-bug reduction changes that at all (specifically #469058, and the arguably RC #463669). If you think we should rather make an upload *instead* of getting the current kernel into testing, please say so. Otherwise, I assume the current unstable kernel will migrate with one of the next testing migration runs (and if that happend, I'll drop a note on irc). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer Lenny Beta1: Status Update 4
* Otavio Salvador ([EMAIL PROTECTED]) [080313 02:36]: Otavio Salvador [EMAIL PROTECTED] writes: +--+---+ | Date | What happens | +--+---+ |March 8, 2008 |test of images starts | = +--+---+ |March 12, 2008|final image builds | +--+---+ |March 16, 2008|planned release date | +--+---+ Currently we're trying to get final images built but the building machine has hardware issues and it's being worked on to get it solves as soon as possible. I'll mail you all once it has been solved and images are available for final tests. Is there any update on this? As of now, the final images should be available according to your plan ... (I'm asking because the blocks for packages generate us pain elsewhere - e.g. openssh needs to go to testing for armel, libxklavier-transition depends on glib2.0 and pango, ...) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444961: starting a domU kills the system
Package: linux-image-2.6.18-5-xen-amd64 Version: 2.6.18.dfsg.1-13etch2 Severity: critical Hi, after starting a domU with linux-image-2.6.18-xen-3.1-1-amd64, version 2.6.18.dfsg.1-15+xen.1 (from http://194.39.182.225/debian/linux-2.6/xen-extra/ as told by waldi), the host system and all domUs suddenly stop with this error: Oct 2 01:42:23 urd kernel: --- [cut here ] - [please bite here ] - Oct 2 01:42:23 urd kernel: CPU 1 Oct 2 01:42:23 urd kernel: Modules linked in: xt_physdev xfs iptable_filter ip_tables x_tables ipv6 bridge loop floppy shpchp pci_hotplug serial _core pcspkr serio_raw psmouse i2c_nforce2 i2c_core evdev joydev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod raid456 xor raid1 md_mod ide_gener ic ide_cd cdrom sd_mod usb_storage usbhid sata_nv libata scsi_mod e1000 amd74xx forcedeth ohci_hcd generic ide_core ehci_hcd fan Oct 2 01:42:23 urd kernel: Pid: 21, comm: xenwatch Not tainted 2.6.18-5-xen-amd64 #1 Oct 2 01:42:23 urd kernel: RIP: e030:[80360ee3] [80360ee3] retrigger+0x26/0x3e Oct 2 01:42:23 urd kernel: RSP: e02b:8800f2917d88 EFLAGS: 00010046 Oct 2 01:42:23 urd kernel: RAX: RBX: 8980 RCX: ff578000 Oct 2 01:42:23 urd kernel: RDX: 0024 RSI: 8800f2917d30 RDI: 0113 Oct 2 01:42:23 urd kernel: RBP: 804cde00 R08: 8800f284cbf0 R09: 88000a36fd00 Oct 2 01:42:23 urd kernel: R10: 88000a36f800 R11: 80360ebd R12: 0113 Oct 2 01:42:23 urd kernel: R13: 804cde3c R14: R15: 0008 Oct 2 01:42:23 urd kernel: FS: 2b6951249ae0() GS:804c4080() knlGS: Oct 2 01:42:23 urd kernel: CS: e033 DS: ES: Oct 2 01:42:23 urd kernel: Process xenwatch (pid: 21, threadinfo 8800f2916000, task 8800f28f5080) Oct 2 01:42:23 urd kernel: Stack: 802a0646 88000a36fd00 88000a36fd00 Oct 2 01:42:23 urd kernel: 8800f2917de0 020b 8036da4e Oct 2 01:42:23 urd kernel: 8036dec6 8800f2917ea4 Oct 2 01:42:23 urd kernel: Call Trace: Oct 2 01:42:23 urd kernel: [802a0646] enable_irq+0x9d/0xbc Oct 2 01:42:23 urd kernel: [8036da4e] __netif_up+0xc/0x15 Oct 2 01:42:23 urd kernel: [8036dec6] netif_map+0x2a6/0x2d8 Oct 2 01:42:23 urd kernel: [8035c227] bus_for_each_dev+0x61/0x6e Oct 2 01:42:23 urd kernel: [803666d0] xenwatch_thread+0x0/0x145 Oct 2 01:42:23 urd kernel: [803666d0] xenwatch_thread+0x0/0x145 Oct 2 01:42:23 urd kernel: [80368210] frontend_changed+0x2ba/0x4f9 Oct 2 01:42:23 urd kernel: [803666d0] xenwatch_thread+0x0/0x145 Oct 2 01:42:23 urd kernel: [8028f837] keventd_create_kthread+0x0/0x61 Oct 2 01:42:23 urd kernel: [80365ade] xenwatch_handle_callback+0x15/0x48 Oct 2 01:42:23 urd kernel: [803667fd] xenwatch_thread+0x12d/0x145 Oct 2 01:42:23 urd kernel: [8028f9fa] autoremove_wake_function+0x0/0x2e Oct 2 01:42:23 urd kernel: [8028f837] keventd_create_kthread+0x0/0x61 Oct 2 01:42:23 urd kernel: [803666d0] xenwatch_thread+0x0/0x145 Oct 2 01:42:23 urd kernel: [802334da] kthread+0xd4/0x107 Oct 2 01:42:23 urd kernel: [8025c7d8] child_rip+0xa/0x12 Oct 2 01:42:23 urd kernel: [8028f837] keventd_create_kthread+0x0/0x61 Oct 2 01:42:23 urd kernel: [80233406] kthread+0x0/0x107 Oct 2 01:42:23 urd kernel: [8025c7ce] child_rip+0x0/0x12 The host (and all domUs) run etch, with the only exception being the newer kernel. Setting this bug report to critical as crashing the whole machine by starting a new guest sounds to me like an exploitable issue in the xen handlers. (This could of course be wrong, so feel free to adjust the severity.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sparc and testing migration
Hi, as you all are probably aware, we currently have some quite bad issues with the sparc buildds for some times, especially http://bugs.debian.org/433187 unkillable processes on the buildds. More and more packages which are ready for testing migration otherwise can't go in because of out-of-date-packages on sparc (including missing binNMUs). In past, we have decided on a case-by-case-basis to ignore such issues, or even force packages in which break other packages only on sparc. As the situation is now, we decided to make our lives easier, and always allow such packages to migrate to testing by hand if the only issue is on sparc, and the package transition is otherwise useful (i.e. fixing RC bugs, finishing a transition etc). This is not equivalent (yet) to ignore sparc in testing migration by scripts, but also not a healty sign for this architecture. I hope that the mentioned RC bug can be fixed soon - if so, we're happy to stop ignoring issues on sparc (or rather: we probably will find us in the situation that such cases cease to exist). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
* Bastian Blank ([EMAIL PROTECTED]) [070726 11:40]: For the libata-pata support we need to change fstab on several arches to not break all systems which uses them. We need to decide which arches needs this rewrite now and which value should be filed in. I'd like to ask you to postpone such changes until we split the etch+.5-kernel off (because we don't want to change the fstab on the new kernel, but on the upgrade from etch to lenny). (And, BTW, I don't think this is a kernel-only topic, so setting Cc accordingly). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.21-6
* Bastian Blank ([EMAIL PROTECTED]) [070708 17:50]: I'd like to schedule 2.6.21-6 for tuesday. It only contains a security fix. Dann: Is there a CVE for the nf_conntrack_h323? I'd ask you to wait until linux-2.6 migrates to testing (which will hopefully be tonight, but one knows for sure only after the fact, even in cases where lots of handholding is applied to). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
* Sven Luther ([EMAIL PROTECTED]) [070528 12:14]: On Mon, May 28, 2007 at 11:17:39AM +0200, Bastian Blank wrote: On Mon, May 28, 2007 at 08:38:24AM +0200, Joey Schulze wrote: I can understand the latter. However, maybe it was just a mistake and waldi didn't want to remove Sven but accidently removed one line too much or something? He'll probably speak up and explain things. I already said that I can't remember. I know there was something about dilinger and wli but not more. Fine, so can you reactivate my access ? It seems that waldi doesn't want to do it, and also not to give any statement that he wanted to kick you out. I consider this a very bad behaviour, at least. And not acceptable. We had just an IRC-discussion (in German): 12:15 Ganneff waldi: wie siehts aus mit svenl wieder zum alioth kernel zuzufügen nachdem er da wohl ungeplant flog? 12:15 waldi Ganneff: es hat eigentlich keiner lust sich mit ihm abzugeben. ein teil ignoriert ihn komplett 12:15 aba waldi: *du* hast ihn entfernt. Dann bist Du auch fürs aufräumen zuständig. 12:16 Ganneff waldi: dann schreib ihm entweder sowas als entscheidung vom kernel team wenns die gibt oder füg ihn wieder zu. aber ignorieren ist nix gut. 12:16 aba waldi: entweder sagst du offiziell, das du ihn draußen haben willst. Oder du fügst ihn wieder hinzu. 12:17 Ganneff waldi: und es heisst svn zufügen, das muss nit unbedingt wieder admin sein. solang er dran arbeiten kann - oder alternativ halt weiss dass es nix wird weil $grund. 12:21 Ganneff waldi: so? 12:27 Ganneff waldi: im moment siehts eher so aus dass du deinen access zu kernel (zumindest admin) verlieren solltest, nicht sven. (and no answer from waldi up to now) As you can see, there is no need for you to escalate it - other people will take care of that. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
* Andreas Barth ([EMAIL PROTECTED]) [070528 12:28]: It seems that waldi doesn't want to do it, and also not to give any statement that he wanted to kick you out. I consider this a very bad behaviour, at least. And not acceptable. After some more pressure on IRC, your commit access has been restored. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another level of agression ?
* Sven Luther ([EMAIL PROTECTED]) [070528 13:23]: [...] Sven, this whole thread is about that your commit access to the kernel svn repro was revoked without anyone telling you. What then happened is that the alioth admins published that waldi revoked the access, waldi refused to comment to it, and was finally beaten by Ganneff and me to reenable your access. So, you see, two people jumped up to help you to get your access back, and were successful. I can understand that you are annoyed/angry at waldi now, but please consider that some people in Debian did efforts to help you to have your access restored. (And BTW, I still think that waldi needs to send a public apology for removing your access - as far as I can see it, it really seems to me waldi shouldn't have admin access because his behaviour is not how any admin should behave. But please stop muddling everything together. Debian as a project is definitly not responsible for waldis bad behaviour - and there is no correlation between waldis bad behaviour and anything else, waldi is behaving bad to almost all and not only to you.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418339: initramfs-tools: dist-upgrade runs update-initramfs twice, once for udev, and once for initramfs-tools
* Sven Luther ([EMAIL PROTECTED]) [070409 09:34]: This is a less than ideal situation, especially given how long the initramfs-tools ramdisk generation takes, and it would be better if in some way there could be a detection that it will have to run multiple times, and the upgrade be queued for running once only at the end of install. Use the dpkg triggers feature, which is currently in development. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing 2.6.18.dfsg.1-13
* Bastian Blank ([EMAIL PROTECTED]) [070409 16:48]: You want to use the -XetchY namespace for security builds and the -X for p-u uploads? The first is no problem, but the later is if we don't update linux-2.6 in testing ASAP. Well, don't you plan to upload linux-2.6 soon anyways? :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
* Steve Langasek ([EMAIL PROTECTED]) [070331 12:59]: On Sat, Mar 31, 2007 at 01:29:04AM +0200, Christoph Anton Mitterer wrote: I would say (although I'm by any means not kernel expert) that your patch looks good and I _strongly_ recommend to include it in etch r0 (!!)... You're the release manager,... so you should get managed this :-) It wouldn't be appropriate for me to push this without the consent of the rest of the kernel team just because I'm the release manager; I'm not even an amd64 porter, this should be signed off on by the folks who are actually responsible for the amd64 kernel first. But regardless, there are no plans for another kernel update before etch r0, and including one is likely to delay the release. I'm of the opinion that this bug does not justify a delay at this point. With the consent of the kernel team and the stable release managers, I'm happy to commit this patch to the queue for the next kernel update though, so it can be included in etch r1. BTW, we intended to have frequent kernel uploads to proposed-updates, and frankly speaking, I personally don't mind to already have a newer kernel in proposed-updates during the release, but that's something I want to have signed-off by Martin. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404148: kernel: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping
* Sven Luther ([EMAIL PROTECTED]) [070331 16:03]: The ideal would have been a framework where we could build new kernels and have it integrated within a few days only. I gave a speach about this at FOSDEM, of how we could use the initramfs incremental nature, to separate fully the kernel module .udebs from the rest of d-i, and have actual d-i images which are daily built, and usable independently of the kernel used. Sven, sorry but this doesn't have anything to do with the installer now. But that we refrain from making new uploads of the kernel less than a week prior to release - for the simple reason the kernel *is* a central component. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
* Andreas Barth ([EMAIL PROTECTED]) [070114 00:37]:
-Depends: linux-patch-debian-2.6.18 (= 2.6.18-8), linux-source-2.6.18 (=
2.6.18-1) | linux-source-2.6.18 (= 2.6.18-2) | linux-source-2.6.18 (=
2.6.18-3) | linux-source-2.6.18 (= 2.6.18-4) | linux-source-2.6.18 (=
2.6.18-5) | linux-source-2.6.18 (= 2.6.18-6) | linux-source-2.6.18 (=
2.6.18-7) | linux-source-2.6.18 (= 2.6.18-8)
+Depends: linux-patch-debian-2.6.18 (= 2.6.18-9), linux-source-2.6.18 (=
2.6.18-1) | linux-source-2.6.18 (= 2.6.18-2) | linux-source-2.6.18 (=
2.6.18-3) | linux-source-2.6.18 (= 2.6.18-4) | linux-source-2.6.18 (=
2.6.18-5) | linux-source-2.6.18 (= 2.6.18-6) | linux-source-2.6.18 (=
2.6.18-7) | linux-source-2.6.18 (= 2.6.18-8) | linux-source-2.6.18 (=
2.6.18-9)
This dependency-line was broken, so I fixed the patch. The
template-change is as before.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
diff -ur ../linux-2.6-2.6.18/debian/bin/gencontrol.py debian/bin/gencontrol.py
--- ../linux-2.6-2.6.18/debian/bin/gencontrol.py2007-01-13
23:29:32.0 +
+++ debian/bin/gencontrol.py2007-01-14 12:50:23.0 +
@@ -228,6 +228,12 @@
def process_changelog(self):
self.version = self.changelog[0]['Version']
+ if self.version['upstream'] == '2.6.18-dfsg':
+ self.version['upstream'] = '2.6.18'
+ self.version['linux']['upstream'] = '2.6.18'
+ self.version['linux']['source_upstream'] = '2.6.18'
+ self.version['linux']['modifier'] = None
+ self.version['linux']['source'] =
self.version['upstream']+'-'+self.version['debian']
if self.version['linux']['modifier'] is not None:
self.abiname = ''
else:
@@ -251,17 +257,20 @@
entry = self.process_package(in_entry, vars)
tmp = self.changelog[0]['Version']['linux']['upstream']
versions = []
for i in self.changelog:
if i['Version']['linux']['upstream'] != tmp:
break
versions.insert(0, i['Version']['linux'])
+versionsextra = [{u'major': '2.6', u'parent': None, u'source':
'2.6.18-1', u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream':
'2.6.18', u'modifier': None, u'debian': '1'}, {u'major': '2.6', u'parent':
None, u'source': '2.6.18-2', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '2'}, {u'major': '2.6',
u'parent': None, u'source': '2.6.18-3', u'version': '2.6.18',
'source_upstream': '2.6.18', u'upstream': '2.6.18', u'modifier': None,
u'debian': '3'}, {u'major': '2.6', u'parent': None, u'source': '2.6.18-4',
u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream': '2.6.18',
u'modifier': None, u'debian': '4'}, {u'major': '2.6', u'parent': None,
u'source': '2.6.18-5', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '5'}, {u'major': '2.6',
u'parent': None, u'source': '2.6.18-6', u'version': '2.6.18',
'source_upstream': '2.6.18', u'upstream': '2.6.18', u'modifier': None,
u'debian': '6'}, {u'major': '2.6', u'parent': None, u'source': '2.6.18-7',
u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream': '2.6.18',
u'modifier': None, u'debian': '7'}, {u'major': '2.6', u'parent': None,
u'source': '2.6.18-8', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '8'}]
for i in (('Depends', 'Provides')):
value = package_relation_list()
value.extend(entry.get(i, []))
if i == 'Depends':
value.append(linux-patch-debian-%(version)s (= %(source)s) %
self.changelog[0]['Version']['linux'])
-value.append(' | '.join([linux-source-%(version)s (=
%(source)s) % v for v in versions]))
+value.append(' | '.join([linux-source-%(version)s (=
%(source)s) % v for v in versionsextra]))
+value.append(' | '.join([linux-source-%(version)s (=
%(upstream)s-dfsg-%(debian)s) % v for v in versions]))
elif i == 'Provides':
+value.extend([linux-tree-%s % v['source'].replace('~', '-')
for v in versionsextra])
value.extend([linux-tree-%s % v['source'].replace('~', '-')
for v in versions])
entry[i] = value
return entry
diff -ur ../linux-2.6-2.6.18/debian/control debian/control
--- ../linux-2.6-2.6.18/debian/control 2007-01-13 23:29:33.0 +
+++ debian/control 2007-01-14 12:50:26.0 +
@@ -68,15 +68,15 @@
This package includes the patches used to produce the prepackaged
linux-source-2.6.18 package, as well as architecture-specific patches.
Note that these patches do NOT apply against a pristine Linux 2.6.18
- kernel but only against the kernel tarball linux-2.6_2.6.18.orig.tar.gz
- from the Debian archive.
+ kernel but only against the kernel tarball
+ linux-2.6_2.6.18-dfsg.orig.tar.gz from
Re: Solving the linux-2.6 firmware issue
Hi, thanks for the patch. One small issue: * Bastian Blank ([EMAIL PROTECTED]) [070114 16:14]: --- debian/changelog (revision 3362) +++ debian/changelog (local) @@ -1,4 +1,4 @@ -linux-2.6 (2.6.18-9) UNRELEASED; urgency=low +linux-2.6 (2.6.18.dfsg.1-9) UNRELEASED; urgency=low The standard is normally version+dfsg, so you might consider the same in your case. This would of course require an change --- debian/lib/python/debian_linux/debian.py (revision 3362) +++ debian/lib/python/debian_linux/debian.py (local) @@ -85,6 +80,9 @@ ) )? ) +(?: +\.dfsg\.\d+ here as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
* Bastian Blank ([EMAIL PROTECTED]) [070114 15:21]: On Sun, Jan 14, 2007 at 12:36:37AM +0100, Andreas Barth wrote: Actually, there is another way to do it - hardcode to -dfsg for now, so this is a change that needs to be reverted at the beginning of the Lenny cycle. But I think it is still better then the other one, and I don't think it hurts for Etch to hardcode a few bits now. This fix and the prefered patch (attached) needs testing to make sure the following things works fine: - linux-patch-debian-*/linux-tree-* - linux-modules-* What do you mean with this? The second I guess that linux-modules-* still build correctly? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
* Florian Weimer ([EMAIL PROTECTED]) [070108 12:21]: * Bastian Blank: Not possible without another large round of testing. Our infrastracture currently expects that the upstream part of the version remains the same through the whole cycle. This information is for example used to find all patches. Uhm, why can't you do a simple full upload just once, manually? AFAICS this was the last mail on the topic why don't we finally upload the kernel with the changed ABI. Any real blockers, or what needs to happen? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solving the linux-2.6 firmware issue
* Andreas Barth ([EMAIL PROTECTED]) [070113 14:28]:
* Andreas Barth ([EMAIL PROTECTED]) [070113 10:33]:
* Florian Weimer ([EMAIL PROTECTED]) [070108 12:21]:
* Bastian Blank:
Not possible without another large round of testing. Our infrastracture
currently expects that the upstream part of the version remains
the same through the whole cycle. This information is for example used
to find all patches.
Uhm, why can't you do a simple full upload just once, manually?
AFAICS this was the last mail on the topic why don't we finally upload
the kernel with the changed ABI. Any real blockers, or what needs to
happen?
So, I checked the infrastructure now.
A kernel version of 2.6.18-dfsg-1 works fairly well. There are only two
packages who build-depend on the then-removed linux-tree-2.6.18,
fai-kernels and modconf, and no package directly depends on it.
The only change I did was this patch:
Actually, there is another way to do it - hardcode to -dfsg for now, so
this is a change that needs to be reverted at the beginning of the Lenny
cycle. But I think it is still better then the other one, and I don't
think it hurts for Etch to hardcode a few bits now.
Please see the attachement for what changes (first two files are the
productive changes, and the third one is how this changes
debian/control). In the relevant changelog, I named the next version
2.6.18-dfsg-9.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
diff -Nur ../linux-2.6-2.6.18/debian/bin/gencontrol.py debian/bin/gencontrol.py
--- ../linux-2.6-2.6.18/debian/bin/gencontrol.py2007-01-13
23:29:32.0 +
+++ debian/bin/gencontrol.py2007-01-13 23:30:27.0 +
@@ -228,6 +228,12 @@
def process_changelog(self):
self.version = self.changelog[0]['Version']
+ if self.version['upstream'] == '2.6.18-dfsg':
+ self.version['upstream'] = '2.6.18'
+ self.version['linux']['upstream'] = '2.6.18'
+ self.version['linux']['source_upstream'] = '2.6.18'
+ self.version['linux']['modifier'] = None
+ self.version['linux']['source'] =
self.version['upstream']+'-'+self.version['debian']
if self.version['linux']['modifier'] is not None:
self.abiname = ''
else:
@@ -251,10 +257,11 @@
entry = self.process_package(in_entry, vars)
tmp = self.changelog[0]['Version']['linux']['upstream']
versions = []
for i in self.changelog:
if i['Version']['linux']['upstream'] != tmp:
break
versions.insert(0, i['Version']['linux'])
+versions = [{u'major': '2.6', u'parent': None, u'source': '2.6.18-1',
u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream': '2.6.18',
u'modifier': None, u'debian': '1'}, {u'major': '2.6', u'parent': None,
u'source': '2.6.18-2', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '2'}, {u'major': '2.6',
u'parent': None, u'source': '2.6.18-3', u'version': '2.6.18',
'source_upstream': '2.6.18', u'upstream': '2.6.18', u'modifier': None,
u'debian': '3'}, {u'major': '2.6', u'parent': None, u'source': '2.6.18-4',
u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream': '2.6.18',
u'modifier': None, u'debian': '4'}, {u'major': '2.6', u'parent': None,
u'source': '2.6.18-5', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '5'}, {u'major': '2.6',
u'parent': None, u'source': '2.6.18-6', u'version': '2.6.18',
'source_upstream': '2.6.18', u'upstream': '2.6.18', u'modifier': None,
u'debian': '6'}, {u'major': '2.6', u'parent': None, u'source': '2.6.18-7',
u'version': '2.6.18', 'source_upstream': '2.6.18', u'upstream': '2.6.18',
u'modifier': None, u'debian': '7'}, {u'major': '2.6', u'parent': None,
u'source': '2.6.18-8', u'version': '2.6.18', 'source_upstream': '2.6.18',
u'upstream': '2.6.18', u'modifier': None, u'debian': '8'}] + versions
for i in (('Depends', 'Provides')):
value = package_relation_list()
value.extend(entry.get(i, []))
diff -Nur ../linux-2.6-2.6.18/debian/templates/control.main.in
debian/templates/control.main.in
--- ../linux-2.6-2.6.18/debian/templates/control.main.in2007-01-13
12:59:35.0 +
+++ debian/templates/control.main.in2007-01-13 23:31:15.0 +
@@ -61,4 +61,4 @@
[EMAIL PROTECTED]@ package, as well as architecture-specific
patches. Note that these patches do NOT apply against a pristine
Linux @version@ kernel but only against the kernel tarball
- [EMAIL PROTECTED]@[EMAIL PROTECTED]@.orig.tar.gz from the Debian archive.
+ [EMAIL PROTECTED]@[EMAIL PROTECTED]@-dfsg.orig.tar.gz from the Debian archive.
diff -Nur ../linux-2.6-2.6.18/debian/control debian/control
--- ../linux-2.6-2.6.18/debian/control 2007-01-13 23:29:33.0 +
+++ debian/control 2007-01-13 23:31
Re: Solving the linux-2.6 firmware issue
* Frederik Schueler ([EMAIL PROTECTED]) [070106 23:45]: 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. AFAICS, nobody would object if someone would start to work on these issues. But, unless somebody actually deals with these, I don't think there is any alternative to the purging proposed by Frederik. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
* Sven Luther ([EMAIL PROTECTED]) [061222 05:42]: On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: maximilian attems [EMAIL PROTECTED] writes: On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: Fix it or document it, I don't care. But the current state is not releasable. we are not talking about a patch. what you need is an backport of the 2.6.19 acpi release to 2.6.18. Read again what I wrote. I will not allow Debian to release with a Kernel that may damage hardware without even a notice in the release notes. If you are not able to fix it, note that you have provided a broken kernel. Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 kernel, to solve this issue. Sven, stop this! I can remember well how you promised that moving to 2.6.18 will magically solve almost all of our issues - 6 (or more) release critical bugs against 2.6.18 don't show that this has worked so well. Please try helping us on solutions rather then breaking things again. Please try to look at it from another perspective: Consider you have bought such a laptop, and you install Debian. You have even read the release notes first. Everything works well. Until one day you notice your laptop gets too warm, and eventually even breaks because of this. On deeper research, you notice that this issue was well-known to Debian, but they refused to deal with it at all. How would you feel as a user? I think this is an unacceptable perspective. Ok, what can we do? 1. ignore the problem, 2. document it in the release notes and README.Debian of the kernel, 3. prevent the kernel running on such buggy laptops [is this possible?], 4. backport ACPI from 2.6.19, or use 2.6.19, 5. isolate a smaller fix and apply it. I personally consider options 1 and 4 to be unacceptable. Option 5 would be the best, but I have yet to see that this is possible (or rather, someone knowledgeable enough has time to do it). So, we should at least document it inside of the release notes, and README.Debian, and, if possible without being to invasive, get some check inside the kernel to print a big warning on bootup, or even refuse to work until some special parameter is used. How does this proposal sound to the kernel team? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404143: Fans unreliable under load, permanent memory leak
severity 404143 critical thanks * Bastian Blank ([EMAIL PROTECTED]) [061222 01:27]: On Fri, Dec 22, 2006 at 01:51:36AM +0100, [EMAIL PROTECTED] wrote: Consequence: linux-image-2.6.18-3-amd63 (=2.6.18-7) is unsuitable for release. Failing for you don't makes it unsuitable. That is a true statement by itself. This bug however has the potential to damage hardware. Which is a critical bug. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398962: [2.6.18] Platform devices incorrectly provide $MODALIAS?
severity 398962 important
thanks
* Joey Hess ([EMAIL PROTECTED]) [061127 12:13]:
Frans Pop wrote:
He has suggested working around this by excluding loading drivers for
platform devices in udev. However, Sven Luther noted that e.g. the
Pegasos marvell gigabit ethernet port is a platform device for which the
driver should be loaded.
udev 0.103-1 works around the problem as follows:
# this driver is broken and should not be loaded automatically (see #398962)
SUBSYSTEM==platform, ENV{MODALIAS}==i82365, GOTO=hotplug_driver_loaded
So at least for the Pegasos marvell gigabit ethernet, the module will still
load. I don't know if it or other platform modules will still perhaps have
problems due to this bug.
Once the new udev reaches testing, I wouldn't consider this bug as RC
anymore, unless new problems come to light with other platform devices.
udev | udev |0.103-1 | testing | source, alpha, amd64,
arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
downgrading to important now.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242866: remainings are etch-ignore
tags 242866 + etch-ignore tags 243022 + etch-ignore tags 383403 + etch-ignore thanks Hi, AFAICS, all items needing clean up prior to etch are cleaned up now, so tagging these bug reports etch-ignore. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hint for autodir (closes RC) and comments about linux-kernel-headers
Hi, can we please have some comment on that from the kernel side? Cheers, Andi * Francesco P. Lovergine ([EMAIL PROTECTED]) [061211 12:18]: After about 20 days of work with both autodir and autofs4 upstream a final fix for autodir is available (closes #399454). Incidentally 0.9.8 is almost the same of 0.9.7 (integrating my previous fix for an header file and an initial trial to fix the above bug) at upstream level and we are quite confident it does not impact stability in respect with 0.9.7. Just in case I could provide a 1:0.9.7-1 if required (0.9.7 was the last available version in testing AFAIK). About the fix, as communicated in #debian-kernel, just FYI: frankie FYI: #399454 is essentially a bug in the auto_fs4.h header file, as resulted by talking with autofs and autodir upstreams (API breakage due to a change in a union used both in v4 and v5). The issue potentially impact any program built on 2.6.17+ and depending on auto_fs4.h. frankie any program which still uses v4 protocol, indeed frankie autofs upstream is fixing on his side for the kernel, but I wonder if we need to fix as well etch linux-kernel-headers frankie of course this is not a problem for debian binaries, but i think developers would not appreciate a broken header in etch for their buildings and the issue is quite obscure No answer :-( This is an issue at kernel headers level, but Ian Kent has not still provided a final fix for mainstream kernel. Incidentally not every program which uses auto_fs4.h and the kernel module is exposed to the breakage, and probably very few programs use autofs4. Maybe documenting all the issue (but where? linux-kernel-headers is probably the best choice) and providing the old auto_fs4.h is at this time the most reasonable thing to do. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
* Goswin von Brederlow ([EMAIL PROTECTED]) [061120 10:47]: Bastian Blank [EMAIL PROTECTED] wrote: On Sat, Nov 18, 2006 at 07:12:49AM +0100, Goswin von Brederlow wrote: The patch breaks crosscompilation and other things. | diff -u linux-2.6.16-2.6.16/debian/arch/i386/xen-vserver/defines linux-2.6.16-2.6.16/debian/arch/i386/xen-vserver/defines | --- linux-2.6.16-2.6.16/debian/arch/i386/xen-vserver/defines | +++ linux-2.6.16-2.6.16/debian/arch/i386/xen-vserver/defines | @@ -12 +12,9 @@ | +kernel-arch: i386 | | +[amd64] | +class: AMD64 / EM64T SMP | +longclass: 64bit multi-processor AMD Athlon64/Opteron / Intel EM64T models | +KPKG-ARCH: amd64 | +recommends: libc6-i686 | +kpkg-arch: amd64 kpkg always gets the debian arch of the system it compiles for. Overwriting this is not allowed. See also man make-kpkg: | The value should be whatever DEB_HOST_ARCH_CPU contains when | dpkg-architecture is run on the target machine, or it can be an other | architecture in a multi-arch set (like i386/amd64). Which is what we do here. Sounds sane. Anyway, leave the xen stuff disabled if that makes problems for you. As said in this bugreport before we probably don't need it. Good. | diff -u linux-2.6.16-2.6.16/debian/rules.real linux-2.6.16-2.6.16/debian/rules.real | --- linux-2.6.16-2.6.16/debian/rules.real | +++ linux-2.6.16-2.6.16/debian/rules.real | @@ -35,7 +35,11 @@ | # replaced by the flavour for which the command is run. | # | kpkg_image := make-kpkg | -kpkg_image += --arch '$(ARCH)' | +ifdef KPKG_ARCH | + kpkg_image += --arch '$(KPKG_ARCH)' --cross-compile='-' | +else | + kpkg_image += --arch '$(ARCH)' | +endif | kpkg_image += --stem linux | ifneq ($(INITRAMFS),False) |kpkg_image += --initrd No. The cross compilation stuff is set intern and must not be overwriten by the rules. Yes it must. We are building for a multi-arch set here and the synatx for that is to set the architecture but not to cross-compile. --cross-compile='-' does that. The man page tells: --cross-compile foo This is useful for setting the target string when you are cross compiling. Use the dummy target - if you are building for other arches of a multiarch set, like i386/amd64. The supports Goswins view. There is however one negative side-effect: You cannot crosscompile i386-kernel-package anymore. It might be better to set --cross-compile to the right value for i386 - but that shouldn't block application of this patch. Goswin, I expect you actually tested this patch on an i386, and it returned proper kernels (i.e. you tried at least one of them). If so, I think this patch is now in a state where it can be applied. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400220: Close
* Steve Langasek ([EMAIL PROTECTED]) [061201 16:36]: No, it isn't. The latest upload still build-depends on squashfs-source and unionfs-source, and these packages are still not available in testing. Now, both packages more or less only wait for ftp-team's cleanup for testing transition. And l-m-e-2.6 is still failing to build on arm because of the ICE in squashfs. This has now also been fixed, but the package is waiting in NEW now. So, things move in the right direction now. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400220: Close
* Andreas Barth ([EMAIL PROTECTED]) [061206 11:28]: * Steve Langasek ([EMAIL PROTECTED]) [061201 16:36]: And l-m-e-2.6 is still failing to build on arm because of the ICE in squashfs. That has been moved to hppa now :( /build/buildd/linux-modules-extra-2.6-2.6.18/debian/build/build_hppa_none_parisc_squashfs/linux-2.6/inode.c: In function 'get_cached_fragment': /build/buildd/linux-modules-extra-2.6-2.6.18/debian/build/build_hppa_none_parisc_squashfs/linux-2.6/inode.c:516: fatal error: internal consistency failure compilation terminated. Preprocessed source stored into /tmp/ccRW6WgF.out file, please attach this to your bugreport. make[4]: *** [/build/buildd/linux-modules-extra-2.6-2.6.18/debian/build/build_hppa_none_parisc_squashfs/linux-2.6/inode.o] Error 1 make[3]: *** [_module_/build/buildd/linux-modules-extra-2.6-2.6.18/debian/build/build_hppa_none_parisc_squashfs/linux-2.6] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.18-3-parisc' make[2]: *** [debian/stamps/build_hppa_none_parisc_squashfs] Error 2 make[2]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.18' make[1]: *** [build-hppa-none-parisc-squashfs] Error 2 make[1]: Leaving directory `/build/buildd/linux-modules-extra-2.6-2.6.18' make: *** [debian/stamps/build-base] Error 2 Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.19, kernel-package problems and what are our plans for etch ...
* Sven Luther ([EMAIL PROTECTED]) [061201 20:30]: - What is stopping 2.6.18 to enter testing ? The PTS says Should ignore, but forced by vorlon, so does this mean it will enter testing today ? What about the remaining (or new) RC bugs ? Some of them being open against 2.6.17, so also present in testing. If one of the release managers uses the force-hint, nothing from the first stage (RC-bugs, date, out-of-date, ...) will block the testing migration anymore. However, in the second stage, installability is checked. According to todays output, these packages are broken by the transition: trying: linux-2.6 skipped: linux-2.6 (15 - 32) got: 115+0: i-115 * i386: kernel-image-2.6-386, kernel-image-2.6-686, kernel-image-2.6-686-smp, kernel-image-2.6-k7, kernel-image-2.6-k7-smp, linux-headers-2.6-486, linux-headers-2.6-686, linux-headers-2.6-686-bigmem, linux-headers-2.6-k7, linux-headers-2.6-vserver-686, linux-headers-2.6-vserver-k7, linux-headers-2.6-xen-686, linux-headers-2.6-xen-k7, linux-headers-2.6.18-3-486, linux-headers-2.6.18-3-686, linux-headers-2.6.18-3-686-bigmem, linux-headers-2.6.18-3-all, linux-headers-2.6.18-3-all-i386, linux-headers-2.6.18-3-k7, linux-headers-2.6.18-3-vserver-686, linux-headers-2.6.18-3-vserver-k7, linux-headers-2.6.18-3-xen-686, linux-headers-2.6.18-3-xen-k7, linux-headers-2.6.18-3-xen-vserver-686, linux-image-2.6-486, linux-image-2.6-686, linux-image-2.6-686-bigmem, linux-image-2.6-686-smp, linux-image-2.6-k7, linux-image-2.6-k7-smp, linux-image-2.6-vserver-686, linux-image-2.6-vserver-k7, linux-image-2.6-xen-686, linux-image-2.6-xen-k7, linux-image-486, linux-image-686, linux-image-686-bigmem, linux-image-k7, linux-image-vserver-686, linux-image-vserver-k7, linux-image-xen-686, linux-image-xen-k7, loop-aes-2.6-486, loop-aes-2.6-686, loop-aes-2.6-686-bigmem, loop-aes-2.6-k7, loop-aes-2.6-vserver-686, loop-aes-2.6-vserver-k7, loop-aes-2.6.17-2-486, loop-aes-2.6.17-2-686, loop-aes-2.6.17-2-686-bigmem, loop-aes-2.6.17-2-k7, loop-aes-2.6.17-2-vserver-686, loop-aes-2.6.17-2-vserver-k7, nvidia-kernel-legacy-2.6-486, nvidia-kernel-legacy-2.6-686, nvidia-kernel-legacy-2.6-686-smp, nvidia-kernel-legacy-2.6-k7, nvidia-kernel-legacy-2.6-k7-smp, redhat-cluster-modules-2.6-486, redhat-cluster-modules-2.6-686, redhat-cluster-modules-2.6-686-bigmem, redhat-cluster-modules-2.6-k7, redhat-cluster-modules-2.6-vserver-686, redhat-cluster-modules-2.6-vserver-k7, redhat-cluster-modules-2.6-xen-686, redhat-cluster-modules-2.6-xen-k7, redhat-cluster-modules-2.6.17-2-486, redhat-cluster-modules-2.6.17-2-686, redhat-cluster-modules-2.6.17-2-686-bigmem, redhat-cluster-modules-2.6.17-2-k7, redhat-cluster-modules-2.6.17-2-vserver-686, redhat-cluster-modules-2.6.17-2-vserver-k7, redhat-cluster-modules-2.6.17-2-xen-686, redhat-cluster-modules-2.6.17-2-xen-k7, spca5xx-modules-2.6-486, spca5xx-modules-2.6-686, spca5xx-modules-2.6-686-bigmem, spca5xx-modules-2.6-k7, spca5xx-modules-2.6-vserver-686, spca5xx-modules-2.6-vserver-k7, spca5xx-modules-2.6-xen-686, spca5xx-modules-2.6-xen-k7, spca5xx-modules-2.6.17-2-486, spca5xx-modules-2.6.17-2-686, spca5xx-modules-2.6.17-2-686-bigmem, spca5xx-modules-2.6.17-2-k7, spca5xx-modules-2.6.17-2-vserver-686, spca5xx-modules-2.6.17-2-vserver-k7, spca5xx-modules-2.6.17-2-xen-686, spca5xx-modules-2.6.17-2-xen-k7, squashfs-modules-2.6-486, squashfs-modules-2.6-686, squashfs-modules-2.6-686-bigmem, squashfs-modules-2.6-k7, squashfs-modules-2.6-vserver-686, squashfs-modules-2.6-vserver-k7, squashfs-modules-2.6-xen-686, squashfs-modules-2.6-xen-k7, squashfs-modules-2.6.17-2-486, squashfs-modules-2.6.17-2-686, squashfs-modules-2.6.17-2-686-bigmem, squashfs-modules-2.6.17-2-k7, squashfs-modules-2.6.17-2-vserver-686, squashfs-modules-2.6.17-2-vserver-k7, squashfs-modules-2.6.17-2-xen-686, squashfs-modules-2.6.17-2-xen-k7, unionfs-modules-2.6-486, unionfs-modules-2.6-686, unionfs-modules-2.6-686-bigmem, unionfs-modules-2.6-k7, unionfs-modules-2.6.17-2-486, unionfs-modules-2.6.17-2-686, unionfs-modules-2.6.17-2-686-bigmem, unionfs-modules-2.6.17-2-k7 I could use a force-hint on linux-modules-extra-2.6 as well, but as long as it is out-of-date on so many architectures, that won't improve the picture. And also, why do e.g. linux-image-2.6-vserver-k7 get uninstallable (hm, that could be a bug in britney though). - What are our plans for 2.6.19 ? Will we have it enter unstable, and maintain the etch kernel through testing-proposed-updates ? I heard this mentioned some time back. Will we fork a linux-2.6.19 package in unstable ? Will we keep 2.6.19 in experimental for now ? I hope you can keep 2.6.19 in experimental for now - it doesn't take so long to release Etch anymore. Cheers, Andi -- http://home.arcor.de/andreas-barth/
Re: preparation for 2.6.18-6 kernel upload on monday 20th of november 2006.
* Bastian Blank ([EMAIL PROTECTED]) [061117 22:52]: On Fri, Nov 17, 2006 at 10:20:09PM +0100, Goswin von Brederlow wrote: Check the BTS. Its been there for ages now. The patch is broken. Why? I hope that is documented in the bts - and if the patch is broken, the tag patch should be removed, btw. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061115 01:47]: I've updated the text in svn, and added some more to help with a couple of the open bugs in your list. I would really appreciate it if others from the kernel team could review it for accuracy, especially the initramfs-tools/yaird stuff. Another question: What is the recommended installation order for this upgrade? We have different variants: From 2.2, 2.4 or 2.6-kernels (where we have different default kernel versions on different arches)? First packages, then kernel? Or first kernel? Or kernel first if it is 2.2 or 2.4, otherwise packages first? Or ...? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061115 01:47]: aba: Let me know if you need any help incorporating this text, and once its merged, let me know so that I can kill off the version in svn. I know merge it to the release notes (should be visible with the next build). There are two changes I didn't merge: | arch=s390 | [waldi it needs documentation about the new s390 hardware configuration] | /arch This one is IMHO already part of bug #360582: s390 network. Waldi, when can we expect updates from you on that bug? | arch=ia64 | For example, an rx1600 with a single built-in serial port plus | an MP has these ports: |Old Old | MMIO (EFI console(EFI console | addresson builtin) on MP port) New | -- - | builtin 0xff5ettyS0 ttyS1 ttyS0 | MP UPS 0xf8031000ttyS1 ttyS2 ttyS1 | MP Console 0xf803ttyS2 ttyS0 ttyS2 | MP 20xf8030010ttyS3 ttyS3 ttyS3 | MP 30xf8030038ttyS4 ttyS4 ttyS4 I don't think we need this detailed level on the release notes. If we should have more details then we have now (and I even believe now it is already too detailed), one should create an extra document / wiki page / whatever, and we could cross-reference. About the open kernel-related bug reports: | #383982: release-notes: Describe replace of kernel-image package with | linux-image package has happened now. | #271315: kernel-image-2.6.8-1-sparc64: sun keyboard unusable does this bug affect us at all now? If so, we need some more input. | #341225: Etch: Upgrade path from devfs to udev needs documenting This should be also done now. | #325568: Upgrade path for udev needs documenting This has not happened yet, and also, it seems the answer in which order should the upgrade happen is related to that. | #343892: Should document NIC naming issue with udev This should be done now. | #395174: linux-2.6: Dell CERC ATA100/4ch with F/W 6.61 not supported in etch We need more info on that I think. | #360582: s390 network open, see above. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
release notes
Hi, I have read the kernel release notes, and think we should put them into the regular release notes now. Also, I'm not sure how far these bugs are handled by them up to now: #325568: Upgrade path for udev needs documenting #383982: release-notes: Describe replace of kernel-image package with linux-image package #271315: kernel-image-2.6.8-1-sparc64: sun keyboard unusable #341225: Etch: Upgrade path from devfs to udev needs documenting #343892: Should document NIC naming issue with udev #360582: s390 network #395174: linux-2.6: Dell CERC ATA100/4ch with F/W 6.61 not supported in etch Any feedback is welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: release notes
* dann frazier ([EMAIL PROTECTED]) [061114 18:48]: On Tue, Nov 14, 2006 at 06:10:12PM +0100, Andreas Barth wrote: I have read the kernel release notes, and think we should put them into the regular release notes now. Fine by me, given no updates have been made since my first draft :( Should I just mark-up what we have now and send you a patch? Well, the problem is not as much to get the text from svn (I looked at it earlier today, but working on text for a few hours is a bit tiring for me), but rather to fill in the places unanswered so far. But perhaps you can give the text some final love from your side, and send it to me? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
* Goswin von Brederlow ([EMAIL PROTECTED]) [061031 17:31]: Goswin von Brederlow [EMAIL PROTECTED] writes: Andreas Barth [EMAIL PROTECTED] writes: Can we also have amd64-kernels again on i386? Cheers, Andi The patch is in the BTS and quite small. About 5 lines of code change and the obvious ton of .config files. Replying to myself, juhey. Sorry for breaking the threading. Could we have one of these compromises? 1) Apply the patch and set the config but keep the actual images commented out. 2) Do 1 and enable one generic 64bit image. No xen, no vserver. Or is even one more images too much? I think xen or vserver are the perfect environment to have both worlds live on the same machine. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379090: Still no news on 64bit i386 kernels
* Goswin von Brederlow ([EMAIL PROTECTED]) [061031 15:01]: Frederik Schueler [EMAIL PROTECTED] writes: I asked this before and haven't yet recieved an answere: What does w-b do when the amd64 build uploads amd64+i386 64bit kernel debs but not 32bit. Afaik the package should be detected as incomplete and set to needs-build for i386. i386 then builds the 32bit kernels only and uploads them. As soon as there are binary packages for i386, wanna-build marks i386 as installed. How should it detect otherwise if e.g. a kernel was dropped? 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? Which means, at a minimum, changes to debian-cd and D-I to include the amd64 packages on i386 and the linux64 boot option and a wrapper package for apt/aptitude/dpkg to make the amd64 debs appear and installable. Which won't happen anyways for etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Schedule for linux-2.6 2.6.18-4
* Frederik Schueler ([EMAIL PROTECTED]) [061030 16:30]: 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 Can we also have amd64-kernels again on i386? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LSB 3.1 status for etch
* Jeff Licquia ([EMAIL PROTECTED]) [061021 08:51]: The specific commit which touches msync.c (found in Linus's tree) is 204ec841fbea3e5138168edbc3a76d46747cc987. It depends on several of the other patches by Peter Zijlstra that precede it. The whole group is reflected in the patch in Fedora's 2.6.18 kernel called linux-2.6-mm-tracking-dirty-pages.patch. I have not specifically tested the patches, but as this is the only patch which touches the msync code in Fedora's package, it seems to be the likely culprit. So, it would seem, Debian has a few options: - Apply the Fedora patch to Debian's kernels. - Assume that etch will ship with 2.6.19 or later. - Write a small patch to undo the 2.6.17 change which caused the problem, and apply it to Debian's kernels. Thanks for that detailed report. I assume we need to either apply the Fedora patch, or create another patch by our own - shipping wit 2.6.19 sounds like a non-option to me. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: With the current resolution under vote, tg3 WILL HAVE TO GO, this is against what we want ...
* Sven Luther ([EMAIL PROTECTED]) [061011 10:19]: Which means a few things. For one, we cannot add into the etch kernels any of the firmware which where stripped for sarge, and second, we will have to get ride of all the firmware which are illegal to distribute (we agreed to get ride of this one), but also those who are de-facto under the GPL, which we agreed to keep. In particular this will mean that tg3 has to go, others probably too. We have to remove illegal stuff anyways, there is no way around it. Can you please drop that point in the discussion. Reading the resolution, it clearly tells us the stuff which has a DFSG-conformant license, e.g. BSD, is ok, independend of source. Unless we know otherwise, I would assume that whatever was put in the source by the upstream author, is meant to be source if licenses requires a source. So, I only think we have to strip of: a) stuff illegally to distribute (there is *nothing* which helps you around on that); b) stuff where the author doesn't want it to be DFSG-free; Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious issues with linux-2.6 (was: Re: Scheduling linux-2.6 2.6.18-3)
* Matthias Klose ([EMAIL PROTECTED]) [061013 06:43]: Even if the kernel cannot be built with 4.1, it would be nice to have bug reports. I'm not aware of any alpha related reports, although it's not my pet arch. Of course. I'm still planning not to build g++-4.0 from the 4.0 sources, now that all packages are built using 4.1 or using 3.4 as a fallback. We'll need the 4.0 source anyway to build libgcc2 on hppa and glibc on the hurd. Good. That means that switching alpha to 4.1 would just be nice anyways. Thanks. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious issues with linux-2.6 (was: Re: Scheduling linux-2.6 2.6.18-3)
* Bastian Blank ([EMAIL PROTECTED]) [061012 12:41]: On Tue, Oct 10, 2006 at 01:53:58PM +0200, Frederik Schueler wrote: Two big issues are still open: - hppa FTBFS - alpha gcc-4.0 build dependency What should we do with them? Finally disable alpha and hppa(64)? I don't think it is an option to ship Debian without hppa and alpha kernels. So, the only two options seem to me: a) someone fixes these issues, or b) we ship with what we have in etch now, that is 2.6.17. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xen 3.0.3 for Etch
* Jim Crilly ([EMAIL PROTECTED]) [061003 00:14]: On 10/02/06 06:26:27PM -0300, Otavio Salvador wrote: The kernels works to both, dom0 and domU. You use same kernel image. Nice, I didn't know that was possible. Is that mentioned in the docs somewhere, although I admit I didn't look very hard. Xen for Debian is somewhat underdocumented right now. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390724: Ooops on Xen reboot
Package: linux-image-2.6.18-1-xen-amd64 Version: 2.6.18-2 Hi, on rebooting my Xen dom0, I got this error message. Cheers, Andi Kernel BUG at drivers/xen/netfront/netfront.c:717 invalid opcode: [1] SMP CPU 0 Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod evdev pcspkr ext3 jbd mbcache raid1 md_mod Pid: 8, comm: xenwatch Not tainted 2.6.18-1-xen-amd64 #1 RIP: e030:[8036f61b] [8036f61b] network_alloc_rx_buffers+0x1de/0x460 RSP: e02b:8800070d7de0 EFLAGS: 00010086 RAX: RBX: 8800083ebd80 RCX: 0040 RDX: RSI: RDI: 1048 RBP: 8800013d8500 R08: 80455b88 R09: 0001 R10: 0001 R11: 88000156d460 R12: 05605000 R13: 880007344838 R14: 0209 R15: 8800013ddae0 FS: 2ae1cded4100() GS:804c3000() knlGS: CS: e033 DS: ES: Process xenwatch (pid: 8, threadinfo 8800070d6000, task 8800070bc100) Stack: 8800070d7e40 8800013d8000 88000145c000 000f 00d10100 8800013f6d68 00d1 002f04ed2e70 0009 0001 Call Trace: [80367a7b] backend_changed+0x1c8/0x232 [80366920] xenwatch_thread+0x0/0x145 [80290032] keventd_create_kthread+0x0/0x61 [80365d2e] xenwatch_handle_callback+0x15/0x48 [80366a4d] xenwatch_thread+0x12d/0x145 [802901f5] autoremove_wake_function+0x0/0x2e [80290032] keventd_create_kthread+0x0/0x61 [80366920] xenwatch_thread+0x0/0x145 [802334f8] kthread+0xd4/0x107 [8025d06c] child_rip+0xa/0x12 [80290032] keventd_create_kthread+0x0/0x61 [8024982d] worker_thread+0x0/0x122 [8024982d] worker_thread+0x0/0x122 [80233424] kthread+0x0/0x107 [8025d062] child_rip+0x0/0x12 Code: 0f 0b 68 ec ee 41 80 c2 cd 02 4c 63 e2 48 8d bd 80 15 00 00 RIP [8036f61b] network_alloc_rx_buffers+0x1de/0x460 RSP 8800070d7de0 -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
* Bill Allombert ([EMAIL PROTECTED]) [060921 13:11]: 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. 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. From a release point of view, it would be better not to assume too much about the outcome, and I don't think any of the proposed resolution require the kernel package to include any firmwares. From a release point of view, assuming a bad outcome will make it impossible to release etch in December. So, we need to assume and fight for a good outcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Version for etch 4.0 release?
* Ola Lundqvist ([EMAIL PROTECTED]) [060823 12:55]: I got a question from the openvz upstream people on which version of the kernel that will be released as the version in etch. Do you know if it will be 2.6.17 or if any later version may be used? Assuming that the release date sometime in december still holds. That is not yet finally decided. The two likly suspects are currently 2.6.17 or 2.6.18. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Decision about oot-modules for etch
* Daniel Baumann ([EMAIL PROTECTED]) [060731 12:46]: as stated in [0], waldi is working on an oot-module conglomeration package to solve NEW spamming for oot-module packages when the kernel ABI is bumped. Now, I would like to have a definitive statement for that to get everything prepared for etch (basically the ipw packages[2]). This means, a decision of the kernel-team and the release-team is required. Atm, there are the following questions open: AFAICS ipw doesn't provide oot-modules, but only ipw*-source. Is that correct? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Decision about oot-modules for etch
* Daniel Baumann ([EMAIL PROTECTED]) [060731 16:29]: Andreas Barth wrote: AFAICS ipw doesn't provide oot-modules, but only ipw*-source. Is that correct? As I wrot in '[2]' of the previous mail, I want ipw2100 and ipw2200 (and, therefore also ieee8201) as oot, *although* they are already in mainline. But I'm not going to do that when a few weeks afterwards they are removed anyway in favour for a conglomeration package. Ah, ok. Thanks. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Decision about oot-modules for etch
* Daniel Baumann ([EMAIL PROTECTED]) [060731 12:46]: Now, I would like to have a definitive statement for that to get everything prepared for etch (basically the ipw packages[2]). This means, a decision of the kernel-team and the release-team is required. I don't see any release-team decisions required right now. :) Basically, I tend to something like: * Will be oot-modules in main outside of the linux-modules-extra be removed by the release-team for etch? If there are fewer (source) packages to be rebuild in case of kernel abi changes, that's something good. If all important modules are there, we might consider to deprecate/disallow other packages to require to be rebuild in case of kernel changes. I don't really mind to make one exception for some package if there are good reasons; but if that means that 40 maintainers start jumping because their package should get the exception, that boils down to no exception. :) As to allow new packages with build oot-modules: I'm not too sure if we should allow that, as every module makes a kernel update more complicated. But of course, you could try to convince us that ipw is important enough for that. * If no conglomeration package for contrib modules, will oot-modules of contrib be removed by the release-team for etch? Same for contrib: If there is no alternative to single packages, well, we need to use single packages. Also, how many packages in contrib generate oot-modules? If there are only 1 or 2, why bother? * If contrib oot-modules outside of a conglomeration packages will not be removed, will it be possible to have updates to the usual conditions for point-releases, or, will this be refused for oot-modules of contrib given no contrib-conglomeration package is done? I don't see a reason to refuse upgrades during point release right now. If the oot-package with their own modules are updated, everything is fine. Updates during point release are more problematic with a conglomeration package, as all binary packages need to be rebuild, forcing users a (potentially) unneeded package upgrade. (Of course, there are the normal rules for stable updates as well.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch
* Frans Pop ([EMAIL PROTECTED]) [060727 16:41]: On Thursday 27 July 2006 16:19, Andreas Barth wrote: What happened during the Sarge release was that we were aiming all the time to release ASAP. If you do that, you cannot really relax your freeze selectively. Well, we're definitly not aiming to release all the time. :) I meant after the base freeze of course. The time from the base freeze (including the kernel) to the actual release was very (too?) long. I am talking about possibly deciding to relax the base freeze for a while if there are major issues that will delay the release anyway. Of course you'd have to be selective and test very carefully. Well, the base freeze sounds (for me) mostly like: We must be sure that update doesn't drive us further away from release. If there is an update e.g. in Mid of August where d-i is happy with, and the relevant team is sure that it is stable enough (and possible upcoming issues will be fixed soon enough), and it looks for us the same, I don't see an issue to block it. Like said earlier, there is one thing that's definitly worse than allowing an update in: Discussing about it a few weeks, backporting some fixes back and finally accepting it later. Security updates are not a problem. We can handle that. I was talking about a possible update to a new upstream kernel minor release. For that, I think there should be a some last date, which sounds to me currently like something in October. Until that, as long as d-i is ok, and people are carefull enough to not select a kernel just because it's newer, there is no reason to not go ahead. Freeze doesn't mean no updates possible, just be way more careful now please. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
which kernel version for etch
Hi, 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? 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. 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. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch
* Andreas Barth ([EMAIL PROTECTED]) [060716 10:59]: 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? Also, obviously I forgot to ask something - how does the firmware issue look like to you? Are there critical parts of non-free firmware we need to have in the installer? Or is all firmware now remote enough to say well, it's good enough if people can add stuff after installation? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch
* Bastian Blank ([EMAIL PROTECTED]) [060716 12:55]: [ non-cooperative things ] Could please someone from the kernel team who is coorporative handle this issue? If we don't manage to act together, we cannot release in time or even not at all, and that would be really sad. Also, please note that all the times I mentioned in my post were not invented just now by me, but are plannings communicated more than once. I don't mind to change the plan, but if so, that should happen in a way that the other involved teams are happy with it as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch
* Frederik Schueler ([EMAIL PROTECTED]) [060716 16:15]: 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. Ok. I will try to put something along that into the next release update. I hope this is ok for you. 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. Hm. Frans, how much effort is an ABI bump on the d-i side? Actually, there will be a time when the kernel is frozen hard, independend of how late we try to have it. There is no way around that, except by not releasing at all. The only way out that I see is that from the frozen hard time on, there needs to be some security support for the kernel, so that in case there are issues, we can release a newer kernel via security.debian.org. Of course, there is nothing that makes it impossible to put updated kernel images to testing-proposed-updates - just that they're not installed by default. This might be ok for testing the issues, but I'm not the final jugde on that. 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. When do you think is the latest chance for us to say stop, we need to exchange the kernel? Before the final d-i build, before the last britney run, before the symlink is moved, before the packages files are generated, before the mirrors are pushed, before the CDs are built? There will be a sorry, it is too late-date - we only can change when it is. Perhaps we should really try to write down when this point in time is going to be, that might make our decisions easier later on. Actually, I think it's way more important that we make sure we have infrastructure ready on each and every day to update the kernel, than to try to delay this point in time for a few hours or days. Because we will need that not only before release, but also after release, and if I look at the amount of kernel root exploits, we will need it quite fast. AFAICS the round trip time is more than a week, because the resulting d-i images need some heavy testing before we declare them stable. Even if it is only one week, with more than one security issue per week (which happened quite often for the current kernels series), we cannot release at all. Is that really what we want? Or shouldn't we really rather be fast to give the people with net access access to updated kernels? (And please consider that right now, we still have an installer with buggy kernel images for sarge, and people are required to update their kernels via security.d.o - for more than one year now. Is the difference of a few days before release really so bad?) Also, what I considered quite problematic in sarge was that we had a long time span of uncertainity, where we neither decided to exchange the kernel nor decided to rather not, and then did it when it was even later, which just makes the cost for all parties higher. That is something I really want to avoid this time. I hope we can agree on that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch
* Frederik Schueler ([EMAIL PROTECTED]) [060716 16:54]: The kernel firmware issue has not been solved yet in Debian. Plans for a GR to decide if and which firmware is distributable in Debian after the editorial changes to the SC have never been realized. Currently, distributing appropriately licensed firmwares without source in the non-free repository is - pragmatically - the best solution for those of our users, who run hardware which requires a binary only firmware. Just that this doesn't help our users who need it in the installer. We need a fundamental solution for this, after Etch has been released. Fully agreed. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling 2.6.17-1
* dann frazier ([EMAIL PROTECTED]) [060619 20:51]: On Mon, Jun 19, 2006 at 06:56:50PM +0200, Bastian Blank wrote: On Sun, Jun 18, 2006 at 04:10:30PM -0600, dann frazier wrote: The only technical issue is getting the meta packages to play well. I think rough consensus was to leave the metapackages as-is in linux-2.6.16 and either 1) drop meta packages from linux-2.6 = 2.6.17 or 2) create separate metapackages for linux-2.6 (linux-image-2.6-686-sid, for example). AFAIK the plan is the following: - linux-2.6 remains the metapackages, the point to the last available one. - linux-2.6.16 contains no metapackages. - linux-latest-2.6 or so contains the metapackages to match linux-2.6.16 and have to go through t-p-u. fwiw, this doesn't provide a way for people to track the proposed etch kernel in sid, which may reduce the number of testers of that kernel prior to migration. Agreed. I think there should be agreement on which meta packages point to where before bumping meta packages version numbers, and we should find a way that encourages as many people as possible in both etch and unstable to test etch kernels. I see two ways: 1. linux-image-2.6 - very latest, and (perhaps) something like linux-image-etch - etch kernels (plus in etch, linux-image-2.6 - etch) 2. linux-image-2.6 - etch kernels, linux-image-2.6-latest to most current I think the 2nd way would give us more etch kernel testers, because most people will just stay with linux-image-2.6 - but of course I'm a bit biased for more etch testing (well, but most people here will have a different bias, so I think that's ok :). Comments? Cheers, Andi BTW: I would really prefer some kind of we're now doing foo and bar to debian-release prior to upload if there was no previous agreement with the release team to prevent release team members getting panic attacks on seeing 2.6.17 being uploaded. :) -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch for update-grub for Sarge R3
* Otavio Salvador ([EMAIL PROTECTED]) [060614 19:11]: Manoj Srivastava [EMAIL PROTECTED] writes: One way to mitigate the problem is to propagate a fixed update-grub script into a Sarge point release; here is a minimal patch that should make a sarge update-grub script be STDOUT safe. If the RM people accept I can prepare a package with it and upload to proposed-updates. The script looks good, but I don't know who has actually tested it. So, if someone trustworthy (i.e. any of you) tests it, and it works (both for sarge as well as for the upgrade to etch), I'd be happy with an upload. Thanks. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060526 10:20]: Well, it was my understanding that both those packages where living in a differnt section, namely etch and etch-whatever, which would take care of the problem. Failing that, it is easy enough to handle the problem in the same way as we want to handle the sid/etch kernel dichotomy, in case we froze on a 2.6.16 kernel. Both packages will have to live in etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.2 from the archive?
* dann frazier ([EMAIL PROTECTED]) [060526 15:14]: On Mon, May 22, 2006 at 01:24:52PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 11:20:38PM +0200, Christian T. Steigies wrote: need some further discussion among the m68k folks... does this also mean that an etch installation will require a 2.6 kernel to run on the machine? Some of the m68k buildds (most macs) are still running 2.2.25, the two Atari Falcons run 2.4. The long term aim is indeed to release etch with only 2.6 kernels, which means no 2.4 but also no 2.2 kernel. Now, the removal of the 2.2 kernel should follow the same roadmap as what was discussed for the 2.4 kernels, and i suppose that for m68k purpose, you can substitute '2.4' with '2.2 or 2.4' in all those emails. There has been no DSA for a 2.2 kernel to date in the lifetime of woody/sarge (counting on my recollection here, I'm currently offline), so I can't see how we can continue shipping it unless someone steps up to handle this. Of course, you could always request insecure status from the release team (with proper release notes, etc). As far as I know, 2.2 isn't even supported by glibc any more. If that is the case, we definitly shouldn't ship with 2.2. Also, anyone is free to open a kernel-2-2.debian.net repository - and I would be willing to mention that in the release notes. I however doubt we should deliver 2.2 kernels inside of etch. Heck, we even consider to drop 2.4. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Status of non-free firmware
Hi, at least I forgot what the current status is. For this reason, I'm asking where we are. Please don't take that as I trying to push you or something, but rather as a please do cluebat me. :) And, I would be interested (if there exists or is not too much effort to create) in a list where blobs is marked as essential if some boards don't run/have cd/hard disk/network without, and where it's marked whether the firmware runs on the host CPU or somewhere else. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* dann frazier ([EMAIL PROTECTED]) [060524 05:33]: On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote: On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: Kernel udeb creation process (possibly using k-p?) - If we build all of the *existing* udebs from a single source, we outgrow the limit of the Binary: field in the control file. Huh ? This problem is known since over 2 years now, and i thought it was one of the things that where fixed earlier this year or late last year ? Immediately after I sent out the notes from this meeting, aba said he'd followed up with an ftp master (neuro, iirc). From what he was told, it sounds like the information we had during this meeting was stale/inaccurate. Actually, if I understood everything correct, the issue with the long lines used to be that on the way from the buildd to the buildd maintainer, the long line in the changes-file could be broken by MTAs, and this has been fixed. The best way to test if this is all would be to upload one source package producing all udebs to experimental, and see what happens. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: You are ignoring that we have scheduled a time to update the kernel again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Nice then, the question remains of how often and in what timeframe we can do such. Imagine there is a security issue shortly before the release, will we say like last time, let's ship with it, because we have not put into place the procedure to handle it in a timely fashion ? There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 12:14]: On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Err, do you really need to retest everything when a kernel change only includes a small set of security fixes ? I think 6 weeks may be overkill there, unless naturally you are speaking of a version bump with a huge load of changes. If it is a minimal patch, we will see. However, I don't think it's usefull to discuss that now in theory. We need to see the patchset (and also what amount of open issues there still is elsewhere) to decide what to do. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel installer issues discussion at debconf
* maximilian attems ([EMAIL PROTECTED]) [060516 11:09]: On Tue, May 16, 2006 at 06:11:53AM +0200, Andreas Barth wrote: I just want to point out that we have at Tuesday, 10.05 in the Hacklab the stable release BoF, which will give us a chance to discuss that topic. (Thanks to Frans for pointing out how usefull such a pointer would be. :) ok, please take into account for remote participants the responses to the thread which kernel version for etch? on d-kernel. That is understood - however, that BoF was/is rather about the current stable version, sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel installer issues discussion at debconf
Hi, I just want to point out that we have at Tuesday, 10.05 in the Hacklab the stable release BoF, which will give us a chance to discuss that topic. (Thanks to Frans for pointing out how usefull such a pointer would be. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* dann frazier ([EMAIL PROTECTED]) [060513 02:00]: Of course, I do see the benefit to Bastian's suggestion - we'd have working metapackages for both sid etch that pull in the latest available in that dist. My proposal leaves sid meta packages pointing at the latest kernel for etch. Actually, I see the sid meta packages pointing to the latest etch kernel as a feature, as this makes sure that more boxes have these kernels installed, and especially the d-i-build boxes will have the correct kernel, which will help with d-i testing and final preparations for etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* dann frazier ([EMAIL PROTECTED]) [060513 21:01]: On Sat, May 13, 2006 at 06:23:46AM +0200, Sven Luther wrote: Mmm. Do we really want the default for sid to be something that will maybe never be going into etch ? I think so; there is a class of users (myself included) who want to run/test the latest and greatest on some machines, and its nice when it automatically updates. Users that just want to run what will go into testing should, well, just run testing :) Well, actually, there are reasons for both decisions. I think that in the end, it is more important to make building packages for etch easier. Please remember, this is only for a limited time, and at that time, we'll be quite busy with etch issues. And, BTW, kernel developers should know when a new kernel arrives. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* dann frazier ([EMAIL PROTECTED]) [060511 21:48]: On Wed, May 10, 2006 at 12:21:23PM +0200, Sven Luther wrote: On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: 1) Frans is hardly competent enough to give advice for this. He is biased by his personal feud over this with me, and i believe has not a good enough oversight of the problems involved to give a good technical advice. This is my opinion, though, so feel free to ignore it. We need to discuss how to update the kernel for the next stable point release. There is a stable release management BoF during Debconf, I'll try to discuss it there. Of course, anyone can come to that BoF, and I'd welcome anyone who helps us to resolve issues. (And this discussion needs to happen anyways, independend of Etch.) I will not be at debconf, so i will not be able to participate in this discussion. fyi, I will be there, and would very much like to participate. Cool. Looking forward to see you there. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: 1) Frans is hardly competent enough to give advice for this. He is biased by his personal feud over this with me, and i believe has not a good enough oversight of the problems involved to give a good technical advice. This is my opinion, though, so feel free to ignore it. We need to discuss how to update the kernel for the next stable point release. There is a stable release management BoF during Debconf, I'll try to discuss it there. Of course, anyone can come to that BoF, and I'd welcome anyone who helps us to resolve issues. (And this discussion needs to happen anyways, independend of Etch.) 2) Any discussion about this issue done during the sarge time can be thrown in the trashcan. Remember the mess that was the kernel packages in sarge, and compare it to the current situation. I didn't claim that Sarge and Etch are the same. However, one should and could do the following: Which issues are problematic within Sarge? Could that happen in Etch again? If the answer is no, I'm happy. If not, one could try to fix it in time. 4) Back in the sarge time, a full d-i rebuild meant over a month of work. We have solved all the issues we had with this on the kernel side, and the delay is now caused by a lack of organisation on the d-i side, and their refusal to address the issue. I'm going to discuss that with the d-i people. Hey, we could even do an ad-hoc BoF on kerneld-i. :) I believe it is the RMs place to have enough vision to find the best technical solution, and to make sure they happen, even if a few try to block it because they are afraid of change. I think the RMs should only address issues if the maintainers / teams / whoever fail to address them by themself. So for now, I'm not going to force anybody to something. But I definitly will discuss issues with different people during debconf. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:33]: On Wed, May 10, 2006 at 11:21:27AM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: Andreas Barth, you claimed that you could see strong reason not to go this way, please could you comment on them now in this thread. I think that discussion how to handle udebs should be done inbetween kernel and boot team, and the right mail address for the boot team people is [EMAIL PROTECTED] I don't like to be a human forwarder of infos. Debian-boot has said they want nothing to do with me Well, in that case, perhaps someone else from the kernel team should try to speak with them. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Frederik Schueler ([EMAIL PROTECTED]) [060509 23:47]: Second, if we go this path and do an Etch release with 2.6.16.x, I would like to NOT stick forever with that very version we will have in testing at the day the freeze happens, but keep updating the kernel images and the installer for every point release to a reasonably newer 2.6.16.x upstream release. We need to discuss how to do it sanely for the installer; I'll discuss that with Frans anyways during debconf for Sarge, and what we learn from that for Etch. Otherwise, this is ok from the stable release management point of view. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Andreas Barth ([EMAIL PROTECTED]) [060510 11:17]: * Frederik Schueler ([EMAIL PROTECTED]) [060509 23:47]: Second, if we go this path and do an Etch release with 2.6.16.x, I would like to NOT stick forever with that very version we will have in testing at the day the freeze happens, but keep updating the kernel images and the installer for every point release to a reasonably newer 2.6.16.x upstream release. We need to discuss how to do it sanely for the installer; I'll discuss that with Frans anyways during debconf for Sarge, and what we learn from that for Etch. Otherwise, this is ok from the stable release management point of view. Ah, and of course: If a kernel update breaks out-of-the-tree modules, we need some way to handle that. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 11:06]: Andreas Barth, you claimed that you could see strong reason not to go this way, please could you comment on them now in this thread. I think that discussion how to handle udebs should be done inbetween kernel and boot team, and the right mail address for the boot team people is [EMAIL PROTECTED] I don't like to be a human forwarder of infos. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: which kernel version for etch?
* Sven Luther ([EMAIL PROTECTED]) [060510 12:25]: On Wed, May 10, 2006 at 12:02:48PM +0200, Andreas Barth wrote: * Sven Luther ([EMAIL PROTECTED]) [060510 11:31]: 1) Frans is hardly competent enough to give advice for this. He is biased by his personal feud over this with me, and i believe has not a good enough oversight of the problems involved to give a good technical advice. This is my opinion, though, so feel free to ignore it. We need to discuss how to update the kernel for the next stable point release. There is a stable release management BoF during Debconf, I'll try to discuss it there. Of course, anyone can come to that BoF, and I'd welcome anyone who helps us to resolve issues. (And this discussion needs to happen anyways, independend of Etch.) I will not be at debconf, so i will not be able to participate in this discussion. That's a pity. 2) Any discussion about this issue done during the sarge time can be thrown in the trashcan. Remember the mess that was the kernel packages in sarge, and compare it to the current situation. I didn't claim that Sarge and Etch are the same. However, one should and could do the following: Which issues are problematic within Sarge? Could that happen in Etch again? If the answer is no, I'm happy. If not, one could try to fix it in time. Seems good. I listed a few points in the past, do you want that i repeat them, or will you find them in the archive by yourself. Hm, best if you could send me a private mail listing these points (or just containing pointers), so I can make sure they're picked up. i think that we are already in the situation where the corresponding teams have failed. Perhaps I'm a bit more tolerant in that then you, but I agree that we might come to a point where this is the case, and in that case, I'll make sure the release team calls for a solution. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
* Bastian Blank ([EMAIL PROTECTED]) [060428 22:50]: On Sat, Apr 22, 2006 at 08:33:38PM +0200, Andreas Barth wrote: A combination of a working patch in the most current point release, documentation in the etch release notes and a conflict with the current package in sarge might however do the trick. Dear grub maintainers Can you please prepare an upload to stable which includes the update-grub fix from 0.97-3? The attached patch is a port of my original patch to the version in sarge. Did you test the patch on a sarge box? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
* Martin Schulze ([EMAIL PROTECTED]) [060422 11:17]: Bastian Blank wrote: On Tue, Apr 18, 2006 at 05:04:53PM +0200, maximilian attems wrote: waldi why not add your patch to update-grub to the next stable release? Please keep in mind that you can't rely on a current sarge installation when it is upgraded to etch, in other words, you can't depend on people keeping their sarge r0 up-to-date with newer revisions or security updates. Especially for offline installations that are only maintained via ready CD/DVD images this may be the case. A combination of a working patch in the most current point release, documentation in the etch release notes and a conflict with the current package in sarge might however do the trick. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge upgrade - linux, grub conflict
* Bastian Blank ([EMAIL PROTECTED]) [060417 11:39]: On Sun, Apr 16, 2006 at 09:59:55PM -0700, Steve Langasek wrote: On Mon, Apr 17, 2006 at 12:29:04AM +0200, Bastian Blank wrote: For sarge updates of the linux kernels, grub needs to be updated before linux-image*. Can this be forced by an conflict with older versions? A dependency is not appropriate. Can you give more detail on why grub needs to be updated first? I haven't heard anything about this incompatibilty, and would like to understand it before endorsing a versioned conflict; there's a very good chance that a versioned conflict with grub would force removal, not upgrade, of the bootloader. kernel-package 10 uses debconf for the user communication. This includes the pre and post scripts specified in /etc/kernel-img.conf. update-grub from grub older than 0.97-3 writes informations to stdout, which is coupled to debconf and makes it fail. I would *really* hope you are a bit more careful about such changes. We require all packages in etch to be installable with the core sarge tools (whether the tools are dpkg or grub or ...). Can't the kernel packages detect whether they have the sarge or the etch version of grub, and behave acordingly? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
timeline for next kernel update round
Hi, as we're now on track in getting sarge r2 out, I'm interessted when the next kernel update should happen - and of course if there is something important from your side. As far as I understood, that update will be an ABI-change, which means: we need to rebuild the installer. Is that correct? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
