guenter geiger wrote: (I wrote:)
Yes, linux-kernel-headers is a subproject of the Debian glibc packaging project; it consists of the headers which go in /usr/include/linux. It should be named something else like glibc-linux-kernel-headers so as to stop confusing people, but that's another matter. ;-)Hmm. OK, this is the way it is. Linux kernel developers don't like most linux headers to be included directly from userspace. They want them to be "sanitized" first if used at all; the glibc sys/ headers often include carefully sanitized versions of the linux/ headers. Now, pix_videoLinux.h includes linux/videodev.h directly, which includes linux/videodev2.h, which includes linux/time.h. If there is a "userspace version" of videodev.h somewhere in glibc, gem should use that instead. There probably isn't, though, as I couldn't find one. :-) It's possible that either linux/videodev.h or linux/videodev2.h could be trivially cleaned up to avoid importing all of linux/time.h (when used in userspace). In which case a patch to do that should be submitted to linux-kernel-headers.Aren't these headers part of libc anymore ?
At this point this is basically a matter for the glibc packagers. They've been getting recurring problems with various different /usr/include/linux headers; the Linux kernel developers want nothing to do with it; so it's up to the glibc packagers to supply appropriate /usr/include/linux headers.Actually I have the feeling that something more substantial went wrong with /usr/include/linux.
Apparently most of the /usr/include/linux headers are *not* intended for public use; they're supposed to be like the /usr/include/bits headers, included only by other system headers.
There are, however, exceptions when there *is* no other appropriate header. This looks (to me) like one of those cases.
It's RC because it's a FTBFS. It's probably not really *your* release critical bug, though, but a bug in linux-kernel-headers.I just can't believe that something that worked the last 7 years (and is used by every package that uses the video device) is suddenly a release critical bug.
I'm going to CC: this to debian-glibc in hopes that someone there can comment on whether linux/videodev.h is intended to be used from userspace (in which case it's clearly their bug), and if not what the replacement userspace header is.
GuenterIf not, then gem should create its own version of videodev.h and use that instead of including linux/videodev.h directly. :-( Which would be annoying, but would do the trick. (I notice other direct inclusions of linux/*.h headers, which should probably also be avoided if reasonable, as they can lead to the same kinds of bugs.)