Re: Cleaning up kernel's headers for userspace
On Mon, Apr 24, David Woodhouse wrote: The other problem is the vastness of our architecture support - we do from x86 to m68k and all those headers need to work -- hence hand-picking really never was seen as the viable option as it means a *lot* of work between upstream releases. Our current way you just fix a few conflicts with the patches have when you move from say 2.6.16 to 2.6.17, and run test-cases to see if any new gremlins have appeared. The idea is that this all happens upstream; no such merges would be required. Once we've got it sorted out, the architecture maintainers are responsible for the output of 'make headers_install' on their architecture, and 'make headers_check' exists for automated checking of the results. If you have more checks which we should apply during the 'make headers_check' stage, that would be useful. Personally I like the idea to install only the necessary kernel header files without the #ifdef __KERNEL__ part very much. This would solve a lot of problems I currently have, but it would also create a lot of headache for this people, who are using the then missing header files excessive. And for the distributors, who have to fix this packages initially. I had already since a long time the idea to include only this header files, which are needed or referenced by glibc itself, but I never had the time to do so. But I don't think it is realistic that kernel developers will start fixing their header files for user inclusion. In most cases you will get only negativ feedback if you send patches, which fixes header files for userland inclusion. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ [EMAIL PROTECTED] SUSE LINUX Products GmbH Maxfeldstr. 5 D-90409 Nuernberg Key fingerprint = 8C6B FD92 EE0F 42ED F91A 6A73 6D1A 7F05 2E59 24BB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cleaning up kernel's headers for userspace
On Tue, 2006-04-25 at 10:25 +0200, Thorsten Kukuk wrote: Personally I like the idea to install only the necessary kernel header files without the #ifdef __KERNEL__ part very much. This would solve a lot of problems I currently have, but it would also create a lot of headache for this people, who are using the then missing header files excessive. And for the distributors, who have to fix this packages initially. Arjan did a certain amount of this when he owned the glibc-kernheaders package in Fedora. We did trip up a few broken packages; notably those including asm/atomic.h -- which wasn't even atomic in general on i386. It shouldn't be that painful now. We used to occasionally receive complaints that this was Fedora-specific 'breakage', and upstream maintainers were sometimes reluctant to fix their abuse of header files. That's another reason why it would be good to have this done _upstream_, so that users can rely on the set of available headers being _consistent_ between distributions. If this is really a concern, then we can _start_ by shipping the commonly-abused files with #warning in them, and phase them out over time. I don't think that's either necessary or helpful though -- I'd rather just drop them immediately. As I said in a previous mail though, I'm _more_ interested in getting a consensus and moving forward and getting this upstream than I am in the details of which headers we actually include for now, so I'll capitulate on this if I have to. But I don't think it is realistic that kernel developers will start fixing their header files for user inclusion. In most cases you will get only negativ feedback if you send patches, which fixes header files for userland inclusion. I think we will have to take the initiative to do the initial cleanup -- and I'm happy to coordinate that effort by providing access to a shared git tree for collecting such patches. I agree that it's not realistic to expect kernel developers in general to do that first step. But I don't anticipate much negative feedback at this point. There is a broad consensus among kernel developers that this _needs_ to be done, even if none of us really relish the thought of doing it ourselves. And after that initial cleanup, I _do_ expect random kernel developers in general to care -- and the 'make headers_check' target can become a useful tool to keep them in line. I'd expect to see patches getting rejected if they cause regressions in userspace headers. So where do we go from here? I've split the actual 'headers_install' and 'headers_check' stuff into a clean git tree in shared space at git://git.infradead.org/hdrinstall-2.6.git and I'm currently transferring the actual header cleanups I've already done into another git tree at git://git.infradead.org/hdrcleanup-2.6.git -- using separate trees just so that the actual cleanups can go upstream independently of the export mechanism if necessary. Hopefully, Andrew will be happy to pull both of these into his -mm tree. They're also browsable in gitweb at http://git.infradead.org/ If you want an account with write access to these trees, send me a public SSH key. In particular, I'd like people who care about architectures other than PowerPC to look over the choice of files to be exported, in asm-*/Kbuild. -- dwmw2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cleaning up kernel's headers for userspace
On Tue, Apr 25, 2006 at 02:12:35PM +0100, David Woodhouse wrote: On Tue, 2006-04-25 at 10:25 +0200, Thorsten Kukuk wrote: Personally I like the idea to install only the necessary kernel header files without the #ifdef __KERNEL__ part very much. This would solve a lot of problems I currently have, but it would also create a lot of headache for this people, who are using the then missing header files excessive. And for the distributors, who have to fix this packages initially. Arjan did a certain amount of this when he owned the glibc-kernheaders package in Fedora. We did trip up a few broken packages; notably those including asm/atomic.h -- which wasn't even atomic in general on i386. It shouldn't be that painful now. We used to occasionally receive complaints that this was Fedora-specific 'breakage', and upstream maintainers were sometimes reluctant to fix their abuse of header files. Indeed, which is why we took the other approach to this problem since we need things to compile to our users, not just package maintainers :) That's another reason why it would be good to have this done _upstream_, so that users can rely on the set of available headers being _consistent_ between distributions. Yeah, right now everybody's doing their thing -- centralizing should help solve the problem for everybody. If this is really a concern, then we can _start_ by shipping the commonly-abused files with #warning in them, and phase them out over time. I don't think that's either necessary or helpful though -- I'd rather just drop them immediately. As I said in a previous mail though, I'm _more_ interested in getting a consensus and moving forward and getting this upstream than I am in the details of which headers we actually include for now, so I'll capitulate on this if I have to. Hm, I quite like the idea of the #warning. And for files that are blatantly pure __KERNEL__ we can just do: #ifndef _LINUX_HEADERS_ASM_ARCH_BLARF_H #define _LINUX_HEADERS_ASM_ARCH_BLARF_H #warning linux::asm-arch/blah.h: this header is deprecated, fix yer shizzle! #endif into the file after declaring it pure __KERNEL__ some such. If you could fix the build scripts to do this to any file which isn't explicitly stated as userspace-OK that would be great. That way you get noise (and hopefully users file bugs) and at the same time things work and don't break apps that #include looney headers :) But I don't think it is realistic that kernel developers will start fixing their header files for user inclusion. In most cases you will get only negativ feedback if you send patches, which fixes header files for userland inclusion. This has been a problem in the past. The other problem has been fixing glibc so it includes headers in a sane way in places (we also got negative feedback there when we tried). Either way, since there's now hopefully a centralized place and aim for this cleanup project and once we get things usable the kernel devs should finally get the hint once it hits distribution trees ... that and hopefully Andrew will back us up :) I think we will have to take the initiative to do the initial cleanup -- and I'm happy to coordinate that effort by providing access to a shared git tree for collecting such patches. I agree that it's not realistic to expect kernel developers in general to do that first step. Nod. And after that initial cleanup, I _do_ expect random kernel developers in general to care -- and the 'make headers_check' target can become a useful tool to keep them in line. I'd expect to see patches getting rejected if they cause regressions in userspace headers. What we really need is not random kernel devs but arch maintainers. So anything that goes in asm-arch works. So where do we go from here? I've split the actual 'headers_install' and 'headers_check' stuff into a clean git tree in shared space at git://git.infradead.org/hdrinstall-2.6.git and I'm currently transferring the actual header cleanups I've already done into another git tree at git://git.infradead.org/hdrcleanup-2.6.git -- using separate trees just so that the actual cleanups can go upstream independently of the export mechanism if necessary. Guess I need to start to learn to use git properly :) If you want an account with write access to these trees, send me a public SSH key. In particular, I'd like people who care about architectures other than PowerPC to look over the choice of files to be exported, in asm-*/Kbuild. When I get some time I'll look into x86+ia64. Thanks, Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cleaning up kernel's headers for userspace
On Tue, 2006-04-25 at 17:03 +, Tim Yamin wrote: We used to occasionally receive complaints that this was Fedora-specific 'breakage', and upstream maintainers were sometimes reluctant to fix their abuse of header files. Indeed, which is why we took the other approach to this problem since we need things to compile to our users, not just package maintainers :) Yes, but you still ship bug-fix patches which fix things when the upstream tarball is broken, surely? You're not just held hostage to broken upstream maintainers, although of course it's _better_ when we can get stuff fixed upstream. Hm, I quite like the idea of the #warning. And for files that are blatantly pure __KERNEL__ we can just do: #warning linux::asm-arch/blah.h: this header is deprecated, fix yer shizzle! #endif We really don't need that for 99% of the kernel-private files, and I think it's overkill to do that kind of thing when we can just remove the files. If you really want to accommodate code which is known to be broken not just in theory but also in practice, then we can annotate asm/atomic.h that way for a while in the upstream kernel before we remove it from the 'export' list in a few months' time. Are there other private files you'd want to do that for? But I don't think it is realistic that kernel developers will start fixing their header files for user inclusion. In most cases you will get only negativ feedback if you send patches, which fixes header files for userland inclusion. This has been a problem in the past. The other problem has been fixing glibc so it includes headers in a sane way in places (we also got negative feedback there when we tried). Can you be specific about what was requested, and how it would have helped? I'm sure Uli has no intention of making it harder for us to make progress with cleaning up the kernel headers. That subject might be best pursued with a pruned Cc list. What we really need is not random kernel devs but arch maintainers. So anything that goes in asm-arch works. I think we need _both_ types of developer to actually care about how their header files look in userspace. When I get some time I'll look into x86+ia64. Cool, thanks. -- dwmw2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364845: glibc has recursive build-depends
package: libc6 version: 2.3.6-7 glibc has a build-depends on libc6-dev-amd64 on i386, and libc6-dev-i386 on amd64. This makes bootstrapping difficult. Why can't it just use itself? Doesn't it use gcc in standalone mode, so that gcc doesn't need any system-installed development files? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363644: Upgraded debconf, purged/reinstalled locales, fixed
Package: locales Version: 2.3.6-7 Followup-For: Bug #363644 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I upgraded debconf, purged and reinstalled locales, removed /etc/environment and /etc/default/locale, and dpkg-reconfigure'd locales, and now all seems well. Now I only have /etc/default/locale, and it looks like this: $ cat /etc/default/locale # File generated by update-locale LANG=en_US I don't know what caused it, but at least it's fixed now. I would close this bug, but I'm not sure if I should. Maybe the dependency needs to be updated. - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.0 Debian configuration management sy ii libc6 [glibc-2.3.6-2] 2.3.6-7GNU C Library: Shared libraries locales recommends no packages. - -- debconf information: * locales/default_environment_locale: en_US * locales/locales_to_be_generated: en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 UTF-8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFETwBz5+GdyTDsrJsRAhSVAJ44xD2VxE5MS5TrV5nNrWnxzdlcGQCfXI4E g0ZnwvfKQ60iXj5XMIJnY4g= =uv/6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
