Bug#623377: rpcbind: Please include upstart support in the rpcbind package
tags 719357 patch
tags 623377 patch
thanks
With Luk's approval, I've prepared an NMU to address these two bugs in
rpcbind. Please find the NMU diff attached.
This NMU will be uploaded to unstable shortly.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
=== modified file 'debian/changelog'
--- a/debian/changelog 2012-06-16 00:02:37 +
+++ b/debian/changelog 2013-08-12 16:13:00 +
@@ -1,3 +1,17 @@
+rpcbind (0.2.0-8.1) unstable; urgency=low
+
+ * Non-maintainer upload, approved by Luk Claes.
+ * Convert rpcbind to Upstart. Closes: #719357.
+ * Fix to look directly in /run instead of via the /var/run symlink.
+ * Adjust init script to start rpcbind only in rcS, not to try to start it
+ again in runlevels [2345]: the service should always start reliably in
+ rcS, with no reason to ever restart it later. In practice, insserv
+ already ignores the request to run the script twice (considering it
+ "done" already after leaving runlevel S), so this is merely correcting
+ the documentation of the current behavior. Closes: #623377.
+
+ -- Steve Langasek Mon, 12 Aug 2013 18:11:48 +0200
+
rpcbind (0.2.0-8) unstable; urgency=low
* Relabel the files if SE Linux is active
=== modified file 'debian/control'
--- a/debian/control 2012-06-16 00:02:37 +
+++ b/debian/control 2013-08-11 10:41:15 +
@@ -9,7 +9,7 @@
Package: rpcbind
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 3.2-14), insserv (>= 1.14.0-2.1) | file-rc, initscripts (>= 2.88dsf-13.3)
+Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (>= 4.1+Debian3), insserv (>= 1.14.0-2.1) | file-rc, initscripts (>= 2.88dsf-13.3)
Conflicts: portmap
Provides: portmap
Description: converts RPC program numbers into universal addresses
=== modified file 'debian/init.d'
--- a/debian/init.d 2012-06-16 00:02:37 +
+++ b/debian/init.d 2013-08-12 16:08:42 +
@@ -6,7 +6,7 @@
# Provides: rpcbind
# Required-Start:$network $local_fs
# Required-Stop: $network $local_fs
-# Default-Start: S 2 3 4 5
+# Default-Start: S
# Default-Stop: 0 1 6
# Short-Description: RPC portmapper replacement
# Description: rpcbind is a server that converts RPC (Remote
@@ -78,12 +78,21 @@
case "$1" in
start)
+if init_is_upstart; then
+exit 1
+fi
start $OPTIONS
;;
stop)
+if init_is_upstart; then
+exit 0
+fi
stop
;;
restart|force-reload)
+if init_is_upstart; then
+exit 1
+fi
stop
start $OPTIONS
;;
=== added file 'debian/patches/run-migration'
--- a/debian/patches/run-migration 1970-01-01 00:00:00 +
+++ b/debian/patches/run-migration 2013-08-10 21:22:57 +
@@ -0,0 +1,44 @@
+Author: Steve Langasek
+Description: Fix to look directly in /run instead of via the /var/run symlink
+ Because /var may be a separate partition, and could even be mounted via NFS,
+ and in wheezy and later /var/run is a symlink to /run, look up our files in
+ /run directly. This ensures rpcbind can be started early in boot without
+ any races.
+Index: oneiric/src/rpcbind.c
+===
+--- oneiric.orig/src/rpcbind.c
oneiric/src/rpcbind.c
+@@ -89,7 +89,14 @@
+ /* who to suid to if -s is given */
+ #define RUN_AS "daemon"
+
+-#define RPCBINDDLOCK "/var/run/rpcbind.lock"
++#define RPCBINDDLOCK "/run/rpcbind.lock"
++
++/* Bypass the libtirpc definition, because we know that /var/run is a compat
++ * symlink to /run. */
++#ifdef _PATH_RPCBINDSOCK
++#undef _PATH_RPCBINDSOCK
++#endif
++#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
+
+ int runasdaemon = 0;
+ int insecure = 0;
+Index: oneiric/src/rpcinfo.c
+===
+--- oneiric.orig/src/rpcinfo.c
oneiric/src/rpcinfo.c
+@@ -75,6 +75,13 @@
+ #define MAX_VERS ((u_long)4294967295UL)
+ #define UNKNOWN "unknown"
+
++/* Bypass the libtirpc definition, because we know that /var/run is a compat
++ * symlink to /run. */
++#ifdef _PATH_RPCBINDSOCK
++#undef _PATH_RPCBINDSOCK
++#endif
++#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
++
+ /*
+ * Functions to be performed.
+ */
=== modified file 'debian/patches/series'
--- a/debian/patches/series 2011-12-10 11:36:35 +
+++ b/debian/patches/series 2013-08-10 21:18:15 +
@@ -2,3 +2,4 @@
02-manpages.patch
03-563971-warmstart-error-msg.patch
04-610718-non-linux.patch
+run-migration
=== modified file '
Bug#623377: rpcbind: Please include upstart support in the rpcbind package
Hey Bastian, On Tue, Aug 13, 2013 at 08:56:54AM +0200, Bastian Blank wrote: > On Tue, Aug 13, 2013 at 01:15:31AM +0200, Steve Langasek wrote: > > + * Fix to look directly in /run instead of via the /var/run symlink. > Where is the bug report for this? This is mentioned in bug #719357. > > case "$1" in > > start) > > +if init_is_upstart; then > > +exit 1 > > +fi > Where is this documented and why does it need to be done in every case? Documented generally in Debian policy 9.11.1. This *could* be implemented by exiting non-zero in all cases, but it's nicer from a policy perspective to return 0 when asking to stop a service that is not managed by upstart (because from the init script's perspective, it is "not running"). > > --- a/debian/postinst 2011-12-10 11:36:35 + > > +++ b/debian/postinst 2013-08-12 22:46:00 + > > @@ -10,6 +10,9 @@ > > ln -s /run/rpcbind.pid /run/sendsigs.omit.d/rpcbind > > fi > > fi > > + if dpkg --compare-versions "$2" lt "0.2.0-8.1"; then > > + update-rc.d -f rpcbind remove > > + fi > How does this not trash local modifications? sysv-rc in jessie does not support non-dependency-based boot, so there are no local modifications to the links that need to be (or can be) supported anyway. Are you concerned about the file-rc case? I'm not attached to this bit, but I discussed it with Luk and he said he would prefer the stale links be cleaned up. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Mon, Nov 14, 2005 at 10:38:41PM +0100, Sven Luther wrote: > I still think choice is good, and also what users expect of debian. A sane > default, plus the ability to override that in expert mode. Choice is overrated, and a poor substitute for properly working tools. "Which initramfs generator do I need to use so that my system will be bootable post-install?" is not a choice that *any* user looks forward to making; if a user really has a strong preference for yaird vs. initramfs-tools, that option is open to them after the install. Too often, Debian developers (and Open Source folks in general) give users "choices" in lieu of making sound technical decisions or fixing bugs. I'll take "install this; it works, and when it doesn't, the bugs will get fixed" any day over "well, you can have mediocre.py, or you can have mediocre.pl; if one doesn't work, use the other one". In the case of initramfs generators in the installer, giving users "choice" instead of just fixing bugs means pushing the load on the installer team for testing a greater number of code paths, and on the translators for debconf templates that no one should ever need. It's ok if both of the available alternatives are currently buggy and we don't yet know which one represents the correct technical decision; or if the correct decision varies from architecture to architecture. None of these are reasons to not make the decision -- we just can't make it /yet/. Incidentally, I'm pretty sure that regardless of which initramfs generator d-i favors, the dependencies on the linux-image packages should be switched around to put initramfs-tools first so that we have an automatic upgrade path for sarge systems using 2.4 kernels. (Obviously, d-i can install whichever is better from an installer POV instead.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [D-I] Supporting 2.6.14 kernels in base-installer
On Tue, Nov 15, 2005 at 08:31:28AM +0100, Sven Luther wrote: > On Mon, Nov 14, 2005 at 08:38:03PM -0800, Steve Langasek wrote: > > On Mon, Nov 14, 2005 at 10:38:41PM +0100, Sven Luther wrote: > > > I still think choice is good, and also what users expect of debian. A sane > > > default, plus the ability to override that in expert mode. > > Choice is overrated, and a poor substitute for properly working tools. > > "Which initramfs generator do I need to use so that my system will be > > bootable post-install?" is not a choice that *any* user looks forward to > > making; if a user really has a strong preference for yaird vs. > > initramfs-tools, that option is open to them after the install. > The real question here is : > 1) what does it cost us. I *listed* other costs, which you apparently ignored. > Joeyh is concerned about testing. I personally have doubts that this is a > bad thing, as it means more testing which is good, but i defer to his > greater experience on this. No, this is extra testing of *code that wouldn't need to exist if not for this option*. That's not good, that's *wasteful*. > > Too often, Debian developers (and Open Source folks in general) give users > > "choices" in lieu of making sound technical decisions or fixing bugs. I'll > > take "install this; it works, and when it doesn't, the bugs will get fixed" > > any day over "well, you can have mediocre.py, or you can have mediocre.pl; > > if one doesn't work, use the other one". In the case of initramfs > > generators in the installer, giving users "choice" instead of just fixing > > bugs means pushing the load on the installer team for testing a greater > > number of code paths, and on the translators for debconf templates that no > > one should ever need. > Nope, it is more than a technical difference in language used, it is a > different design goal between both. Um... the design goal is "create an initramfs that boots the user's system." Any other design goals are almost completely irrelevant to the user... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340688: Bug#339955: TODO
severity 340688 important severity 340689 important severity 339955 important thanks On Fri, Nov 25, 2005 at 01:00:08AM +0100, Thomas Hood wrote: > Before /etc/init.d/rc can source .sh scripts, all we have to do is get > various maintainers to eliminate all these exit commands. Hmm; it seems I had quite the brainfart when I re-upgraded this bug report -- I somehow did not realize we were talking about sysv-rc, the standard runlevel manager in Debian, and thought this was a discussion about file-rc or some *other* runlevel manager package. Since sysv-rc is obviously the default runlevel manager in Debian and millions of people use it, if no one has yet reported breakage as a result of not sourcing .sh scripts, my concern about this breaking "unrelated packages or the whole system" is invalid. Downgrading again, with apologies. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#333776: qt-x11-free build fails
notfound 326581 2.3.5-8 notfound 326581 2.3.5-8.1 unblock 341666 by 326581 unblock 341675 by 326581 retitle 326581 [hppa] glibc-2.3.5 lets python FTBFS found 333766 2.3.5-8 merge 333766 342545 thanks > qt-x11-free's recent failure to build on hppa is apparently due to a glibc > problem that was allegedly, but not actually, fixed in 2.3.5-8, or has > since returned (presumably #326581 or something else that was thought fixed > by building with gcc-3.4 on hppa). The message below has a link to an > example of the build failure. This is a bug that was believed fixed previously, but it is *not* bug #326581; it's bug #333766, which was fixed in glibc 2.3.5-7. (And it really was fixed, otherwise kdelibs4c2 wouldn't be in testing right now for hppa.) But it's back in 2.3.5-8; could this have to do with the fact that 2.3.5-7 was built (wrongly) with gcc-4.0, and 2.3.5-8 is the first version to build with gcc-3.4? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#342931: doesn't work on alpha
reassign 342931 klibc 1.1.1-4
# completely broken binaries on an arch == RC
severity 342931 grave
tags 342931 patch
thanks
Well, I haven't been able to reproduce Norbert's exact error, but I think
this may be due to differences in successive versions of klibc.
Here's what I am able to reproduce:
EXT3-fs: mounted filesystem with ordered data mode.
Begin: Running /scripts/log-bottom ...
[...]
run-init: rootfs not a ramfs or tmpfs: error 0
Kernel panic - not syncing: Attempted to kill init!
This one was pretty easy to figure out once I dug into run-init: the 64-bit
definition of struct statfs is completely wrong for alpha. I'd be pretty
surprised if it were correct anywhere; using a 64-bit f_type field makes no
sense anywhere. This is the first patch that's attached. Please confirm
that this doesn't cause regressions on other 64-bit archs; it's my
understanding that people have klibc working on amd64, which my reading of
the source says should be using the 64-bit version of the struct, so.
The next problem in line was that when trying to clear the initramfs to free
memory before overmounting, run-init was getting EPERM instead of EISDIR
when calling unlink() on directories. After stepping through both glibc and
klibc linked binaries, I've concluded that the issue is simply that klibc is
trying to read the errno from the wrong register. Initially, I was
concerned this meant unlink was different from other syscalls on alpha,
which didn't make sense; then I realized that none of the other syscalls I
was looking at were *returning* a non-zero errno, just a return value. So
this second simple patch applied after the first should get us a completely
working initramfs-tools on alpha, AFAICT.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff -u klibc-1.1.1/debian/changelog klibc-1.1.1/debian/changelog
--- klibc-1.1.1/debian/changelog
+++ klibc-1.1.1/debian/changelog
@@ -1,3 +1,11 @@
+klibc (1.1.1-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix the definition of struct statfs64, required for run-init to work on
+alpha
+
+ -- Steve Langasek <[EMAIL PROTECTED]> Thu, 15 Dec 2005 00:08:56 -0800
+
klibc (1.1.1-4) unstable; urgency=low
* debian/rules,debian/control: Use gcc-3.3 for sparc.
only in patch2:
unchanged:
--- klibc-1.1.1.orig/include/sys/vfs.h
+++ klibc-1.1.1/include/sys/vfs.h
@@ -32,17 +32,17 @@
#else /* _BITSIZE == 64 */
struct statfs {
-uint64_t f_type;
-uint64_t f_bsize;
+uint32_t f_type;
+uint32_t f_bsize;
uint64_t f_blocks;
uint64_t f_bfree;
uint64_t f_bavail;
uint64_t f_files;
uint64_t f_ffree;
__kernel_fsid_t f_fsid;
-uint64_t f_namelen;
-uint64_t f_frsize;
-uint64_t f_spare[5];
+uint32_t f_namelen;
+uint32_t f_frsize;
+uint32_t f_spare[5];
};
#endif /* _BITSIZE */
diff -u klibc-1.1.1/debian/changelog klibc-1.1.1/debian/changelog
--- klibc-1.1.1/debian/changelog
+++ klibc-1.1.1/debian/changelog
@@ -3,6 +3,7 @@
* Non-maintainer upload.
* Fix the definition of struct statfs64, required for run-init to work on
alpha
+ * Grab the errno from the right register after syscalls on alpha!
-- Steve Langasek <[EMAIL PROTECTED]> Thu, 15 Dec 2005 00:08:56 -0800
only in patch2:
unchanged:
diff -Nru /tmp/Ylb9yZiFni/klibc-1.1.1/klibc/arch/alpha/syscall.S
/tmp/qrWEKspwxh/klibc-1.1.1/klibc/arch/alpha/syscall.S
--- /tmp/Ylb9yZiFni/klibc-1.1.1/klibc/arch/alpha/syscall.S 2005-09-06
13:49:34.0 -0700
+++ /tmp/qrWEKspwxh/klibc-1.1.1/klibc/arch/alpha/syscall.S 2005-12-15
23:42:02.0 -0800
@@ -17,8 +17,8 @@
2:
ldgpgp, 0(pv)
lda a1, errno
+ stl v0, 0(a1)
lda v0, -1(zero)
- stl a3, 0(a1)
1:
ret zero,(ra),1
signature.asc
Description: Digital signature
Bug#313552: kernel-image-2.6.11-alpha: qla1280 driver doesn't work with ISP1020 (PCI ID: 1077:1020)
Hi David, On Mon, Jan 02, 2006 at 11:32:50PM +0100, David Schmitt wrote: > Could you please retest this with a current 2.6.14 or 2.6.15-rc (from > experimental) image? The bug still exists with 2.6.14. I haven't tested 2.6.15 yet, but I eventually worked around the bug by throwing a second SCSI controller in the box so I could make some headway on d-i for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: remaining linux-2.6 RC bugs ...
On Tue, Jan 03, 2006 at 04:17:20PM +0100, Sven Luther wrote: > On Tue, Jan 03, 2006 at 03:31:16PM +0100, Martin Michlmayr wrote: > > severity 343934 important > > retitle 343934 please support mips > > thanks > > * Sven Luther <[EMAIL PROTECTED]> [2006-01-03 15:24]: > > > #343934: kernel-2.6: FTBFS on mips/experimental > > > > > > Of these, #337493 ius artificial and can be closed anytime, #343260 is a > > > kernel-package/grub bug, #343443 and #343092 are the same yaird bug, > > > #343686 > > > is a kernel-package issue, and #343934 is ths's fault. > > This is not RC anyway given that it has never built on mips. > the fact that the mips/mipsel guys do their own thing in their own way is i > believe etch-RC though, and need to be solved in the next 6 month. That's a decision that needs to be made together with the people who will be doing security support for the kernel in etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote: > On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote: > > (forgot to CC d-kernel on this) > > On Tuesday 03 January 2006 22:02, Sven Luther wrote: > > > We will have a kernel which is outdated by two versions at release time > > > with this plan, since there are about 1 kernel upstream release every 2 > > > month. > > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just > > starting to get implemented). > > I remember we did consider using 2.6.10 instead of 2.6.8 and decided not > > to mainly because it was not really that much better than 2.6.8. > > As I remember it, this was a joint decision by the kernel team, release > > managers and the d-i developers. Not something that the kernel team were > > really pushing and was blocked by some assholes from the d-i team who did > > not want to cooperate. > Well, i remember joeyh vetoing it because it would take at least a month to > get the change done, and i believe we didn't really push for it because the > infrastructure was a mess back then. This has changed. > The one point that put me up, is that we should have gotten that security > update in, but this was also vetoed for the same month-long delay in the > kernel/d-i upgrade process. The kernel team has reduced that delay to less > than 24hours now for the release arches, You have been harranguing the ftp team to approve new upstream kernels through the NEW queue before they've even been uploaded -- for an amazing false optimization that burns good will with your fellow developers. Even if udebs *were* being built from the same linux-2.6 source package, this doesn't address the real reason why it's important to freeze the kernel early: *the kernel is a core component of everyone's system and detecting regressions takes a long time*. Anything that requires a reboot cycle or an installation test in order for users to detect bugs is going to need a longer testing period than other packages; the only way to ensure this happens is by freezing it early, i.e., around the same time as the toolchain packages for which we have the same problem of figuring out whether a new version is better or worse. The underlying assumption in your plea for a shorter kernel freeze is "newer is better". But people who accept this assumption unconditionally don't *run* Debian stable; so neither should we base our freeze timeline on an unconditional acceptance of it. Newer isn't necessarily better, but it is necessarily *different*, which is the enemy of stability. There is still room for targetted fixes to the kernel after the freeze date; backports of new drivers, or backports of specific bugfixes, are certainly fair game. Taking a new version of whatever upstream happens to have released would not be. > My believe is that this kind of thing should be as much automated as possible, > to let the few ressource we have be used where best it should, a little work > at the start which will pay off forever after, this is what computers and > programming is for, to make the task of the users and programmers easier, i > think we all agree with that, or we would still be using boot-floppies :) I'm all in favor of streamlining the integration of new kernel versions into the installer, but I don't believe that the majority of the work involved falls into the "automatable" category. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: bits from the release team
On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) wrote: > 1. http://lkml.org/lkml/2005/12/3/55 > Perhaps the idea of maintain a kernel with other distros is not bad, > if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire, > Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really > don't know if it is possible to mix RH, Debian, SuSE, Slackware and > other distros to maintain the same kernel, but certainly should be possible > to get all Debian (and Debian based/derivative) playing together. :-) The biggest obstacle to this is that different distributions have different and contradictory requirements for what ships in the kernel. For Debian, the obvious requirement is that everything we ship in main meets the DFSG; this is a requirement that is not shared by Ubuntu, for instance, which means any collaboration on kernels between those two distros has to allow for different bits being stripped out at the time of source package generation. It would certainly be nice to see improvements in kernel collaboration, and I believe it is possible, we just have to be honest with ourselves about the difficulties involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#346141: [Yaird-devel] Bug#346141: linux-image-2.6.15-1-k7-smp: the package doesn't configure
On Fri, Jan 06, 2006 at 01:48:13AM +0100, Sven Luther wrote: > > So why do the official 2.6.15 packages in unstable still depend on > > yaird | initramfs-tools, instead of initramfs-tools | yaird? > > Marked as "serious", because I don't believe it's acceptable to release 2.6 > > kernels for etch without a clear and automated upgrade path from sarge > > (i.e., 2.4). > svn already has initramfs-tools | yaird, as will 2.6.15-2 when it is uploaded. Ok, an easy closure for the changelog then. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
Package: linux-2.6 Version: 2.6.14-7 Severity: important Sigh, can't get a break with alpha kernel support around here. After upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works correctly on my alpha with a Matrox Millenium II. The matroxfb_base module loads without error, but gives me corrupt video output only. Card info from lspci: :00:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] and lspci -n: :00:05.0 0300: 102b:051b dmesg output: matroxfb: Matrox Millennium II (PCI) detected PInS memtype = 0 matroxfb: 640x480x8bpp (virtual: 640x6553) matroxfb: framebuffer at 0x900, mapped to 0xfc880900, size 4194304 fb0: MATROX frame buffer device fb0: initializing hardware Happy to test potential driver fixes, though due to issues with *other* hardware in this system I didn't test the framebuffer with any previous 2.6 kernels and can't tell you whether it worked with them. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Mon, Jan 09, 2006 at 10:35:18AM +0100, Sven Luther wrote: > On Mon, Jan 09, 2006 at 01:08:49AM -0800, Steve Langasek wrote: > > Package: linux-2.6 > > Version: 2.6.14-7 > > Severity: important > > Sigh, can't get a break with alpha kernel support around here. After > > upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works > > correctly on my alpha with a Matrox Millenium II. The matroxfb_base module > > loads without error, but gives me corrupt video output only. > Try turning off acceleration. Doesn't make a difference. What did make a difference was, after googling, loading fbcon manually before loading matroxfb_base. Given that I'm loading matroxfb_base by hand (/etc/modules), it's not getting loaded via udev or anything like that, it seems to me that it's my responsibility to load fbcon by hand as well, but it's still something of an unexpected change from 2.4. It might be nice to have these modules all autoloaded by something, but it's not strictly necessary, and some users may not want the framebuffer activated automatically? The other issue (and the first thing I was trying to get work, which led me to believe the fb was completely broken) is that, even though console works on the framebuffer now, X does not. This breakage corresponds to the kernel upgrade, not to any changes in X, so still looks like a kernel bug to me. If I turn off "UseFBDev" in my xorg.conf, X displays correctly. I haven't poked yet to see what this does performance-wise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware
On Mon, Jan 09, 2006 at 08:13:18PM +0100, Sven Luther wrote: > > current fact is that the qlaxxx firmware is gpl, > > so on has all it's right in main. > It is GPL, except for the binary blob of firmware, as the two constitute > separate work, this is not a violation of the GPL. The exact licence, that > this one comes under, as pointed out by Frederik and Andres on irc is in > Documentation/scsi/LICENSE.qla2xxx : > This program includes a device driver for Linux 2.6 that may be > distributed with QLogic hardware specific firmware binary file. > You may modify and redistribute the device driver code under the > GNU General Public License as published by the Free Software > Foundation (version 2 or a later version). > You may redistribute the hardware specific firmware binary file > under the following terms: > 1. Redistribution of source code (only if applicable), >must retain the above copyright notice, this list of >conditions and the following disclaimer. > 2. Redistribution in binary form must reproduce the above >copyright notice, this list of conditions and the >following disclaimer in the documentation and/or other >materials provided with the distribution. > 3. The name of QLogic Corporation may not be used to >endorse or promote products derived from this software >without specific prior written permission > Which unless someone released a heavily modified GPL licence silently in out > back, very very far from the GPL itself. Yes; this is not GPL, this is a simple BSD license. The BSD license is certainly considered free: it grants us all the redistribution and modification rights that we require in order for a work to be included in main. The only thing it doesn't grant us in this case (which is not a license issue, though the license does acknowledge the issue) is source redistribution simply because we don't have any source code. So this work is not acceptable for main if we require source code for firmware; and it is acceptable if we don't require source code for firmware. I have argued previously (on debian-legal and elsewhere) that for some types of works, such as icons, fonts, and documentation, "source code" is not important to the modifiability of a work in the same way that it is to programs. There are many cases in which the original source form used by the author is *not* the preferred form of modification for the creation of new derivative works, and it seems to me that the DFSG silently acknowledges this reality by speaking about "programs" (not the ambiguous "software") directly in DFSG #2. But of all the forms of software that we distribute which aren't normally considered "programs", firmware is certainly the most program-like. I believe the problem currently before us is, therefore, to decide whether we as a project consider firmware to be "programs" for the purposes of DFSG compliance. I am disposed to accept that they are not, but I'm not comfortable making this decision on behalf of the project ex cathedra as an RM. Instead, my plan had been to, over the next month or two, review the past discussions of this point, talk the issue over with various folks, and propose a GR that would clarify this interpretation of the DFSG where firmware is concerned. If the "discussion" part is starting now, so much the better. Please respect M-F-T to debian-project. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Mon, Jan 09, 2006 at 12:09:43PM +0100, Sven Luther wrote: > On Mon, Jan 09, 2006 at 02:51:46AM -0800, Steve Langasek wrote: > > On Mon, Jan 09, 2006 at 10:35:18AM +0100, Sven Luther wrote: > > > On Mon, Jan 09, 2006 at 01:08:49AM -0800, Steve Langasek wrote: > > > > Package: linux-2.6 > > > > Version: 2.6.14-7 > > > > Severity: important > > > > Sigh, can't get a break with alpha kernel support around here. After > > > > upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer > > > > works > > > > correctly on my alpha with a Matrox Millenium II. The matroxfb_base > > > > module > > > > loads without error, but gives me corrupt video output only. > > > Try turning off acceleration. > > Doesn't make a difference. > > What did make a difference was, after googling, loading fbcon manually > > before loading matroxfb_base. Given that I'm loading matroxfb_base by hand > > (/etc/modules), it's not getting loaded via udev or anything like that, it > > seems to me that it's my responsibility to load fbcon by hand as well, but > Indeed, if you load it by hand, you need to load fbcon also. Maybe there > should be a dependency between matroxfb and fbcon, which modprobe would then > take care of, but i guess it also makes sense to use matroxfb without fbcon, > or something. Well, depmod dependencies are based on who uses symbols from what -- obviously matroxfb doesn't *need* fbcon in order to load and be used. And one may have their console on a different video card with no framebuffer involved. If any change is to be made here to enforce auto-loading of fbcon, it seems to me that it makes more sense to just build fbcon into the kernel instead of doing dances with the initramfs managers. > > it's still something of an unexpected change from 2.4. It might be nice to > > have these modules all autoloaded by something, but it's not strictly > > necessary, and some users may not want the framebuffer activated > > automatically? > I think that if you configure yaird to load in matroxfb, it should then also > load fbcon. Well, first of all, I'm not using yaird... > > The other issue (and the first thing I was trying to get work, which led me > > to believe the fb was completely broken) is that, even though console works > > on the framebuffer now, X does not. This breakage corresponds to the kernel > > upgrade, not to any changes in X, so still looks like a kernel bug to me. > What X version are you using ? 6.8.2.dfsg.1-1; I've just upgraded to 6.9.0.dfsg.1-2, but haven't restarted anything yet. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware in the linux kernel
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote: > > In 2004, there was a GR that decided to put everything in main under the > > DFSG. We had some discussions, but in the end, the result was that all > > the non-free firmware bits have to be removed from main before we can > > release etch. > > Now, my question is: Is there still work open? If so, what? Or is the > > current removal of firmware enough, and we can relax on this topic? > 3) an effort seems to be happening inside the upstream kernel to use the > request_firmware infrastructure which allows to load firmware code from > userland through an hotplug mechanism. There seem to be more and more > drivers going this way, since there aare more in current git than in 2.6.15 > which was released a week ago, qla2xxx being among them. And this seems like a good thing; for starters it makes it easier to test different firmware versions without having to do irrelevant recompiles of kernel code. > Here is a link to the relevant wiki page about the cleaning up of messy > licences : http://wiki.debian.org/KernelFirmwareLicensing > So, basically this means we have the following options : > a) we move the whole kernel to non-free :) Essentially a non-option. > b) we move the affected modules to non-free. Well those that have their > licencing solved, the others will simply no more be distributed, or > distributed form an unofficial source. Probably overkill, and causes significant problems unless we are able to provide better infrastructure for such modules in the installer. > c) we move the firmware in non-free, and actively use the request_firmware > mechanism. Seems like a pretty good division, but if there are users who *need* the non-free firmware, we still have problems unless there's some way for them to grab it in the installer. > d) we go for a new GR, asking for an exception for the linux kernel, in > order to still stay in main, even though the firmware is non-free, arguing > that said firmware is more akin to hardware, since it replaces firmware on a > prom or flash on the expansion card, and you thus lose no freedom if we > distribute it, and the pain the other solutions will cause to ourselves and > our users. So, see my latest post to -project about that. > I think everyone agrees that a) is not a possibility. Both b) and c) require a > non-negligible amount of work, altough b) is less work than c), but c) is the > better solution, and also to the best of my knowledge the one which upstream > seems to favour, altough both may mean a long-term additional work for the > kernel-team, work which the kernel team is not really prepared to make, which > leaves d). Not sure if d) is politically right right now with regard to the > GFDL situation, but that is another issue, which will then need to be debated. I don't consider this analogous to the GFDL. The firmware question is "what format must a work be made available in for us to consider it free?" The GFDL question is "what freedoms must the copyright holder have granted to us for us to consider it free?" > Also, if we go the BSP way, it has to make clear that it had to be a long > standing and coordinated effort, since random patches of dubious quality will > probably only make matters worse for the kernel team.. Seems like a poor fit for a BSP then, IMHO. BSPs work best when you can put people to work immediately with little learning curve. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: non-free firmware
On Tue, Jan 10, 2006 at 11:38:21AM -0600, Bill Allombert wrote: > On Tue, Jan 10, 2006 at 01:45:11AM -0800, Steve Langasek wrote: > > > You may redistribute the hardware specific firmware binary file > > > under the following terms: > > > 1. Redistribution of source code (only if applicable), > > >must retain the above copyright notice, this list of > > >conditions and the following disclaimer. > > > 2. Redistribution in binary form must reproduce the above > > >copyright notice, this list of conditions and the > > >following disclaimer in the documentation and/or other > > >materials provided with the distribution. > > > 3. The name of QLogic Corporation may not be used to > > >endorse or promote products derived from this software > > >without specific prior written permission > > > Which unless someone released a heavily modified GPL licence silently in > > > out > > > back, very very far from the GPL itself. > > Yes; this is not GPL, this is a simple BSD license. The BSD license is > > certainly considered free: it grants us all the redistribution and > > modification rights that we require in order for a work to be included in > > main. The only thing it doesn't grant us in this case (which is not a > > license issue, though the license does acknowledge the issue) is source > > redistribution simply because we don't have any source code. > It is not BSD license, it does not grant the right to distribute modified > versions. > So even with the source this would still be nonfree. Hrm, true. Thanks for catching me on this; regardless of the source question, then, this particular firmware license isn't free enough for main. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347556: linux-image-2.6.15-1-alpha-generic: undefined symbols in xfs.ko on
Package: linux-2.6 Version: 2.6.15-1 Severity: grave Hah, this is special. So I tried to upgrade my kernel in order to test bug #347186, and I can't mount my /usr partition due to missing symbols in xfs.ko: $ nm -u /lib/modules/2.6.15-1-alpha-generic/kernel/fs/xfs/xfs.ko |grep cmpx U __cmpxchg_called_with_bad_pointer $ could we have build-time errors instead of clever error messages turned into symbol names please? :) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: alpha Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-alpha-generic Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: remaining linux-2.6 RC bugs ...
On Wed, Jan 11, 2006 at 10:16:59PM +0100, Moritz Muehlenhoff wrote: > Steve Langasek wrote: > >> the fact that the mips/mipsel guys do their own thing in their own way is i > >> believe etch-RC though, and need to be solved in the next 6 month. > > That's a decision that needs to be made together with the people who will be > > doing security support for the kernel in etch. > Debian's 2.6.8 kernel contains (including the upcoming sarge2 kernels) patches > for 107 distinct security problems with a CVE ID. Given that 2.6.8 was > introduced > in August 2004 and security support for Etch will end in December 2007 this > might very well be around 200 issues by the time support for Sarge fades out. > So, the bare numbers should make it pretty obvious why all archs should build > out > of the linux-2.6 package. Sorry, but it doesn't to me. The mips kernels, though built from a separate source package, use the sources from the common kernel source package via a build-dependency. Is the impact of this two-step build process really that significant to the security processes? I would have thought it was a drop in the bucket next to the work of actually preparing the security fixes themselves, and particularly for woody/sarge where we have three major versions of Linux running around. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Wed, Jan 11, 2006 at 11:28:27AM +0100, maximilian attems wrote: > > > > Sigh, can't get a break with alpha kernel support around here. After > > > > upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer > > > > works > > > > correctly on my alpha with a Matrox Millenium II. The matroxfb_base > > > > module > > > > loads without error, but gives me corrupt video output only. > > > Try turning off acceleration. > > Doesn't make a difference. > > What did make a difference was, after googling, loading fbcon manually > > before loading matroxfb_base. Given that I'm loading matroxfb_base by hand > > (/etc/modules), it's not getting loaded via udev or anything like that, it > > seems to me that it's my responsibility to load fbcon by hand as well, but > > it's still something of an unexpected change from 2.4. It might be nice to > > have these modules all autoloaded by something, but it's not strictly > > necessary, and some users may not want the framebuffer activated > > automatically? > > The other issue (and the first thing I was trying to get work, which led me > > to believe the fb was completely broken) is that, even though console works > > on the framebuffer now, X does not. This breakage corresponds to the kernel > > upgrade, not to any changes in X, so still looks like a kernel bug to me. > > If I turn off "UseFBDev" in my xorg.conf, X displays correctly. I haven't > > poked yet to see what this does performance-wise. > 2.6.15 has matroxfb patches, did it make a difference on your box? Don't know yet, thanks to bug #347556. :) On Wed, Jan 11, 2006 at 07:24:04PM +0800, Antonino A. Daplas wrote: > >> It might be nice to > >> have these modules all autoloaded by something, but it's not strictly > >> necessary, and some users may not want the framebuffer activated > >> automatically? > As long as fbcon is compiled statically, you'll get the same 2.4 behavior. I leave it to Norbert to decide what the policy should be for fbcon in the alpha kernel images. > >> The other issue (and the first thing I was trying to get work, which led me > >> to believe the fb was completely broken) is that, even though console works > >> on the framebuffer now, X does not. This breakage corresponds to the > >> kernel > >> upgrade, not to any changes in X, so still looks like a kernel bug to me. > >> If I turn off "UseFBDev" in my xorg.conf, X displays correctly. I haven't > >> poked yet to see what this does performance-wise. > The "UseFBDev" option was added to X so it can cooperate with fbcon (ie, > allows > X to restore the console state by using the fbdev API ). In 2.6, fbcon has > its > own way of restoring its own state so the "UseFBDev" option is not needed, > and in > your case, is counterproductive. Aha, didn't know that. It had been my impression that this option meant using the fbdev API for all vidcard access; but I guess that's the fbdev driver, anyway. So the real target for all of this was to get matroxfb working to the point of running bterm successfully from the debian installer; and even with fbcon working, in 2.6.14 running bterm or fbi gives me a whole lot of nothing (console blanks, nothing gets displayed). I'll give this another try with 2.6.15 once I've got my /usr partition mounting again. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347556: linux-image-2.6.15-1-alpha-generic: undefined symbols in xfs.ko on
On Tue, Jan 24, 2006 at 10:54:19PM +0100, maximilian attems wrote: > hello, > latest stable 2.6.15 has troubles with xfs on alpha, > could you please hunt that? This isn't an XFS problem, it's an Alpha problem. We've already diagnosed this on IRC, and it turns out to be due to the alpha upstream maintainers trying to out-clever the kernel's standard clever handling of "inline", which results in code that must always be inlined not always being inlined. This doesn't affect just the xfs module, it also affects drm.ko. Anyway, a tentative fix has been proposed, to use the always_inline attribute explicitly for this function, but it remains to be implemented -- I don't have space here to do test kernel builds for alpha without doing a lot of shuffling, and nobse hasn't gotten back to me on it since the day we had that discussion on IRC. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
Package: linux-2.6 Version: 2.6.14-7 So unaligned traps in kernel logs are a frequent complaint on debian-alpha, and it's a PITA to turn these into real bug reports against the programs responsible because there's no tool in the archive to let you change the kernel handling of the unaligned traps; instead, people end up passing around C snippets that do the job. Having seen the nice prctl package, which is currently ia64-only, I decided to see if I could get it to compile on alpha. Lo and behold, it seems that /usr/include/linux/prctl.h (from linux-kernel-headers) is a nice, generic header that defines a nice, generic prctl() syscall that can be used for adjusting unaligned trap handling. Hurray! But, um... it doesn't work. prctl(0x5, 0x11fd45610, 0x120001bb2, 0x1200122b8, 0) = -1 EINVAL (Invalid argument) So please make it work; knowing this exists and should be supported, I'm not willing to hack up prctl's source to use __NR_osf_setsysinfo instead. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Tue, Jan 24, 2006 at 10:42:06PM -0500, Kyle McMartin wrote:
> On Tue, Jan 24, 2006 at 07:06:00PM -0800, Steve Langasek wrote:
> > So please make it work; knowing this exists and should be supported, I'm not
> > willing to hack up prctl's source to use __NR_osf_setsysinfo instead. :)
> Untested, as I don't have an alpha. arch/alpha/kernel/traps.c already
> contained jazz to check if the various TIF_ were set, they were just
> lacking a convenient way to set things. You probably need to make prctl()
> know which bits to twiddle.
> diff --git a/include/asm-alpha/thread_info.h b/include/asm-alpha/thread_info.h
> index 69ffd93..011daaf 100644
> --- a/include/asm-alpha/thread_info.h
> +++ b/include/asm-alpha/thread_info.h
> @@ -92,5 +92,20 @@ register struct thread_info *__current_t
> #define _TIF_ALLWORK_MASK(_TIF_WORK_MASK \
>| _TIF_SYSCALL_TRACE)
>
> +#define ALPHA_UAC_SHIFT 6
> +#define ALPHA_UAC_MASK (TIF_UAC_NOPRINT | TIF_UAC_NOFIX | \
> + TIF_UAC_SIGBUS)
> +
> +#define SET_UNALIGN_CTL(task,value) ({ \
> + (task)->thread_info->flags = (((task)->thread_info->flags & \
> + ~ALPHA_UAC_MASK) | (((value) << ALPHA_UAC_SHIFT) & \
> + ALPHA_UAC_MASK)); \
> + 0; })
> +
> +#define GET_UNALIGN_CTL(task,value) ({ \
> + put_user(((task)->thread_info->flags & ALPHA_UAC_MASK) >> \
> + ALPHA_UAC_SHIFT, (int __user *)(addr)); \
> + })
> +
> #endif /* __KERNEL__ */
> #endif /* _ALPHA_THREAD_INFO_H */
CC kernel/sys.o
kernel/sys.c: In function ‘sys_prctl’:
kernel/sys.c:1798: error: ‘addr’ undeclared (first use in this function)
kernel/sys.c:1798: error: (Each undeclared identifier is reported only once
kernel/sys.c:1798: error: for each function it appears in.)
kernel/sys.c:1798: warning: type defaults to ‘int’ in declaration of ‘__pu_addr’
kernel/sys.c:1798: warning: type defaults to ‘int’ in declaration of ‘type name’
kernel/sys.c:1798: warning: type defaults to ‘int’ in declaration of ‘type name’
kernel/sys.c:1798: warning: type defaults to ‘int’ in declaration of ‘type name’
kernel/sys.c:1798: warning: type defaults to ‘int’ in declaration of ‘type name’
make[5]: *** [kernel/sys.o] Error 1
Should be 'value' instead of 'addr', I guess?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Tue, Jan 24, 2006 at 10:42:06PM -0500, Kyle McMartin wrote: > On Tue, Jan 24, 2006 at 07:06:00PM -0800, Steve Langasek wrote: > > So please make it work; knowing this exists and should be supported, I'm not > > willing to hack up prctl's source to use __NR_osf_setsysinfo instead. :) > > > Bleh. > Untested, as I don't have an alpha. arch/alpha/kernel/traps.c already > contained jazz to check if the various TIF_ were set, they were just > lacking a convenient way to set things. You probably need to make prctl() > know which bits to twiddle. After changing addr to value, compiles fine; prctl -q runs ok now, prctl --unaligned=signal doesn't have any effect. You say that it's going to be the prctl() function in the kernel that needs further tweaks? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
tags 349765 patch
thanks
On Sat, Jan 28, 2006 at 01:48:21AM -0500, Kyle McMartin wrote:
> > After changing addr to value, compiles fine; prctl -q runs ok now, prctl
> > --unaligned=signal doesn't have any effect. You say that it's going to be
> > the prctl() function in the kernel that needs further tweaks?
> I suspect this is the problem:
> (linux/prctl.h)
> # define PR_UNALIGN_NOPRINT 1 /* silently fix up unaligned user
> accesses */
> # define PR_UNALIGN_SIGBUS2 /* generate SIGBUS on unaligned user
> access */
> (asm-parisc/processor.h & asm-ia64/processor.h)
> #define PARISC_UAC_NOPRINT(1UL << 0) /* see prctl and unaligned.c */
> #define PARISC_UAC_SIGBUS (1UL << 1)
> IE, NOPRINT is set by 1, and SIGBUS set by 2.
> on alpha, because it's reusing the OSF/1 crap, the order is
> NOPRINT, NOFIX, SIGNAL, ie: 1, 2, 4.
> I don't know what the best way to fix this is, but something like
> this patch will probably help,
As discussed, I think it's more appropriate to fix this in the kernel, so
that the syscall behavior actually matches what's documented in
linux/prctl.h. :) So here's a tested patch which does this. Ugly as sin,
but I'm at a loss for how you'd make this pretty...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff --git a/include/asm-alpha/thread_info.h b/include/asm-alpha/thread_info.h
index 69ffd93..011daaf 100644
--- a/include/asm-alpha/thread_info.h
+++ b/include/asm-alpha/thread_info.h
@@ -92,5 +92,27 @@ register struct thread_info *__current_t
#define _TIF_ALLWORK_MASK (_TIF_WORK_MASK \
| _TIF_SYSCALL_TRACE)
+#define ALPHA_UAC_SHIFT6
+#define ALPHA_UAC_MASK (1 << TIF_UAC_NOPRINT | 1 << TIF_UAC_NOFIX | \
+1 << TIF_UAC_SIGBUS)
+
+#define SET_UNALIGN_CTL(task,value)({ \
+ (task)->thread_info->flags = (((task)->thread_info->flags & \
+ ~ALPHA_UAC_MASK) \
+ | (((value) << ALPHA_UAC_SHIFT) & (1 << TIF_UAC_NOPRINT))\
+ | (((value) << ALPHA_UAC_SHIFT + 1) & (1 << TIF_UAC_SIGBUS)) \
+ | (((value) << ALPHA_UAC_SHIFT - 1) & (1 << TIF_UAC_NOFIX)));\
+ 0; })
+
+#define GET_UNALIGN_CTL(task,value)({ \
+ put_user(((task)->thread_info->flags & (1 << TIF_UAC_NOPRINT)) \
+ >> ALPHA_UAC_SHIFT\
+| ((task)->thread_info->flags & (1 << TIF_UAC_SIGBUS)) \
+ >> ALPHA_UAC_SHIFT + 1\
+| ((task)->thread_info->flags & (1 << TIF_UAC_NOFIX)) \
+ >> ALPHA_UAC_SHIFT - 1, \
+(int __user *)(value));\
+ })
+
#endif /* __KERNEL__ */
#endif /* _ALPHA_THREAD_INFO_H */
signature.asc
Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 12:32:21AM +0100, Marco d'Itri wrote: > Now that 2.6.15 kernels are in testing I'd like to raise the kernel > requirement for the udev package from 2.6.12 to 2.6.15 as soon as a new > version of udev will have entered testing. > This will let me remove a lot of cruft from the package. > Does anybody have a reason to wait some more time? Aside from it being a pain in my ass personally to have to constantly reboot to continue using a non-chrooted up-to-date unstable system for development, I suppose it doesn't make much difference whether 2.6.12 or 2.6.15 is the break point, no. :P -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#352186: LEGACY_START should not be set on alpha
Package: linux-2.6 Version: 2.6.15-5 Severity: important On Thu, Feb 09, 2006 at 05:46:01PM -0500, Jay Estabrook wrote: > On Wed, Feb 08, 2006 at 01:51:45AM -0800, Steve Langasek wrote: > > As of two days ago, the debian-installer svn tree has been switched to use > > Linux 2.6.15 exclusively on alpha, instead of the previous 2.4.27. This > > means that with the most recent daily builds, all installer images for alpha > > are using 2.6 kernels *only*, and the current plan is that d-i beta2 will be > > the same. If you haven't tried 2.6 on your alpha yet, now would be a good > > time so you can let us know if it doesn't work before we drop 2.4 for etch > > completely. > Tried the netinstall CD from 02/07/06 on LX164, and found the following: > 1. installer used 2.6.15 kernel with LEGACY_START option > 2. installed kernel 2.4.27 with LEGACY_START option > Neither of those will boot on DS15/DS25/ES45 (among others) because of > the LEGACY_START. > AFAIK, all SRM console machines will boot kernels without LEGACY_START. > Only MILO-based machines require LEGACY_START. Yep, we're all in agreement that LEGACY_START should be disabled in the standard image flavor, and even that this should have been done a while ago; and that a new "legacy" flavor (name TBD) should be added for MILO systems requiring the different load address. Opening a reminder bug, as discussed with Norbert on IRC. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:45:04AM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 07:57:25AM +0100, Sven Luther wrote: > > We need something which upgrades seamlessly, and the above solution is not > > acceptable for the etch release, as has been said already in the past. > Hmm. Are there problems with the following: > - Upgrade works but asks the not yet completed dkt to disable old images > which raises a big fat warning that it needs a reboot. Context from IRC: 01:55 < svenl> waldi: dkt ? 01:56 < waldi> svenl: the piece of software I just work on 01:56 < vorlon> which does what? 01:56 < waldi> https://lophos.multibuild.org/svn/dkt/trunk/doc/design 01:56 < waldi> it is mostly a generic replacement of update-grub Anyway, I don't see that this is a very good solution. Disabling all of the available boot options for the system doesn't prevent incidental breakage, it just changes the *kind* of incidental breakage you get. The *least* bad solution we have today is that some packages (lvm, udev) refuse in the preinst to continue being installed when upgrading from sarge (lvm for upgrades from either 2.4.27 or 2.6.8; udev from 2.6.8 only), and then the user is left to figure out how to get a viable 2.6.1x kernel package onto their system after a dist-upgrade has left God knows how many packages in an unconfigured or inconsistent state. Anything that introduces the possibility of the system breaking on reboot/power failure is *worse* than this. > - Refuse to start on startup if no compatible version is found. What does this mean, exactly? Should that be "upgrade" instead of "startup"? And how does that help us improve users' experience when upgrading? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 12:07:11PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 02:37:21AM -0800, Steve Langasek wrote: > > Anyway, I don't see that this is a very good solution. Disabling all of the > > available boot options for the system doesn't prevent incidental breakage, > > it just changes the *kind* of incidental breakage you get. > It makes it impossible to break by accident. It don't help against hand > made breakages. This is a social problem which can't be fixed by a > technical solution. Then what does this have to do with the problem people are trying to solve? The problem is that there is *no* kernel available in sarge that meets the needs of the etch udev and lvm packages, and as a result people have to install a new kernel, reboot, and then continue with the upgrade -- and failing to follow these directions means hours of pain trying to recover from an interrupted dist-upgrade (in particular for those users who have little or no dpkg knowledge/experience). > > Anything that introduces the possibility of the system breaking on > > reboot/power failure is *worse* than this. > Hu? The kernel image have to be configured already. *What* kernel image? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 01:41:55PM +0100, Sven Luther wrote: > On Fri, Feb 10, 2006 at 11:27:12AM +0100, Marco d'Itri wrote: > > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > We need something which upgrades seamlessly, and the above solution is not > > > acceptable for the etch release, as has been said already in the past. > > This would be nice, but so far nobody has been able to design anything > > better, myself included. > Yeah, but more heads together searching actively may find a solution where > people alone have not. > More to this later, as i am busy, just a few comments now. > > > Is it not possible to have a newer udev which is not removing the older > > > udev, > > > so you have both installed, and the older udev will work with older > > > kernels > > > and the newer udev will work with newer kernels ? > > I do not believe that this would be possible, at least for the general > > case, because the version of udev in stable is almost a different > > program with different interfaces with other system components. > Notice, the only case we really have to deal with is the case where the system > is already running with a 2.6.8 (or random self built) kernel, using the older > udev, and we are installing a newer kernel and udev. > The 2.6.8 kernel is already running, and the kernel upgrade needs a reboot > anyway, so, we only need something that : > - don't mess up the currently running stuff, is it possible to have udev > installed to take effect after the next reboot, and keep the old udev live > until then ? > - installs without trouble. > - works fine when the newer kernel is booted into. - Doesn't fuck the system if you lose power part-way through the dist-upgrade after udev has been unpacked and no newer kernel has been installed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 07:54:01PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 03:45:28AM -0800, Steve Langasek wrote: > > Then what does this have to do with the problem people are trying to solve? > > The problem is that there is *no* kernel available in sarge that meets the > > needs of the etch udev and lvm packages, and as a result people have to > > install a new kernel, reboot, and then continue with the upgrade > No, they need to reboot after installing udev/lvm, not before. Then you've once again left the user without any assurance that their system is bootable at the end of the udev/lvm install. We *must* avoid leaving the user in a state where rebooting the system could leave /usr and /var unmountable, the network inaccesible, and so on. > > > Hu? The kernel image have to be configured already. > > *What* kernel image? > Which should be used. I don't see anywhere you've specified a mechanism for determining what kernel image this is, or ensuring that it is configured first. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:45:23PM +0100, Sven Luther wrote: > On Fri, Feb 10, 2006 at 01:21:22PM -0800, Steve Langasek wrote: > > - Doesn't fuck the system if you lose power part-way through the > >dist-upgrade after udev has been unpacked and no newer kernel has been > >installed. > Hehe, never thougth about that. i guess that having udev depend on a kernel > image of at least version foo, you solve this problem. > Naturally, if you have i-t include klibc and udev, then you are faced with a > chicken-and-egg problem :) Yes, that's the circular dependency loop bug that's currently open on these packages. AIUI, maks has already agreed to try to break this loop by making i-t work with older udev. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 10:57:27PM +0100, Bastian Blank wrote: > On Fri, Feb 10, 2006 at 01:30:51PM -0800, Steve Langasek wrote: > > > No, they need to reboot after installing udev/lvm, not before. > > Then you've once again left the user without any assurance that their system > > is bootable at the end of the udev/lvm install. > Which is the same than the other way around. (For example the device > mapper api version changed around 2.6.5 and older devmapper versions was > not longer able to work.) Does this mean that the sarge lvm2 package doesn't work with kernels from etch? If so, then bug #351679 *is* RC. > > We *must* avoid leaving the > > user in a state where rebooting the system could leave /usr and /var > > unmountable, the network inaccesible, and so on. > The old initrd is not changed at this time and can mount at least /. This means you're not guaranteed to get /usr/sbin/sshd, which many admins use exclusively for system administration where remote kvm is not an affordable option. That's a pretty big problem. > > > Which should be used. > > I don't see anywhere you've specified a mechanism for determining what > > kernel image this is, or ensuring that it is configured first. > Hu? The stated problem is that upgrades from sarge to etch require the user to go to a bunch of extra work to change out their kernel before they can dist-upgrade. I haven't heard you say "lvm will depend on the linux-image package it needs", or anything equivalent, which means the preinst check for running kernel version is the only protection against a completely broken system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Fri, Feb 10, 2006 at 04:52:50PM +0100, Marco d'Itri wrote: > On Feb 10, Sven Luther <[EMAIL PROTECTED]> wrote: > > > > 1) sarge-udev & etch-udev install concurently, maybe using the divert > > > > or > > > > alternative mechanism to not overwrite their files. > > > As I explained, I do not believe that on-disk co-existence of two udev > > > packages is feasible. > > Mmm, even if for a short time as planed here ? > I can't see how this would change anything. > > Well, less than 6 months now, so now is the best time to handle this. We > > still > > need to tackle the out-of-tree module issues, and the non-free firmware too. > FWIW, I plan to propose a GR to allow temporary distribution of > binary-only firmwares on our official install media. Why temporary, out of curiosity? This doesn't seem like a temporary problem; I think this is an issue that will be just as applicable for etch+1 as it is for etch, and I think we should be honest about that. I also think it's within the realm of reason for us to decide that source for things like firmware, fonts, and documentation is less important than it is for programs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#352765: linux-2.6: wrong drivers for tulip PCI IDs on alpha?
Package: linux-2.6 Version: 2.6.15-6 Currently, the modules.pcimap for DEC tulip chips is as follows: tulip0x1011 0x0009 0x 0x 0x 0x 0x0 tulip0x1011 0x0019 0x 0x 0x 0x 0x0 de2104x 0x1011 0x0002 0x 0x 0x 0x 0x0 de2104x 0x1011 0x0014 0x 0x 0x 0x 0x0 lmc 0x1011 0x0009 0x1376 0x 0x 0x 0x0 lmc 0x1011 0x0009 0x 0x1376 0x 0x 0x0 Presently, neither de2104x nor lmc is being included in the installer images for etch; this is because discover1-data lists de4x5 as the module for *all* of these PCI IDs. With the switch to 2.6 in d-i, this means that a number of common NICs for alpha (0002, 0014, 0009) are not being auto-detected by udev. The de4x5 module *can* be loaded by hand on my own system (1011:0002), and appears to work correctly; this is the driver that I've been using under 2.6 on my installed system. I am also now testing de2104x; so far, it does appear to work. The apparent trade-off between de2104x is that de4x5 does not support full-duplex mode, whereas I have some vague impression that de2104x didn't work on my system in some earlier driver revision. However, the discover1-data changelog doesn't support this; it mentions that 1011:1002 uses de4x5 because of bug #273265, which was about tulip, not de2104x -- and tulip doesn't detect my card at all, so there's no doubt that *that* is the wrong driver. Recent discussion of this issue on debian-alpha included the following response froman Alpha expert at HP: --- From: Jay Estabrook <[EMAIL PROTECTED]> To: debian-alpha@lists.debian.org Subject: Re: testing wanted: debian-installer, now with 2.6.15 Date: Mon, 13 Feb 2006 10:53:43 -0500 On Sun, Feb 12, 2006 at 03:41:24AM -0800, Steve Langasek wrote: > So should the 21040 and 21041 be switched from de2104x to de4x5, or should > de2104x be added to the installer? I seem to recall that I had problems > with de2104x on my 21040 as well; and at least in 2.6.15, the tulip driver > doesn't work at all for my card, I have to use de4x5. > The discover1-data package seems to have de4x5 listed for *all* of these PCI > IDs, but I think we may be using the kernel's map now with 2.6 (via udev). I don't know of any problems using "tulip" on the 2114x chipsets. And I don't think full duplex will significantly increase the throughput of a 2104x chipset, so, yes, I'd think that using de4x5 for any 2104x and tulip fo any 2114x might be the way to go... --- We probably shouldn't make that change in Debian without talking to whoever's responsible for these drivers upstream, though. In the meantime, I'm going to add de2104x into the d-i images. This bug report is opened to collect success/failure reports regarding the current driver mappings, so we can be sure we're making an informed decision about these historically-problematic PCI IDs. For the record, de4x5 is currently not referenced in modules.pcimap at all, so depending on the outcome of this bug report, it may make sense to drop it completely from the 2.6 build... Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#353079: linux-2.6.15-1-alpha-generic: srm_env broken, returns EFAULT
Package: linux-2.6
Version: 2.6.15-4
In all versions of 2.6 that I've tested with d-i to date, srm_env no longer
works correctly. Attempting to query any variables from
/proc/srm_environment on alpha gives a "Bad address" error:
$ cat /proc/srm_environment/named_variables/language
6cat: /proc/srm_environment/named_variables/language: Bad address
$
strace shows:
open("/proc/srm_environment/named_variables/language", O_RDONLY) = 3
fstat64(0x3, 0x11fc49798) = 0
read(3, "6\0\0\0", 1024)= 4
write(1, "6\0\0\0", 46) = 4
read(3, 0x120018000, 1024) = -1 EFAULT (Bad address)
With coreutils cat, it does at least output the contents ("6") before
exiting with the error; with busybox cat, there is no output, breaking
language autodetection in the installer.
This worked fine with 2.4.27.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: making udev require 2.6.15 kernels
On Sat, Feb 11, 2006 at 08:11:34AM +0100, Sven Luther wrote: > On Fri, Feb 10, 2006 at 04:20:02PM -0800, Steve Langasek wrote: > > This means you're not guaranteed to get /usr/sbin/sshd, which many admins > > use exclusively for system administration where remote kvm is not an > > affordable option. That's a pretty big problem. > Maybe we need a sshd in /sbin then, since as i understand there is no real > guarantee that /usr is mounted always in case of problems ? No, we need to do a good job of *ensuring the system is safely rebootable at all times*. Why should we be satisfied with upgrades that have to come with a big warning label, "system may not boot back up completely if you leave your desk for coffee and the power goes out"? I think we have every right to expect more from Debian (and ourselves) than that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#353717: kernel-latest-powerpc: it's definitely not the latest, and it should go away
Package: kernel-latest-powerpc Version: 102 Severity: serious The kernel-latest-powerpc package hasn't been updated since March 2005. It's not the "latest" at all; its 2.6 metapackages depend on 2.6.8, which is preventing the old 2.6.8 powerpc kernels from being removed from testing, and its 2.4 metapackages depend on other packages that no longer exist in unstable. This source package appears to not serve any purpose at all today. If you can confirm, please reassign this bug to ftp.debian.org to request removal. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#353809: initramfs-tools: Silently destroys yaird initrd image on package update
On Tue, Feb 21, 2006 at 04:15:02AM +0100, Jonas Smedegaard wrote: > Package: initramfs-tools > Version: 0.52b > Severity: critical > Justification: breaks unrelated software Um. How does this "break unrelated software"? It doesn't respect the policy set in /etc/kernel-img.conf, and it overwrites the initrd image without asking, but what *broke*? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#353809: initramfs-tools: Silently destroys yaird initrd image on package update
On Tue, Feb 21, 2006 at 09:19:29AM +0100, Bastian Blank wrote: > On Mon, Feb 20, 2006 at 07:49:42PM -0800, Steve Langasek wrote: > > Um. How does this "break unrelated software"? > Yes. The kernel image depends on both. So yaird is unrelated to > initramfs-tools. > > It doesn't respect the > > policy set in /etc/kernel-img.conf, and it overwrites the initrd image > > without asking, but what *broke*? > It breaks booting of all images. *How*? Nothing in this report has described actual breakage. If using initramfs-tools to generate initramfs images prevents the system from booting, that is indeed a critical bug, but that's not the bug that Jonas filed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#354124: 8139too fails to receive packets
reassign 354124 kernel-image-2.4.27-2-386 thanks On Thu, Feb 23, 2006 at 07:16:14AM -0800, Matt Kraai wrote: > Package: nic-extra-modules-2.4.27-2-386-di > Version: 1.04 > The 8139too driver does not appear to be able to receive packets. > Using tcpdump on another system, I verified that it is able to send > DHCP requests and that the DHCP server sends responses, but there is > no indication that they are ever received on the system using the > 8139too driver. You seem to be reporting this against the stable version of the package, which means it's unlikely to be fixed... anyway, nic-extra-modules just repackages the module from the kernel image, so let's reassign it there. Does this driver work for you if you boot with the "linux26" option? Does it work with the etch installer? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#349354: why not yaird by default?
On Fri, Feb 24, 2006 at 04:24:55PM -0500, Mike O'Connor wrote: > Is there any drawback to just switching the default dependency to be on > yaird instead of initramfs-tools? Yes. You can't install yaird on upgrade from a 2.4 kernel. And currently, you can't install initramfs-tools on upgrade from a 2.6.8 kernel. In each case there are workarounds, but we really want to be able to break this dependency loop. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:32:10PM +0100, Guido Trotter wrote: > On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: > > It is a sort of kernel. > Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the > kernel team is about the linux kernel, not just any kernel, isn't it? The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If Debian is to provide a complete packaged environment for Xen, which is certainly the goal I'm interested in (and Bastian as well, by the looks of it), that means packaging (at least) a dom0 kernel; and the only way to do that which would make the cut for stable is if it's kept synchronized with the main linux-2.6 package. I think the only reasonable way to do that is within the kernel team, which means people interested in helping with this part should consider joining the kernel team. For the userspace tools and the hypervisor, clearly there's no reason why these need to be part of the kernel team repo as long as they aren't going to be part of the same linux-2.6 source package. As Bastian points out, though, there does still need to be close coordination between the hypervisor/userspace tools and the XenoLinux build, because we don't yet have mix-and-match compatibility. My feeling is that it still makes sense to maintain the hypervisor and userspace tools in a separate pkg-xen group, and just coordinate between the kernel and xen teams for this; but that should be sorted out among those doing the work. I certainly can't see any benefits in terms of source management to having them in the same svn repo with the kernel, anyway. > > Just to say, how connected xen to linux is: > > For example: There are three kernel trees of xen: > > - from xen-3.0-testing, 2.6.12 > > - from linux-2.6-xen, 2.6.16-rc4 > > - from linux-2.6-merge, 2.6.16-rc3 > > All of them have different needs from xen. And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? > > The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 > > and unstable hypervisor. > > The 3.0 utils only works on the kernel from xen-3.0-testing. The > > unstable utils with the other. But with both hypervisors. > That's I think because xen is still young, and is starting just now its > distribution integration, and probably will happen a lot less when it will be > integrated with Linux (Linus' tree) and the development of xenolinux will > proceed at a different pace than the hypervisor. Then probably it will just be > that any xen version will have a minimum linux version needed, just as now a > lot > of other stuff does, and there will be nothing special in it, except the fact > that it needs a kernel compiled for the appropriate subarch). In the meantime, to the extent this is an issue it probably means that some of this stuff isn't ready for inclusion in etch. I don't see a point in uploading two versions of xen to unstable, certainly, if they aren't both going to work with the provided kernels. > What do other people in the kernel team think? If the majority of them agree > fine, otherwise are you sure it's not counterproductive to force xen in the > kernel team hands if most of them don't want to touch it, and on the other > hand > to risk driving away other people who just cannot follow the whole linux > business but could work on the xen hypervisor and tools, help coordinate with > xen's upstream, debian glibc and d-i, etc! Especially if you and other people > who would do both can still do it! :) As an erstwhile contributor to the kernel team who's also interested in Xen packaging, you have my answer above... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:22:23PM +0100, Guido Trotter wrote: > > The debian kernel team will maintain xen images with the linux-2.6 > > source. I currently prepare both xen 3.0 and unstable packages, which > > can be hopefully uploaded today. Maintainer will be the kernel team, as > > there are heavy dependencies between xen and the kernel. > This is great! In the meantime we are working on uploading xen 3.0 to > unstable, > and our packages I think are almost ready too! We planned to contact the > kernel > team after the upload to see how to coordinate, but it's nice to know that the > kernel part is being taken care of! :) > Our packages don't contain any kernel (we wouldn't have uploaded them without > asking the kernel team, of course) but we plan on shipping just the xen patch > for a kernel.org kernel, just in case someone preffers running a non-debian > kernel: is that OK, or should we remove that from our sources? FWIW, the policy on kernel patches for sarge was that if it didn't apply to the kernel sources we shipped, it didn't need to be included as a package in stable. We're obviously not shipping a 2.6.12 kernel for etch, so I wouldn't bother uploading that part... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#352765: linux-2.6: wrong drivers for tulip PCI IDs on alpha?
On Mon, Feb 27, 2006 at 01:12:50PM +, Stuart T. R. Rowan wrote: > My old alphastation 200 4/166 needs de4x5 for the onboard ethernet. Last > time I did an install, I think discover tried to use de2104x which just > didn't work, it modprobed, found it but no traffic etc. Could you please confirm that this is the case with the current 2.6.15 kernel in unstable? I don't want to recommend a change to the upstream kernel driver maps based only on unconfirmed, historical problems with the de2104x driver. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote: > On Mon, 27 Feb 2006, Guido Trotter wrote: > > Absolutely true! The current xen team is fully agrees on this position! > xen 3.0 is out since the 6th of december! > so it has seen considerable amount of production use since. > as the xen userspace is tightly integrated to the xen kernel, > it makes a lot of sense to release both in the same run. But it doesn't make sense to release them both as part of the same source package, and it doesn't necessarily make sense to keep them in the same svn repo. Can you explain why it's better for the xen userspace/hypervisor packages to be kept under the aegis of the kernel team, instead of for Bastian (and other interested developers) to join the pkg-xen team? Is there really so much more interest in the xen-tools among the members of the kernel team than among the, er, Xen team? > the debian kernel team has always been open to valuable input. > beeing just annoyed and threatening to bypass on weblog doesn't > put your team on a good light. Holding all the members of the pkg-xen team responsible for what one of their fellows has written in his blog would be petty and immature, and would not exactly be the kind of encouragement one would hope to see from the kernel team seeking the input of others interested in Xen packaging. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: jonas, you are being dishonest.
On Tue, Mar 07, 2006 at 02:15:56PM +0100, Sven Luther wrote: > I am severly disapointed with you, and you are a liar by claiming that i > didn't hear your arguments, i did hear them, and when i tried to give mines, > you refused to continue the conversation. I remember well your arguments, and > they where nothing to be proud of, you basically claimed that : This kind of petty bickering has no place in the technical committee (or, for that matter, in the BTS at all). You have submitted a technical issue to the TC, and we will consider it; personal attacks on the package maintainer are irrelevant, and a waste of both your time and ours which will only delay the process of the tech ctte reaching a decision as we are forced to sift through this nonsense. If you can't limit yourself to civilly presenting relevant technical information, then I would recommend that you keep quiet altogether until the committee asks for your input. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Wed, Mar 08, 2006 at 10:35:38PM -0800, Jurij Smakov wrote: > On Thu, 9 Mar 2006, Sven Luther wrote: > >As quoted from http://wiki.debian.org/LinuxKernelIdeProblem, it is no clear > >that ide-generic and via82cxxx to take only one example do exactly the same > >thing, and there is no way both could be needed at the same time, and in > >fact > >it is contrary, what do i say, anathema, to both the linux ide layer and > >the > >yaird design document, to even imagine that. > I've independently done the analysis of the IDE layer initialization and > can confirm the technical part of Sven's conclusion: ide-generic takes > over all hardware interfaces (hwifs), which do not have the 'present' flag > set in their corresponding entry in the ide_hwifs[] structure. Normally, > the native IDE drivers set this flag during their initialization (via82cxxx > does it through the chain of calls ide_setup_pci_device() -> > probe_hwif_init_with_fixup() -> hwif_init()). So, if ide-generic is loaded > last, it will pick up only the interfaces, which have not been claimed by > any native drivers, which is the desired result. Looking at the code I > cannot see how the native drivers can depend in any way on the ide-generic > being loaded before them. What version of the kernel was this analysis done with? The workaround in yaird is explicitly commented as existing for the benefit of older kernel versions; can you assure us that this aspect of the driver design is unchanged from 2.6.8 through 2.6.15? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: [Yaird-devel] Re: Bug#345067: ide-generic on poweprc
On Thu, Mar 09, 2006 at 12:52:24PM +0100, Sven Luther wrote: > If you think developper of embedded distros will use yaird over tools like > buildroot and co, you are severly deluded and have no idea about that milieu. > Furthermore, you are making a mountain about a imaginary bug, and are not even > able to go looking at the archives of back then and see what the real problem > was, but just bother other folk until they make the job for you out of sheer > spite. Once again, this bug report is not a stage for your personal conflict. If it's not a new technical argument relevant to the technical committee's decision making process, please don't waste our time by sending it. It seems like you never mind repeating yourself, but I do mind when *I* have to repeat *my*self. If you continue to fill my mailbox with posts that have nothing to do with the actual bug we've been asked to rule on, I'll reassign it back to yaird and you can take as long as you want to resolve it via your private war, since that seems to matter more to you than actually persuading the TC. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Thu, Mar 09, 2006 at 09:44:51AM -0800, Jurij Smakov wrote: > >What version of the kernel was this analysis done with? The workaround in > >yaird is explicitly commented as existing for the benefit of older kernel > >versions; can you assure us that this aspect of the driver design is > >unchanged from 2.6.8 through 2.6.15? > That's a good point. I was looking at the latest kernel (2.6.15), and > Frans and Anthony mentioned that ide-generic was neccessary in the past. > I'll try to figure it out. Ok, thanks for your work on this, Jurij. And to answer Sven's question, On Thu, Mar 09, 2006 at 11:08:33AM +0100, Sven Luther wrote: > > What version of the kernel was this analysis done with? The workaround in > > yaird is explicitly commented as existing for the benefit of older kernel > > versions; can you assure us that this aspect of the driver design is > > unchanged from 2.6.8 through 2.6.15? > Steve, what is the interest of doing this ? We only have 2.6.15 currently in > sid/etch, and sarge uses 2.6.8 together with initrd-tool, so it is a > non-issue. Whether this workaround is needed for older kernels is a technical factor. You may not consider supporting older kernels worthwhile (and neither do I in this case, really), but it's clear that Jonas *does* consider it important; if he didn't, there would obviously be no need to overrule Jonas at this point. Since he does, it's important that we have as much information as possible about this case in order to make an informed decision. Reaching a technical solution that satisfies both parties should *always* be preferred over forcing a maintainer to do something he disagrees with. But even if that's not possible, we still have a responsibility to base our decision on as clear a picture of the evidence as possible. I've done a little poking of my own at sysfs based on the comments in the yaird code. I can confirm that it is possible for a PCI IDE driver to be listed as associated with a PCI device without actually being the driver used to access the device. This happens on my alpha, where ide-generic must be used due to bugs in the cmd64x driver, yet running modprobe cmd64x does show this driver associated with the PCI device: $ ls -l /sys/devices/pci\:00/\:00\:0b.0/driver lrwxrwxrwx 1 root root 0 2006-03-09 19:46 /sys/devices/pci:00/:00:0b.0/driver -> ../../../bus/pci/drivers/CMD64x_IDE $ However, /sys/block/hda/device still points to the right place, and it's my understanding that /sys/block is what yaird walks, so this still is no explanation for how someone could have mis-identified a bug in this area. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 08:10:12AM +0100, Sven Luther wrote: > > I've done a little poking of my own at sysfs based on the comments in > > the yaird code. I can confirm that it is possible for a PCI IDE driver > > to be listed as associated with a PCI device without actually being the > > driver used to access the device. This happens on my alpha, where > > ide-generic must be used due to bugs in the cmd64x driver, yet running > > modprobe cmd64x does show this driver associated with the PCI device: > > $ ls -l /sys/devices/pci\:00/\:00\:0b.0/driver > > lrwxrwxrwx 1 root root 0 2006-03-09 19:46 > > /sys/devices/pci:00/:00:0b.0/driver -> > > ../../../bus/pci/drivers/CMD64x_IDE > Mmm. When this was happening, could you use and mount partition on this > device ? > And when doing so, do you know which of ide-generic or cmd64x would be used to > read the drive ? Are you suggesting that loading cmd64x has changed which driver is associated with /dev/hda, even though the machine has partitions mounted from it at the time? > And again, is the right thing to do here, not to fix those cmd64x bugs ? Um, that's completely missing the point. The point of this exercise was to try to rule out a possible explanation for the yaird workaround. Which I did. > > However, /sys/block/hda/device still points to the right place, and it's my > > understanding that /sys/block is what yaird walks, so this still is no > > explanation for how someone could have mis-identified a bug in this area. > How does it find the device and then the driver starting from block ? $ readlink /sys/block/hda/device ../../devices/ide0/0.0 $ So we should expect yaird to only load ide-generic on this system, since cmd64x, while loaded, is not associated with the root device (according to sysfs or otherwise). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#345067: My understanding of the IDE mess, and why it does not make sense to apply the proposed patch
On Fri, Mar 10, 2006 at 09:49:18AM +0100, Sven Luther wrote: > > > Mmm. When this was happening, could you use and mount partition on this > > > device ? > > > And when doing so, do you know which of ide-generic or cmd64x would be > > > used to > > > read the drive ? > > Are you suggesting that loading cmd64x has changed which driver is > > associated with /dev/hda, even though the machine has partitions mounted > > from it at the time? > No, i am wondering what /sys/devices/pci:00/:00:0b.0/driver was > pointing too previous to cm64x being loaded. Nothing: there is no driver associated with the PCI device. > > > And again, is the right thing to do here, not to fix those cmd64x bugs ? > > Um, that's completely missing the point. The point of this exercise was to > > try to rule out a possible explanation for the yaird workaround. Which I > > did. > He, ... > BTW, did you see Jurij's post, which tracked back all those trouble to the > recently dropped Herbert-Xu-modular-ide patch ? Yes. That seems to give most of the answers I was looking for. > > > > However, /sys/block/hda/device still points to the right place, and > > > > it's my > > > > understanding that /sys/block is what yaird walks, so this still is no > > > > explanation for how someone could have mis-identified a bug in this > > > > area. > > > How does it find the device and then the driver starting from block ? > > $ readlink /sys/block/hda/device > > ../../devices/ide0/0.0 > This is the ide-generic node, right ? Yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#358512: More information: changes from 2.6.15
On Fri, Mar 24, 2006 at 02:04:09PM +0100, Martijn Pieters wrote: > Package: linux-headers-2.6.16-1-686-smp > Version: 2.6.16-2 > Followup-For: Bug #358512 > I see the same problems with module-assistant. I suspect that m-a is in the > wrong here, but perhaps more information on what changed re. version.h files > is > helpful: What is the m-a command you're issuing? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#358512: More information: changes from 2.6.15
On Sat, Mar 25, 2006 at 07:55:59AM +0100, Martijn Pieters wrote: > Steve Langasek wrote: > > On Fri, Mar 24, 2006 at 02:04:09PM +0100, Martijn Pieters wrote: > >> Package: linux-headers-2.6.16-1-686-smp > >> Version: 2.6.16-2 > >> Followup-For: Bug #358512 > >> I see the same problems with module-assistant. I suspect that m-a is in the > >> wrong here, but perhaps more information on what changed re. version.h > >> files is > >> helpful: > > What is the m-a command you're issuing? > $ m-a a-i nvidia Ok, and just to be sure, what is the output of uname -r on this system? I haven't tested this myself with 2.6.16; but if uname -r returns what's expected, then I'd agree it's a m-a bug -- otherwise it's probably not a bug at all. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#360448: iptables damages mac rules with kernel-image-2.4.27-3-k7
reassign 360448 iptables severity 360448 normal merge 360448 355285 quit On Sun, Apr 02, 2006 at 01:46:29PM +0200, Hansgeorg Schwibbe wrote: > When the server is up, the mac rules are correct like this: > debian:~# iptables > -L Isn't this the same bug you reported previously as bug #355285? > Now is the computer with the mac address 00:13:D3:FD:20:FA unable to > access the squid proxy server on port 3128 because the mac adress is > completly missing. The severity of this report is grossly overinflated; nobody else seems to be experiencing these problems with iptables. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: linux-2.4 deprecated
On Wed, Apr 05, 2006 at 11:06:21PM +0200, Aurelien Jarno wrote: > A few weeks ago, the 2.4 kernels have been declared "deprecated" [1]. I > would like to know what does this exactly mean: > - That users are advised not to use them? > - That we could drop support for them in other packages? > - That they will be removed from the archive soon? It means 1), and should mean 3) as well. In general, it does *not* imply 2) -- we need to be assured of having a clean upgrade path from sarge to etch, and since sarge shipped with a 2.4 kernel by default, this means that etch packages should at least be functional enough on 2.4 to allow a full upgrade and subsequent reboot to a new kernel. (That includes not breaking the system if the upgrade is interrupted and the system is rebooted again to a 2.4 kernel before the upgrade completes.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#361024: 361024: and lack of feedback
On Tue, Apr 11, 2006 at 07:21:49PM -0700, Gordon Haverland wrote: > Is the only option to upgrade to a 2.6 kernel? If you want a quick fix, your options are to upgrade to a 2.6 kernel, or to install the old version of libstdc++6 from gcc 4.0 and put it on hold until this bug is fixed in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#362064: udev: udev tries to write to an installed, working initrd without asking
severity 362064 serious quit On Thu, Apr 13, 2006 at 10:29:06AM +0200, maximilian attems wrote: > > __> sudo dpkg --configure udev > > Setting up udev (0.089-1) ... > > touch: cannot touch `/boot/initrd.img-2.6.16-selinux1-1-skas3-v9-pre9': > > Read-only file system > > /usr/sbin/mkinitramfs: line 218: > > /boot/initrd.img-2.6.16-selinux1-1-skas3-v9-pre9: Read-only file system > > dpkg: error processing udev (--configure): > > subprocess post-installation script returned error exit status 1 > > Errors were encountered while processing: > > udev > > Why is udev trying to write to a working boot mechanism > > without asking? > nor do i agree that there is a bug there. > Every service that puts something into the initramfs > has to run update-initrmfs. We've had this conversation before on IRC, and I don't believe there is any evidence that this is the case. Until you can show some, I regard this bug as release-critical. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362064: udev: udev tries to write to an installed, working initrd without asking
an lvm volume to be configured as the rootfs before the lvm2 package was installed (whereas evms may be pointing at some volume set up with an already-installed lvm2). So I don't see any real benefit to having all of these tools rebuilding the initramfs repeatedly during an upgrade cycle. Theoretically it would be nice to know as soon as a package is installed that it will break the initramfs, but using update-initramfs doesn't do this: the only way to be sure whether a new initramfs is broken is to try to boot from it. Since we can't force reboots during an upgrade (especially not once for each hook!), there is no significant increase in predictability by using this method, and users are better off if the upgrade doesn't touch the existing, working initramfs images at all. Now, Marco has a persuasive argument that udev version skew between rootfs and initramfs may cause problems; but that's not the problem that you claim this design addresses, and if that *is* the problem we need to address there are way we could do it with much less collateral damage. I would be more than happy to discuss with you guys possible designs for this; at the moment, though, I'm afraid I think the problem space is too ill-defined and needs to be clarified before I can comment intelligently on how to solve the problem. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#361024: note on "2.4 is deprecated"
On Thu, Apr 13, 2006 at 09:52:42PM +0200, Florian Weimer wrote: > * Joey Hess: > > - Debian's userland has *always* supported at least the previous major > >kernel version, and most often the previous two, or sometimes I > >think, three major kernel versions. > This isn't a real argument, IMHO, because upstream no longer releases > major kernel versions. > OTOH, dropping support for 2.4 kernels at this stage feels wrong. > (Even though I'd rather do it ASAP so that we can compile Berkeley DB > with POSIX threading. 8-) It might make sense to declare etch the > latest release which supports 2.4, though. I think etch should support 2.4 in the sense of "upgrade support only"; i.e., it should support 2.4 because we need to be able to install etch on systems running sarge 2.4 kernels, not because we'll provide support for 2.4 in etch. This AFAIK will satisfy Joey's need for interim 2.4 compatibility, while making it clear that the upgrade to 2.6 needs to happen before the etch+1 release. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#361024: note on "2.4 is deprecated"
On Thu, Apr 13, 2006 at 11:20:38PM +0200, Frans Pop wrote: > On Thursday 13 April 2006 22:59, Steve Langasek wrote: > > I think etch should support 2.4 in the sense of "upgrade support only"; > > i.e., it should support 2.4 because we need to be able to install etch > > on systems running sarge 2.4 kernels, not because we'll provide support > > for 2.4 in etch. > What about (sub)arches that currently do not yet support installing 2.6? These subarches would have to either get ported to 2.6, or not be supported for the release. Do you see any other options here? > If 2.4 is really going to be dropped for Etch except for upgrade purposes, > I'd very much like to see a formal (release) policy statement saying so. Well, then I think this will have to go in the next release update, unless someone steps forward to maintain 2.4 for etch before then. I think that's pretty unlikely, since the current kernel team appears unwilling to support 2.4, and any such support needs to include security support (or else it's not worth including it in stable). With no upstream security support for 2.4, it seems unlikely that anyone would consider that a worthwhile trade-off, and I don't think the security team is going to be willing to be left holding the bag. > If 2.4 kernels are really abandoned, it will mean that we (d-i) could > (should even) start cleaning out 2.4 related code and prod lagging > architectures into more speed where it comes to switching to 2.6. > Delaying a formal decision much longer will probably mean we'll be stuck > with 2.4 whether we like it or not. Rather, I think it would mean people would be upset about 2.4 being dropped with little official notice -- but yes, this should be announced sooner rather than later. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#362064: udev: udev tries to write to an installed, working initrd without asking
easy one and the hook wouldn't need to do anything. > b) hook is unpacked after: >according to above leads to broken initramfs generation, >thus linux-image is not fully installed >"breaks" potentialy many upgrades Hmm, this can still be handled by having the hooking packages only call update-initramfs on initial install, and making sure that a hook script that's not ready fails explicitly instead of silently. - if linux-image is configured while all hooking packages are in working order, then update-initramfs works fine - if linux-image is configured while a hooking package is still unconfigured, the hook script errors out and configuration of linux-image is deferred - if linux-image is configured, and a hook script is installed afterwards, update-initramfs is called once by each package -- and even if the initramfs generated by the first call isn't bootable, there should still be initramfs'es from previous images that are bootable. And if udev should really call update-initramfs in certain upgrade scenarios as well, then that's also easy for it to do. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: sarge upgrade - linux, grub conflict
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. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM
On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote: > Luke Kenneth Casson Leighton writes... > > i invite you to think ahead to when the 2.4 kernel is no longer > > maintained. > > i invite you to consider where debian will stand at that time with > > respect to older hardware. > > should debian be possible to install on older hardware in two, > > three years time, or should people who are not as fortunate and > > as computer literate as yourself, myself and mr horms, either > > throw the machine away or utilise an alternative distribution? > The subject of the minimum system requirements for Debian is probably > something the Debian Release team should be tracking if they're not already. > I > don't know if sarge had minimum system requirements, I didn't find any in a > brief scan of the release notes. I believe Joey Hess is the person who has the best handle on what the actual minimum requirements are for installing sarge. Joey, do you have anything we could add to the sarge release notes for this, if it's not already in there? > Can a goal be added to the release goals for etch? Obviously supporting 32mb > would be nice since a lot of appliance type systems only have that, but 64mb > might be a more reasonable goal. In addition to "minimum" requirements, > "recommended" requirements might be a good idea too. I think 48MB should still be a reasonable goal even with 2.6 kernels, shouldn't it? Whether 32 or 48 is the minimum for etch probably depends on whether we insist on shipping etch as 2.6-only. On Mon, Jul 25, 2005 at 04:17:10PM -0700, Matt Taggart wrote: > Luke Kenneth Casson Leighton writes... > > my bug report invites you to consider the impact that such > > a policy decision "roll your own or install 2.4 on anything > > with <= 48mb of ram", made by mr horms, will have on the > > debian project. > In reality, not much. But the nice thing about Debian is that it's built to > be > able to support the needs of minority groups, so there could be a solution > for > this group if there are people motivated to work on and maintain it. It's not > clear that there are though :( Curiously, this bug report seems to be about the memory requirements of 2.6 ramdisks. AIUI, it's still the hope that we'll have switched from initrd-tools to an initramfs solution for etch, which should have the effect of dropping the memory requirements significantly. But I don't think it's the responsibility of the kernel maintainers to hold back the hands of time where hardware obsoletion in concerned. If 48MB is the minimum that 2.6 will support, then someone who cares about machines with less RAM than that needs to do the work to lower that bar. Incidentally, I have no idea why this bug was filed against kernel-image-2.6-686; that package does not contain *any* ramdisks, so either Luke is complaining about the ramdisk used by d-i to boot 2.6, or the ramdisk generated by initrd-tools, yes? I can't tell which one, because his bug report is uselessly vague and rant-oriented; otherwise, I'd reassign the bug to the appropriate package. > There is an organization in Portland, OR, USA called FreeGeek ( > http://freegeek.org ) that recycles computer equipment and turns it into as > many working computers as possible (running Debian) and donates them to > various groups around the world. They maintain a specification of the minimum > requirements for the systems they build. Currently this is, > http://freegeek.org/freekbox.php > * Pentium III 500 - 566mhz > * 128MB RAM > * 9 - 10 GB hard drive > * 14x - 24x CD ROM drive > * Floppy disk drive > * 17 inch color monitor > * 56k Modem > * 10/100 Network card > * Keyboard > * Mouse > * Speakers > IMO, at any given time this spec is a good indication of what the minimal > system is to even attempt to run Debian on, anything less would be painful. > If the debian-release team decides to come up with minimum system > requirements > for etch, I think a good place to aim for i386 would be slightly less than > whereever the freekbox spec is at the time. Oh, well, I still have an AMD K6-450 with 128MB running sarge as my primary mailserver. It creaks under spamassassin's load from time to time, but it's not painful enough for me to deal with trying to swap the hardware out remotely. Maybe this box will still be useful through the etch timeframe. :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM
On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote:
> On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
> for this P120 (whatever) i have *shudder* had to use a
> 2.2.10-compact-pci kernel.
> there exists a kernel-image-2.4.18-bf2.4 (which i might try at some
> point).
Uh, 2.4.18-bf2.4 was built solely for use with the woody installer, and is
only available in oldstable. If you're considering using it as the kernel
on a newly-installed system, then it would seem support isn't of vital
importance to you after all.
> ... would it not make an inordinate amount of sense to have a
> kernel-image-2.6.N-bf2.6?
That wouldn't really be the right name for the flavor ("bf" refers to "boot
floppies", the old Debian installer), but I suppose a compact flavor that
statically enables a number of modules common to older hardware would be
feasible.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
Bug#319878: kernel-image-2.6-686: the entire range of 2.6 debian kernels do not install on m/cs with <= 48mb RAM
On Tue, Jul 26, 2005 at 03:19:25AM +0100, Luke Kenneth Casson Leighton wrote: > On Mon, Jul 25, 2005 at 05:52:54PM -0700, Steve Langasek wrote: > > On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton > > wrote: > > > On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote: > > > for this P120 (whatever) i have *shudder* had to use a > > > 2.2.10-compact-pci kernel. > > > there exists a kernel-image-2.4.18-bf2.4 (which i might try at some > > > point). > > Uh, 2.4.18-bf2.4 was built solely for use with the woody installer, and is > > only available in oldstable. If you're considering using it as the kernel > > on a newly-installed system, > only as a drastic desperation measure, as you can see it is a step up > from what the machine is _presently_ running... And why are the 2.4 kernel packages in sarge not a better option? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#322533: linux-2.6: no sound: codec_write 0: semaphore is not ready for register
Package: linux-image-2.6.12-1-686-smp Version: 2.6.12-1 Severity: normal In all Debian kernel packages above 2.6.8, sound is completely broken on my laptop. Trying to adjust volume settings gives me errors of this sort in the kernel log: Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x2 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x2 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x18 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x18 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x12 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x12 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x4 Aug 6 04:57:27 mauritius kernel: codec_write 0: semaphore is not ready for register 0x4 No evidence that the mixer settings actually change. In any case, sound apps hang when trying to open the sound device for output, so it hardly seems to matter if the mixer works. Sound device is, from lspci: :00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) and lspci -n: :00:1f.5 0401: 8086:24d5 (rev 02) Under 2.6.8, the following modules are loaded: snd_intel8x0m 20872 0 snd_intel8x0 37452 2 snd_ac97_codec 70884 2 snd_intel8x0m,snd_intel8x0 snd_pcm_oss55912 1 snd_mixer_oss 20384 2 snd_pcm_oss snd_pcm 102948 3 snd_intel8x0m,snd_intel8x0,snd_pcm_oss snd_timer 27492 1 snd_pcm snd_page_alloc 12008 3 snd_intel8x0m,snd_intel8x0,snd_pcm gameport5120 1 snd_intel8x0 snd_mpu401_uart 8640 1 snd_intel8x0 snd_rawmidi26084 1 snd_mpu401_uart snd_seq_device 8456 1 snd_rawmidi I haven't checked yet how this list compares to what gets loaded under 2.6.12. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#322533: linux-2.6: no sound: codec_write 0: semaphore is not ready for register
On Thu, Aug 11, 2005 at 07:44:00PM +0200, Frans Pop wrote: > tags 322533 + fixed-upstream > thanks > On Thursday 11 August 2005 11:14, Steve Langasek wrote: > > codec_write 0: semaphore is not ready for register 0x2 > > Under 2.6.8, the following modules are loaded: > > snd_intel8x0m 20872 0 > > snd_intel8x0 37452 2 > I've seen the same problem on my laptop and managed to trace it to a > conflict between snd_intel8x0 (that drives audio) and snd_intel8x0m (that > drives the modem). > If you unload the snd_intel8x0m module (or blacklist it so it does not get > loaded in the first place), the messages will go away. Great, this workaround does the trick for me, thanks. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#323183: Please remove some linux packages from sid
On Tue, Aug 16, 2005 at 09:23:52AM -0400, Joey Hess wrote: > Jeroen van Wolffelaar wrote: > > This will break a lot packages depending on one of those, including but > > not limited to things like linux-kernel-di-hppa-2.6, pwc, > > user-mode-linux, kernel-headers-2.6-generic (alpha), etc etc. FWIW, u-m-l seems to still be unmaintained and not going anywhere fast. > Since kernel-lastest in testing still points to 2.6.8, it will also > break d-i. You guys should probably wait until you've gotten > kernel-latest pointing to a newer kernel version before removing an old > one (2.6.11 is in testing now, but kernel-latest was never set to point > to it, and there seems to be no effort being made to time things to get > 2.6.12 into testing anytime soon) It won't actually break d-i when installing etch, because the dependency of kernel-latest on these kernels will prevent the removal of the necessary binary packages from testing. It will break d-i installs of sid, until the point that there's a new kernel-latest available in unstable; and once it's uploaded to unstable, we have to be sure that we're ready to have 2.6.12 as the default kernel in testing, because it probably won't take long to propagate. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Moving forward with the 2.4.27 and 2.6.8 kernels
Hi Horms, The plans you've described all sound good. I'm glad to see some movement on the question of kernel updates for sarge. On Tue, Aug 16, 2005 at 03:31:21PM +0900, Horms wrote: > Back to releases. After 2.4.27-11 is out, which should be very soon, > I would like to take what we have in SVN for both 2.6.8 and 2.4.27, > strip out all the non-security patches since Sarge (2.6.8-16 and > 2.4.27-10) and make a security release. When I say strip out, I > mean comment out the changelog line and the patch entry in the > series file. Thats all. There doesn't seem any reason to hide > other changes that have been included in SVN. Nor any reason > not to include the patches in the release - even if they aren't applied. > In short, this should make producing a security release a simple matter > of reading the changelog, adding a dozen or so # characters, > tagging and building. You'll have to get the security team's ok on this, though; I understand that you're coming from the position of wanting it to be easy to build these security updates off of the current tree, but the security team is definitely going to be coming at it from the other direction -- wanting to have a handle on what the differences are compared with the current stable package. > Of course as many arches need to do builds as possible. And as I > mentioned above, I am a little unsure about what queue to use for > security updates. Which is why I am writing this message. I think I saw that you figured this out in a later message, but just to confirm, the builds will need to go to the stable-security queue on security.debian.org, and need to be approved by the security team before being uploaded. > After all of that I'd like to look at getting some packages together > for a Sarge update (i.e. Sarge r1). Thats probably just a matter > of uploadin to the right queue. Though it would be nice to know > about what the planned timing for releasing r1 is, as it would > be nice to make sure a kernel came out a bit before the release. Yes, for this you should be able to upload to the "stable" queue on ftp-master.debian.org at any time. Your r1 updates should have a later version number than your proposed security updates, so that the one with the more complete set of fixes takes precedence. As far as a schedule for r1, you'd need to ask Joey Schulze. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 01:01:10AM +0200, Marco d'Itri wrote: > On Aug 24, martin f krafft <[EMAIL PROTECTED]> wrote: > > > udev has also been the hotplug multiplexer for some time now. > > Yeah. Horrible. Will udev become an editor and MTA too, maybe after > > etch? > No. But since it had to deal with most events, applying the same process > to the others was a natural extension of its design. > > > 2.4 kernels will not be supported in etch, > > I don't think this is an authoritative statement. At the moment, > > some architectures do not work with 2.6. > It's an educated guess. I consulted some of the interested maintainers > and followed the debian-kernel list, and so far there is no sign that > 2.4 will be supported (and if 2.6 will not be fixed on architectures > like sparc32, too bad for them). Although being able to ship just one kernel for all our ports in etch is everyone's first choice, the release team has not made any decision yet to exclude 2.4 kernels from etch if they're needed for a particular arch or subarch. Given that the kernel team is still rolling new 2.4 updates in unstable, and d-i still defaults to 2.4 on a majority of archs, I think it is premature to drop hotplug support for 2.4 at this point. It would certainly be a big help to the release team in making this decision if the kernel team would begin to drop 2.4 kernels as early as possible in the release cycle for those architectures where they believe they are no longer needed. Together with working out which ports are actually viable for etch under the new requirements (which of course first requires fully specifying those requirements), we should be able to get a clear picture in a couple of months of just what the kernel requirements are for etch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Wed, Aug 24, 2005 at 11:39:13PM -0700, Matt Taggart wrote: > > There are some architectures where 2.4 has been abandonded uptream, > > and these are being removed from the arcive > > powerpc (ok, thats one, not some) > hppa is as well. It is still useful to have the 2.4 kernel-images in the > archive since they are still more stable on some machines. Is it? There were no hppa 2.4 kernels included in sarge, because we were told by Thibaut that the upstream branch was rotting and not worth including. Is there really a reason to think it will be in *better* shape for etch? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: removing /etc/hotplug.d/ support
On Thu, Aug 25, 2005 at 02:31:14PM +0200, Marco d'Itri wrote: > On Aug 25, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > > All those popular mips WLAN devices use still 2.4 kernels, some people > > started to port some of them to 2.6, but the main hindrance are binary > > only (and thus 2.4 only) drivers. > It's not like they are already supported by debian anyway, then. > Is there anything else? > Can somebody comment on the alpha and m68k situations? The current lack of 2.6 support in the installer for alpha shouldn't really be an obstacle, but 2.6 doesn't currently work on my own alpha so I haven't been particularly motivated to fix up d-i to use it until I can usefully test it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev >= 0.060-1 and kernels >= 2.6.12
On Mon, Aug 29, 2005 at 11:26:09AM +0200, Bastian Blank wrote: > reassign 325484 udev > retitle 325484 udev lacks sarge->etch upgrade path > thanks > On Mon, Aug 29, 2005 at 01:46:49AM +0200, Marco d'Itri wrote: > > udev >= 0.060-1 and kernels >= 2.6.12 should enter testing at the same > > time. > You have to provide a proper sarge->etch upgrade path. This bug is the > sign of lack this path. Requiring that users reboot to 2.6.12 before installing the new version of udev from etch *is* a valid upgrade path. There were similar upgrade path choices that had to be made for woody->sarge on some archs due to kernel/glibc incompatibilities between versions; the udev upgrade path provided is not really any different than that, and unless someone can show a working implementation for udev that doesn't require this, I don't intend to second-guess Marco on this issue. Of course, we want udev 0.060 and linux-2.6 to be available at the same time in each suite, because dealing with the udev preinst failure is still disruptive -- we want users to install the kernel update *first*. This bug was opened to ensure that. Marco, since it looks like udev is going to be ready to go into testing before linux-2.6, and the breakage of new udev with old kernel is much worse than the breakage of old udev with new kernel, I think it would be a good idea to keep a bug open on udev for right now, even if the kernel maintainers object to having it listed against linux-2.6. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#325484: udev >= 0.060-1 and kernels >= 2.6.12
On Tue, Aug 30, 2005 at 11:48:17PM +0200, Frans Pop wrote: > (pruning CC list; AFAIK all will still get the message this way) > On Tuesday 30 August 2005 04:56, Steve Langasek wrote: > > > So we're going to have another release with a very elaborate upgrade > > > procedure in the release notes (which a lot of users, especially > > > desktop users, don't read anyway)? > > 1) upgrade your kernel > > 2) dist-upgrade > > That doesn't seem terribly elaborate to me? And if people choose not > > to read, well, they get a failure on dist-upgrade and get to figure it > > out for themselves, I guess. > Yeah, and that IMHO is exactly the problem. > Debian used to be known for relatively trouble free upgrades. For the > Woody-Sarge upgrade the upgrade problems (the kernel issues at least) > were mostly limited to non-mainstream architectures, but now we're likely > to hit 80% of Sarge desktop users. No, failing to read the release notes for sarge and doing a blind dist-upgrade on a desktop system was also likely to rip out large swaths of packages in the process. I understand that we all want dist-upgrade to Just Work, but I don't see how complaining that the release notes contain important information that users ignore at their peril is different from complaining that the list of packages being removed on apt-get dist-upgrade contains important information that users ignore at their peril. If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a vague idea of what this would entail, and I'm not willing to spend a month of my time on trying to make it work.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#308639: kernel-build vs. kernel-headers splitted broken, headers unuseable
Can anyone confirm whether this bug still applies to the kernel-headers-2.6.11-powerpc in testing, or to the linux-headers-2.6.12-1-powerpc in unstable? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linux 2.6.12-6 uploaded and built on all arches, waiting testing migration and futur upload plan.
On Sat, Sep 10, 2005 at 08:54:09AM +0200, Sven Luther wrote: > Now that linux 2.6.12-6 is ready to enter testing, (just waiting an RM > override for the hppa flavour rename) I don't see any reason here for the release team to override the out-of-date hppa packages. Removing them is an ftp team task, not a release team task. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linux 2.6.12-6 uploaded and built on all arches, waiting testing migration and futur upload plan.
On Sat, Sep 10, 2005 at 08:08:45PM +0200, Sven Luther wrote: > On Sat, Sep 10, 2005 at 12:18:50PM -0400, Joey Hess wrote: > > Sven Luther wrote: > > > So, the installer needs to be fixed ASAP. > > Getting a useable kernel into testing is a prerequsite for making the > > installer use it, not the other way around. > sure, will happen as soon as it gets hinted in. I guess my previous message wasn't clear. I'm fine with bumping the urgency of linux-2.6 to get it into testing, but I don't see any reason to override britney's judgement regarding the out-of-date hppa packages. Please get an ftp-master to rene the old binaries, and then linux-2.6 can go into testing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Linux 2.6.12-6 uploaded and built on all arches, waiting testing migration and futur upload plan.
On Sat, Sep 10, 2005 at 11:52:53AM +0200, Bastian Blank wrote: > On Sat, Sep 10, 2005 at 02:32:34AM -0700, Steve Langasek wrote: > > I don't see any reason here for the release team to override the > > out-of-date hppa packages. Removing them is an ftp team task, not a > > release team task. > Why are they listed as out-of-date? There is no version in testing. This refers to binaries in unstable without matching source. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: In preparation for 2.6.13 - initrd issues
On Mon, Sep 12, 2005 at 11:56:03PM +0200, Frans Pop wrote: > On Monday 12 September 2005 03:23, Jurij Smakov wrote: > > 2. What changes need to be done to integrate a new initrd-generating > > tool into the kernel packaging infrastracture. It might be as simple as > > switching the postinst of kernel packages from running mkinitrd to > > running yaird. I have no idea what issues may arise in d-i because of > > that. > The major issue for d-i with 2.6.13 is the dropped devfs support. However, > there already is support for udev in d-i; what's currently missing is a > udeb for hotplug. What we have was backported by Colin Watson from > Ubuntu; for hotplug we can probably do the same. Marco d'Itri has also talked about his plans to incorporate coldplug into udev. If we have coldplug, do we need a separate hotplug udeb? > This needs to be resolved before 2.6.13 can enter unstable and we can > start on this as soon as we have a new beta for d-i based on the 2.6.12 > kernels (which has of course been waiting for 2.6.12 to enter testing and > the major transitions to settle down somewhat). We can start work on the > beta as soon as daily CD building is back up. 2.6.12 has now entered testing. > initrdfs is a separate issue, and really two issues. I guess you mean initramfs here? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: In preparation for 2.6.13 - initrd issues
On Tue, Sep 13, 2005 at 11:17:44AM +0200, Marco d'Itri wrote: > In linux.debian.maint.boot Steve Langasek <[EMAIL PROTECTED]> wrote: > >Marco d'Itri has also talked about his plans to incorporate coldplug > >into udev. If we have coldplug, do we need a separate hotplug udeb? > No, but the new coldplug will probably not be ready before one month. That doesn't sound so bad. Is 2.6.13 going to be an immediate concern for the installer team any sooner than that? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#328130: RM: please remove any remnant of 2.6.10 and 2.6.11 kernels from etch/sid
On Fri, Sep 16, 2005 at 10:38:21AM +0900, Horms wrote: > On Fri, Sep 16, 2005 at 02:35:24AM +0200, Jeroen van Wolffelaar wrote: > > On Thu, Sep 15, 2005 at 03:05:18PM +0900, Horms wrote: > > > As requested, here is an updated list of kernel and related packages > > > to be removed at this time. > > So, I just removed the follow packages, but forgot to close this bug. Oh > > well. As usual, changes take effect upon next mirror pulse, and packages > > are later removed from testing automatically but not before reverse > > dependencies are all gone too. > Thanks, very much appreciated. > Out of interest, what is a good way to check dependancies across all > architectures and distributions? I know that apt-cache can do this based on > the sources it knows about, but thats usually only for the current > arch and distro. For existing packages, /org/ftp.debian.org/katie/melanie -n -R -s warns you of any packages left uninstallable (or unbuildable due to build-dependencies) by a removal. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#330003: kernel-source-2.4.27/kernel-source-2.4.27-11
On Sat, Sep 24, 2005 at 10:02:21PM -0700, Fenrir wrote: > Package: kernel-source-2.4.27-11 > Severity: grave > Justification: renders package unusable > I can successfully apt-get the kernel-source-2.4.27 package using > testing, but when trying to bunzip it bunzip2 gives a Data Integrity > Error while decompressing Sorry, but this error is completely unreproducible here; I don't think it's actually present in the package in the archive. Can you try re-installing the package to confirm? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#330003: kernel-source-2.4.27/kernel-source-2.4.27-11
Please keep the bug report address in the cc: list on replies. On Sun, Sep 25, 2005 at 11:56:55AM -0700, Fenrir wrote: > On 9/25/05, Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 24, 2005 at 10:02:21PM -0700, Fenrir wrote: > > > Package: kernel-source-2.4.27-11 > > > Severity: grave > > > Justification: renders package unusable > > > I can successfully apt-get the kernel-source-2.4.27 package using > > > testing, but when trying to bunzip it bunzip2 gives a Data Integrity > > > Error while decompressing > > Sorry, but this error is completely unreproducible here; I don't think > > it's > > actually present in the package in the archive. Can you try re-installing > > the package to confirm? > Re-installed the package 5 times before reporting the bug, tried again now, > still the same problem. Also tried upgrading bunzip2. I used apt-get to get > it and tried downloading it manually from > packages.debian.org<http://packages.debian.org>. > Is there anything else I should try? Please confirm the md5sum of the package you downloaded, against the md5sum that Andreas provided. Also, please check the md5sum of the .bz2 archive: $ md5sum /usr/src/kernel-source-2.4.27.tar.bz2 9623b035242c87ceeef98b2b3dcb91c8 /tmp/kernelsource/usr/src/kernel-source-2.4.27.tar.bz2 $ Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#330003: kernel-source-2.4.27/kernel-source-2.4.27-11
On Sun, Sep 25, 2005 at 09:09:55PM -0700, Fenrir wrote: > The md5 hash of the bz2 archive matches. Not sure what that hash of the > package is supposed to be though. Well, that's not a great answer, it means that you're getting Data Integrity Errors on a known-good archive, and they aren't reproducible anywhere else... Can you please forward us the output of these two commands? $ dpkg -l bzip2 libbz2-1.0 $ debsums -s bzip2 libbz2-1.0 Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#330003: kernel-source-2.4.27/kernel-source-2.4.27-11
On Sun, Sep 25, 2005 at 10:29:53PM -0700, Fenrir wrote: > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: > uppercase=bad) > ||/ Name Version Description > +++-==-==- > ii bzip2 1.0.2-8.1 high-quality block-sorting file compressor - > ii libbz2-1.0 1.0.2-7 high-quality block-sorting file compressor l > debsums: no md5sums for bzip2 > debsums: package libbz2.10 is not installed Ok. Could you try upgrading libbz2-1.0 to the matching version in testing (1.0.2-8.1) and see if that fixes the problem? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#330003: kernel-source-2.4.27/kernel-source-2.4.27-11
reassign 330003 bzip2 1.0.2-8.1 thanks On Sun, Sep 25, 2005 at 10:51:11PM -0700, Fenrir wrote: > Hm... how odd, never had the problem with the kernel packages before, but > that fixed it. Thanks for all the time, and sorry for the trouble. Yeah, that tells me it's not a bug in the kernel package, it's a bug in the bzip2 packages... reassigning. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: 2.6.12-1-686-smp kernel crash
On Sun, Oct 02, 2005 at 01:45:13AM +0200, Hugo van der Merwe wrote: > My machine is running stable on 2.6.11, however, if I boot 2.6.12, it > usually hangs/crashes within a minute after having logged in graphically > (gdm, gnome), and started doing things. (Last time I was switching > desktops, starting up terminals and loading web pages.) > I looked over the bug-list, but didn't see anything relevant. (Late at > night, I may have missed it...) What I want to know is how to best > provide more info? I think I should try single processor versions, > 386/486 versions, try a different display driver, or work in text mode > for a long time (more troublesome though), or just leave my machine on > doing nothing other than maybe moving the mouse, to try and find out > when it crashes/hangs and when it doesn't? Please ask this question on [EMAIL PROTECTED] The debian-testing list exists to handle problems with the actual process of upgrading, not to address problems with any individual package as a result of upgrading. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
Package: linux-2.6 Version: 2.6.12-6 The vfat driver in 2.6.12 appears to include a regression compared with earlier versions. VFAT is a case-insensitive filesystem, but with this kernel filenames are not handled in a case-insensitive manner: $ cd /media/usb0/ $ touch foo $ ls -l foo -rw--- 1 vorlon vorlon 0 2005-10-08 03:25 foo $ touch fOo touch: cannot touch `fOo': File exists $ cat fOo cat fOo: No such file or directory $ rm foo $ touch FOO $ ls FOO ls: FOO: No such file or directory $ ls foo foo $ touch foo_not_8.3.txt $ touch fOO_not_8.3.txt $ ls -l f*txt -rw--- 1 vorlon vorlon 0 2005-10-08 03:28 foo_not_8.3.txt -rw--- 1 vorlon vorlon 0 2005-10-08 03:28 fOO_not_8.3.txt $ This poses a significant compatibility problem when sharing vfat volumes between Debian and Windows (which, y'know, is the whole point). Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#331391: Re: ftpmaster: Please remove 2.6.8 kernel images
On Thu, Oct 13, 2005 at 02:58:01PM -0400, Joey Hess wrote: > I reviewed base-installer for use of kernel-image-2.6.* metapackages. > It's still used by amd64, arm, m68k, mips, and mipsel: > [EMAIL PROTECTED]:~/src/d-i/packages/base-installer/kernel>grep kernel-image * > alpha.sh: echo "kernel-image-$version-$SMP" > amd64.sh: echo "kernel-image-$KERNEL_MAJOR-amd64-k8$SMP" > amd64.sh: echo "kernel-image-$KERNEL_MAJOR-em64t-p4$SMP" > amd64.sh: echo > "kernel-image-$KERNEL_MAJOR-amd64-generic" > arm.sh: echo "kernel-image-$KERNEL_VERSION-$1" > i386.sh:echo "kernel-image-$KERNEL_VERSION-speakup" > i386.sh:imgbase=kernel-image > m68k.sh:echo "kernel-image-$version-$1" > mips.sh:echo "kernel-image-$version-$1" > mipsel.sh: echo "kernel-image-$version-$1" > powerpc.sh: apus) trykernel=kernel-image-$apusversion-apus ;; > powerpc.sh: echo > "kernel-image-$KERNEL_MAJOR-$1$SMP" > s390.sh:echo "kernel-image-$KERNEL_ABI-s390" > sparc.sh: imgbase=kernel-image > i386, alpha, s390, sparc, powerpc only use it for 2.4 kernels. Does this mean that these archs are now using linux-image-$foo for 2.6 kernels, or that we've regressed to hard-coding kernel versions in places? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
tags 333776 -unreproducible moreinfo thanks Hi Horms, On Fri, Oct 14, 2005 at 11:32:18AM +0900, Horms wrote: > Unfortunately I am unable to reproduce this problem with current sid > using linux-image-2.6.12-1-686-smp 2.6.12-10 > I created a partition using: > $ dd bs=1024 count=1024 if=/dev/zero > /tmp/vfat.img > $ mkdosfs /tmp/vfat.img > $ mount -o loop /tmp/vfat.img /mnt/tmp/ > $ mount > [snip] > /tmp/vfat.img on /mnt/tmp type vfat (rw,loop=/dev/loop0) > And then ran the tests you list above, and they all > worked the way I would expect on a case insensitive > file system, that is rather differently to what > you have above. > Can you cook up a test case that breaks? > Perhaps my mkdosfs is crating something that > works, where as you have a fs created slightly > differently? Ok, I can confirm that this is not reproducible using your above test case. The missing variable appears to be that I am mounting my partition using -oiocharset=utf8. If I use -oisocharset=iso8859-1 (the default), the mount behaves in a case-insensitive manner, but of course I don't want filenames to be shown as ISO8859-1 in userspace.. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: x86 kernel flavours was: 2.6.14-1 in incoming, status and future
On Sun, Oct 30, 2005 at 07:57:34PM +1100, Anand Kumria wrote: > On Sun, 30 Oct 2005 09:46:30 +0100, Sven Luther wrote: > > On Sat, Oct 29, 2005 at 02:36:53PM +0200, Marco Amadori wrote: > > As said, i think that the only way to solve this for debian-installer would > > be > > to follow up with my plan, and mandate a policy of all packaged modules to > > provide .debs and .udebs for all official kernel flavours. > Speaking of kernel flavours (we weren't, but what the hey); is the plan > still to reduce all of the x86 flavours down to two: generic x86 and > generic x86-smp? "Still"? When was this ever the plan? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#310982: does this affect etch/sid?
On Sun, Oct 30, 2005 at 03:42:24PM -0500, Joey Hess wrote: > This bug seems to be full of discussion of sarge, and was closed until > 3.0.14a-4 didn't make the cut for sarge. Does it also affect etch and > sid? If not, could you close it for those, so we can stop tracking it as > a security issue for them? The proper fix for this bug needs to be in the kernel; the changes made to samba were an expedient (but not expedient enough for sarge) workaround only. So yes, it does still apply to etch/sid; it is a kernel issue, and among other things will affect anyone building samba from non-Debian sources. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#490293: linux-image-2.6.24-etchnhalf.1-686: CONFIG_SMB_FS is not set
reopen 490293 thanks On Fri, Jul 11, 2008 at 01:35:05PM +0200, Bastian Blank wrote: > On Fri, Jul 11, 2008 at 12:33:11PM +0200, Hámorszky Balázs wrote: > > CONFIG_SMB_FS is not set > > in the kernel config. it would be nice to have smbfs > The option is described as "SMB file system support (OBSOLETE, please > use CIFS)". Just follow it and use cifs. No, we've already discussed this on IRC. CONFIG_SMB_FS should not be disabled in etch, the userspace support isn't there to give us feature parity via CIFS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Selection of kernel for Lenny
Hi Aurelien, On Mon, Jul 07, 2008 at 06:19:01PM +0200, Aurelien Jarno wrote: > - The switch to linux-libc-dev 2.6.25 is the reason why glibc currently > FTBFS on hppa (due to a timeout in a test). Unfortunately I don't know > yet which change causes the problem, I am down to a 600 lines diff. Have you gotten any closer to finding the cause of this regression? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: imminent 2.6.26 sid upload
On Wed, Jul 23, 2008 at 08:07:25PM -0300, Otavio Salvador wrote: > > That's just adding an arbitrary 5 days delay. Uploading to experimental > > won't uncover new issues, because nobody uses packages in experimental. > Uploading it to sid, will make a revertion to .25 much harder if > needed. Besides that, we'd need to know if it _at least_ builds on all > architectures and then be ready to upload meta packages... No, it really would be a waste of time. 2.6.25 is already in testing, so t-p-u is still there as an update path; but no one on the kernel side is really considering 2.6.25 to be an option for lenny, and the sooner we get 2.6.26 into unstable the sooner we can get everything smoothed out for lenny. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#492301: severity of 492301 is normal
# Automatically generated email from bts, devscripts version 2.10.33 # recommends are not serious severity 492301 normal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Userland compatibility fixes for 2.6.26
On Fri, Jul 18, 2008 at 02:20:12PM +0200, Bastian Blank wrote: > Hi folks > Following the discussion some weeks ago I have a patch to fix most of > the problematic userspace header changes in 2.6.26. I believe the following other incompatible changes should be addressed: asm-arm/unistd.h - changed a syscall define from __NR_timerfd to __NR_timerfd_create, unknown impact on existing applications linux/msdos_fs.h - dropped the #define for FAT_VALID_MEDIA > However I decided to ignore the following changes: > - sparc: Removed a.out definitions, SunOS/Solaris emulation only > - sparc: Removed SunOS/Solaris interface definitions I'm somewhat skeptical about dropping these; there are lots of things that like to include the kernel ELF headers, sometimes for no apparent reason, so it's possible that something is trying to include a.out on sparc or use other compat interfaces. But we can watch for this and deal with it only if and when it causes a problem, if the rest of the release team is ok with it. If it does cause problems, we should be prepared to restore these defns rather than spend time on a full-archive hunt for incompatibilities. > - Definitions for AF_WANPIPE socket Seems ok, any regression is going to be very localized. If someone can take care of patching the two issues mentioned above, then I'm happy with a 2.6.26 upload to unstable. Otherwise I'll work on the patch myself tomorrow night. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Userland compatibility fixes for 2.6.26
On Tue, Jul 29, 2008 at 01:38:56PM +0200, Bastian Blank wrote: > On Tue, Jul 29, 2008 at 02:09:44AM -0700, Steve Langasek wrote: > > On Fri, Jul 18, 2008 at 02:20:12PM +0200, Bastian Blank wrote: > > > Following the discussion some weeks ago I have a patch to fix most of > > > the problematic userspace header changes in 2.6.26. > > I believe the following other incompatible changes should be addressed: > > asm-arm/unistd.h - changed a syscall define from __NR_timerfd to > > __NR_timerfd_create, unknown impact on existing applications > If we define it, we will get broken binaries instead of a failed build. > The syscall was never implemented and got reassiged to timerfd_create. Ok, that clarifies. No need for a change here then. > > linux/msdos_fs.h - dropped the #define for FAT_VALID_MEDIA > Well. > > > However I decided to ignore the following changes: > > > - sparc: Removed a.out definitions, SunOS/Solaris emulation only > > > - sparc: Removed SunOS/Solaris interface definitions > > I'm somewhat skeptical about dropping these; there are lots of things that > > like to include the kernel ELF headers, > This are a.out, not ELF headers. And they don't include anything else. Yes, I understand that. I would expect software that's doing a.out to be *more* likely, not less likely, to abuse misuse kernel headers... > > so > > it's possible that something is trying to include a.out on sparc or use > > other compat interfaces. > This are SunOS interfaces, so the users are completely sparc specific. I > did a check over all possible packages and found nothing. It makes not > much sense anyway to use them, most likely the kernel interface is > already broken. That's fine. I'm not arguing that either of these things should be changed before upload; but if there did turn out to be something that broke because of these changes, we should revert the changes for lenny. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
