Bug#633961: linux images must conflict with unfixed input-utils
On Thu, 2011-07-21 at 07:05 +0300, Adrian Bunk wrote: On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote: On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. That doesn't answer the question Why there are no versioned virtual packages. Policy §7.5: If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied... [...] After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Why isn't that going to happen? As you said before, input-utils is a niche package. That's the one proper solution in this case. Especially considering that Backports are now more or less an official part of Debian, there are many scenarios where a stable update does not solve the problem. And keep in mind that if the fix for input-utils wasn't that trivial, a stable update would not even be an option. But apparently it was, so it is. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#633961: linux images must conflict with unfixed input-utils
On Thu, Jul 21, 2011 at 12:50:01PM +0200, Ben Hutchings wrote: On Thu, 2011-07-21 at 07:05 +0300, Adrian Bunk wrote: On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote: On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. That doesn't answer the question Why there are no versioned virtual packages. Policy §7.5: If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied... And that makes Provides: linux-image-2.6.39 impossible? [...] After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Why isn't that going to happen? As you said before, input-utils is a niche package. You fail to explain where the Breaks would cause any problem for anyone. ... Ben. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011072745.ga19...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. How could a package declare I need at least kernel 2.6.39? (I know that self-compiled kernels are a different story, but for kernel packages that should be possible.) It can't. The only kind of relation you can use to binary kernel packages is an exact dependency from a binary module package. [...] I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. After looking a bit into it, and especially at commit ab4e0192 (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in the kernel, the correct fix for input-utils is a different and quite simple one: The input kernel-userspace API might be enhanced with additional functionality in the future, but it will never change in a way that breaks the ABI. Therefore the old functionality input-utils is using will always be available, and the bug was that EVIOCGVERSION shouldn't be used to check with equality for EV_VERSION (version = 0x010001 might be a valid check for software using EVIOCGKEYCODE_V2). A patch for input-utils to remove the wrong version check is below. After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#633961: linux images must conflict with unfixed input-utils
On Thu, Jul 21, 2011 at 01:09:34AM +0200, Ben Hutchings wrote: On Mon, 2011-07-18 at 14:29 +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? 1. There are many different binary packages for different hardware configurations, and we add and remove them quite regularly. 2. Although the binary packages provide virtual packages, virtual packages aren't versioned. That doesn't answer the question Why there are no versioned virtual packages. How could a package declare I need at least kernel 2.6.39? (I know that self-compiled kernels are a different story, but for kernel packages that should be possible.) It can't. The only kind of relation you can use to binary kernel packages is an exact dependency from a binary module package. [...] I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. After looking a bit into it, and especially at commit ab4e0192 (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in the kernel, the correct fix for input-utils is a different and quite simple one: The input kernel-userspace API might be enhanced with additional functionality in the future, but it will never change in a way that breaks the ABI. Therefore the old functionality input-utils is using will always be available, and the bug was that EVIOCGVERSION shouldn't be used to check with equality for EV_VERSION (version = 0x010001 might be a valid check for software using EVIOCGKEYCODE_V2). A patch for input-utils to remove the wrong version check is below. After that, a Breaks in all kernel images on the unfixed input-utils would be required. [...] Not going to happen. You need to fix this through a stable update. Why isn't that going to happen? That's the one proper solution in this case. Especially considering that Backports are now more or less an official part of Debian, there are many scenarios where a stable update does not solve the problem. And keep in mind that if the fix for input-utils wasn't that trivial, a stable update would not even be an option. Ben. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110721040551.gb13...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
tags 609300 +patch
thanks
On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote:
...
This is wrong on so many levels.
1. There is no way to declare relations to 'all kernel packages'.
Why not?
How could a package declare I need at least kernel 2.6.39?
(I know that self-compiled kernels are a different story, but for
kernel packages that should be possible.)
...
3. You know how people complain about udev and kernel upgrade ordering
dependencies? You're proposing to do the same thing.
udev is a special case, since it is very essential and udev and kernel
upgrade ordering was a tricky problem.
input-utils is a peripheral package without much hassle.
I suspect that the correct way to deal with this may be to build
input-utils from the linux-2.6 source package and add some sort of
wrapper in linux-base to select the right version (like we do for
perf).
Or, you change the program to check which protocol version to use at
run-time.
After looking a bit into it, and especially at commit ab4e0192
(Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in
the kernel, the correct fix for input-utils is a different and
quite simple one:
The input kernel-userspace API might be enhanced with additional
functionality in the future, but it will never change in a way that
breaks the ABI.
Therefore the old functionality input-utils is using will always
be available, and the bug was that EVIOCGVERSION shouldn't be used
to check with equality for EV_VERSION (version = 0x010001 might
be a valid check for software using EVIOCGKEYCODE_V2).
A patch for input-utils to remove the wrong version check is below.
After that, a Breaks in all kernel images on the unfixed input-utils
would be required.
Ben.
cu
Adrian
-- snip --
--- input.c.old 2011-07-18 14:12:14.0 +0300
+++ input.c 2011-07-18 14:12:32.0 +0300
@@ -83,7 +83,7 @@
int device_open(int nr, int verbose)
{
char filename[32];
- int fd, version;
+ int fd;
snprintf(filename,sizeof(filename),
/dev/input/event%d,nr);
@@ -96,17 +96,6 @@
if (verbose)
printf(%s\n,filename);
- if (-1 == ioctl(fd,EVIOCGVERSION,version)) {
- perror(ioctl EVIOCGVERSION);
- close(fd);
- return -1;
- }
- if (EV_VERSION != version) {
- fprintf(stderr, protocol version mismatch (expected %d, got
%d)\n,
- EV_VERSION, version);
- close(fd);
- return -1;
- }
return fd;
}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110718112947.ga12...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 02:29:47PM +0300, Adrian Bunk wrote: tags 609300 +patch thanks On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? How could a package declare I need at least kernel 2.6.39? See http://packages.debian.org/search?keywords=linux-image-2.6.39-2 for the kernel you'd have to depend on only to cover 2.6.39 and not all future kernels with all then valid featuresets. And note that a machine having installed 2.6.39 but runs 2.6.32 satisfies that Depends. So you need a runtime check. ($(uname -r) = 2.6.39) (I know that self-compiled kernels are a different story, but for kernel packages that should be possible.) ... 3. You know how people complain about udev and kernel upgrade ordering dependencies? You're proposing to do the same thing. udev is a special case, since it is very essential and udev and kernel upgrade ordering was a tricky problem. input-utils is a peripheral package without much hassle. I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. After looking a bit into it, and especially at commit ab4e0192 (Input: define separate EVIOCGKEYCODE_V2/EVIOCSKEYCODE_V2) in the kernel, the correct fix for input-utils is a different and quite simple one: The input kernel-userspace API might be enhanced with additional functionality in the future, but it will never change in a way that breaks the ABI. Therefore the old functionality input-utils is using will always be available, and the bug was that EVIOCGVERSION shouldn't be used to check with equality for EV_VERSION (version = 0x010001 might be a valid check for software using EVIOCGKEYCODE_V2). I think this is the way to go. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718124520.gc1...@pengutronix.de
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 02:45:20PM +0200, Uwe Kleine-König wrote: On Mon, Jul 18, 2011 at 02:29:47PM +0300, Adrian Bunk wrote: tags 609300 +patch thanks On Fri, Jul 15, 2011 at 06:30:41PM +0100, Ben Hutchings wrote: ... This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. Why not? How could a package declare I need at least kernel 2.6.39? See http://packages.debian.org/search?keywords=linux-image-2.6.39-2 for the kernel you'd have to depend on only to cover 2.6.39 and not all future kernels with all then valid featuresets. You'd actually need to conflict with all older kernels, since a dependency would force the installation of a kernel image (which is not mandatory with self-compiled kernels). And note that a machine having installed 2.6.39 but runs 2.6.32 satisfies that Depends. So you need a runtime check. ($(uname -r) = 2.6.39) ... That's clear, and it is clear that the kernel is a special case you cannot handle completely through dependencies. Still it's strange that there's no Provides: linux-image-2.6.39 other packages could use for forcing an upgrade of the installed kernel image. Best regards Uwe cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718132239.gb12...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
http://www.kraxel.org/blog/2011/07/input-1-0-released/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e246687.7090...@bytesex.org
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 14:29:47 +0300, Adrian Bunk wrote: How could a package declare I need at least kernel 2.6.39? You can't, and shouldn't, do that (at least until after the wheezy release). Cheers, Julien -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718183521.gv32...@radis.liafa.jussieu.fr
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 08:35:21PM +0200, Julien Cristau wrote: On Mon, Jul 18, 2011 at 14:29:47 +0300, Adrian Bunk wrote: How could a package declare I need at least kernel 2.6.39? You can't, and shouldn't, do that (at least until after the wheezy release). Why shouldn't? What would be the correct handling for a package whose upstream sources use a userspace-kernel interface introduced in 2.6.39? Cheers, Julien cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718192126.ga3...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
Adrian Bunk wrote: What would be the correct handling for a package whose upstream sources use a userspace-kernel interface introduced in 2.6.39? Check for -ENOSYS, print a helpful error message, and exit. And cooperate with upstream to come up with a reasonable fallback so your package can work in a sid chroot on a stable system. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718193041.ga6...@elie.gateway.2wire.net
Bug#633961: linux images must conflict with unfixed input-utils
On Mon, Jul 18, 2011 at 02:30:41PM -0500, Jonathan Nieder wrote: Adrian Bunk wrote: What would be the correct handling for a package whose upstream sources use a userspace-kernel interface introduced in 2.6.39? Check for -ENOSYS, print a helpful error message, and exit. And cooperate with upstream to come up with a reasonable fallback so your package can work in a sid chroot on a stable system. Why is this sid chroot on a stable system usecase so important? And how are you currently ensuring that perf is working in your sid chroot on a stable system usecase? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110718195653.ga4...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
Adrian Bunk wrote:
Why is this sid chroot on a stable system usecase so important?
I don't write the policies.
More to the point, what I was trying to say is that the package
manager will not help you with this. To get reasonable behavior on
what really is a common configuration, you need to be able to cope
with an older kernel, at least enough to print a meaningful error
message and exit.
And how are you currently ensuring that perf is working in your
sid chroot on a stable system usecase?
$ cat /usr/bin/perf
#!/bin/bash
# Execute the right version of perf for the current kernel.
version=$(uname -r)
version=${version%%-*}
shopt -s execfail
exec perf_$version $@
# Not found? Tell the user which package to install.
echo 2 E: linux-tools-$version is not installed.
exit 1
Anyway, if you believe that lockstep upgrades of the kernel and
userspace are something the Debian project should support, I am
guessing this bug log isn't the right place to discuss it. Maybe
debian-devel.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110718200238.ga6...@elie.gateway.2wire.net
Bug#633961: linux images must conflict with unfixed input-utils
Package: linux-image-2.6.39-2-amd64 Version: 2.6.39-3 Severity: serious Upgrading the kernel without also upgrading input-utils (e.g. when using the version in squeeze or the version currently in testing) makes input-utils unusable (see #609300). After #609300 got fixed, the linux images should therefore add Breaks for all non-fixed versions of input-utils. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715130416.12008.876.reportbug@localhost
Bug#633961: linux images must conflict with unfixed input-utils
On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote: Package: linux-image-2.6.39-2-amd64 Version: 2.6.39-3 Severity: serious This is not RC for the kernel. Upgrading the kernel without also upgrading input-utils (e.g. when using the version in squeeze or the version currently in testing) makes input-utils unusable (see #609300). After #609300 got fixed, the linux images should therefore add Breaks for all non-fixed versions of input-utils. Maybe. But first you have to make input-utils work with both the kernel version in squeeze and the version in sid. Ben. -- Ben Hutchings Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer signature.asc Description: This is a digitally signed message part
Bug#633961: linux images must conflict with unfixed input-utils
On Fri, Jul 15, 2011 at 03:45:58PM +0100, Ben Hutchings wrote: On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote: Package: linux-image-2.6.39-2-amd64 Version: 2.6.39-3 Severity: serious This is not RC for the kernel. Upgrade makes another package completely unusable when not forcing an upgrade of that is not RC? Upgrading the kernel without also upgrading input-utils (e.g. when using the version in squeeze or the version currently in testing) makes input-utils unusable (see #609300). After #609300 got fixed, the linux images should therefore add Breaks for all non-fixed versions of input-utils. Maybe. But first you have to make input-utils work with both the kernel version in squeeze and the version in sid. A versioned build-dependency on linux-libc-dev and a breaks for older kernel images seems to be the minimal fix. Ben. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715154159.ge4...@localhost.pp.htv.fi
Bug#633961: linux images must conflict with unfixed input-utils
On Fri, Jul 15, 2011 at 06:41:59PM +0300, Adrian Bunk wrote: On Fri, Jul 15, 2011 at 03:45:58PM +0100, Ben Hutchings wrote: On Fri, 2011-07-15 at 16:04 +0300, Adrian Bunk wrote: Package: linux-image-2.6.39-2-amd64 Version: 2.6.39-3 Severity: serious This is not RC for the kernel. Upgrade makes another package completely unusable when not forcing an upgrade of that is not RC? Depends on the relative importance of the packages. Upgrading the kernel without also upgrading input-utils (e.g. when using the version in squeeze or the version currently in testing) makes input-utils unusable (see #609300). After #609300 got fixed, the linux images should therefore add Breaks for all non-fixed versions of input-utils. Maybe. But first you have to make input-utils work with both the kernel version in squeeze and the version in sid. A versioned build-dependency on linux-libc-dev and a breaks for older kernel images seems to be the minimal fix. This is wrong on so many levels. 1. There is no way to declare relations to 'all kernel packages'. 2. input-utils doesn't break them! They don't depend on input-utils; they'll keep on running. 3. You know how people complain about udev and kernel upgrade ordering dependencies? You're proposing to do the same thing. I suspect that the correct way to deal with this may be to build input-utils from the linux-2.6 source package and add some sort of wrapper in linux-base to select the right version (like we do for perf). Or, you change the program to check which protocol version to use at run-time. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110715173041.gt29...@decadent.org.uk
