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]
Bug#58292: glibc (source): tries to build nss-v1/ before nis/
Hi, On Thu, Feb 17, Kalle Olavi Niemitalo wrote: Package: glibc Version: 2.1.3-2 Severity: normal While compiling glibc, I got this error: make[3]: *** No rule to make target `/var/tmp/kalle/Debian/glibc-2.1.3/i386-linux/obj/nis/libnsl.so.1', needed by `/var/tmp/kalle/Debian/glibc-2.1.3/i386-linux/obj/nss-v1/libnss1_compat.so'. Stop. make[3]: Leaving directory `/var/tmp/kalle/Debian/glibc-2.1.3/glibc-2.1.3/nss-v1' make[2]: *** [nss-v1/others] Error 2 make[2]: Leaving directory `/var/tmp/kalle/Debian/glibc-2.1.3/glibc-2.1.3' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/kalle/Debian/glibc-2.1.3/i386-linux/obj' At this time, Make had already built libc.so and was making others. It appears that Make tried to make others in nss-v1/ before making it in nis/. nss-v1/Depend is: nis db2 resolv and nothing depends on nss-v1, so the build system should have automatically sorted nis before nss-v1. Somehow, it didn't. This is a known make bug. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ [EMAIL PROTECTED] SuSE GmbHSchanzaeckerstr. 1090443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
Bug#42850: nscd resolves not every resolvable host
Hi, this is no nscd bug. It is a bug in /lib/libnss_dns.so and early glibc 2.1.2 snapshots and fixed in the final glibc 2.1.2 release. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ [EMAIL PROTECTED] SuSE GmbHSchanzaeckerstr. 1090443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
Bug#42727: nscd doesn't respect /etc/resolv.conf changes
Hi, I think, nscd should respect changes of /etc/resolv.conf. At the moment it doesn't. nscd will never respect changes of /etc/resolv.conf, because it couldn't. nscd knows nothing about DNS, it caches gethostbyname results which could also come from NIS, LDAP or /etc/hosts. Since /etc/resolv.conf is loaded by NSS, nscd couldn't do anythink. I thing /lib/libresolv.so should be fixed to respect resolv.conf This is a problem with dialup links for example. I use nscd because the DNS cache - IMHO this makes sense in case of low-bandwidth links. Many ppp programs are modifying the /etc/resolv.conf to enable Dynamic DNS via PPP. At the moment my brute force solution is restarting the nscd but this cannot be a real solution. Beside disabling the hosts cache it is the only solution in the moment. And btw... Solaris nscd provides an command line option -i cachename Invalidate the specified cache. I guess, this might be a useful option for GNU nscd too. This is implemented in the current glibc cvs archive. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ [EMAIL PROTECTED] SuSE GmbHSchanzaeckerstr. 1090443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
