r933 - in linux-kernel-headers/branches/lkh-branch-2.6.12: . autoconfs debian
Author: gotom Date: 2005-06-18 07:23:52 + (Sat, 18 Jun 2005) New Revision: 933 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-alpha.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-amd64.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-arm.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-hppa.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-i386.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-ia64.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-m32r.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-m68k.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-mips.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-mipsel.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-powerpc.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-ppc64.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-s390.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-sh.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-sparc.h linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-sparc64.h linux-kernel-headers/branches/lkh-branch-2.6.12/debian/changelog linux-kernel-headers/branches/lkh-branch-2.6.12/version.h Log: - New upstream release 2.6.12. - autoconfs/*.h: Update. - version.h: Update. Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-alpha.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-alpha.h 2005-06-17 06:32:13 UTC (rev 932) +++ linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-alpha.h 2005-06-18 07:23:52 UTC (rev 933) @@ -1,7 +1,7 @@ /* * Automatically generated C config: don't edit - * Linux kernel version: 2.6.12-rc6 - * Sun Jun 12 15:13:46 2005 + * Linux kernel version: 2.6.12 + * Sat Jun 18 16:10:26 2005 */ #define AUTOCONF_INCLUDED #define CONFIG_ALPHA 1 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-amd64.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-amd64.h 2005-06-17 06:32:13 UTC (rev 932) +++ linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-amd64.h 2005-06-18 07:23:52 UTC (rev 933) @@ -1,7 +1,7 @@ /* * Automatically generated C config: don't edit - * Linux kernel version: 2.6.12-rc6 - * Sun Jun 12 15:13:54 2005 + * Linux kernel version: 2.6.12 + * Sat Jun 18 16:10:34 2005 */ #define AUTOCONF_INCLUDED #define CONFIG_X86_64 1 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-arm.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-arm.h 2005-06-17 06:32:13 UTC (rev 932) +++ linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-arm.h 2005-06-18 07:23:52 UTC (rev 933) @@ -1,7 +1,7 @@ /* * Automatically generated C config: don't edit - * Linux kernel version: 2.6.12-rc6 - * Sun Jun 12 15:14:02 2005 + * Linux kernel version: 2.6.12 + * Sat Jun 18 16:10:43 2005 */ #define AUTOCONF_INCLUDED #define CONFIG_ARM 1 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-hppa.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-hppa.h 2005-06-17 06:32:13 UTC (rev 932) +++ linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-hppa.h 2005-06-18 07:23:52 UTC (rev 933) @@ -1,7 +1,7 @@ /* * Automatically generated C config: don't edit - * Linux kernel version: 2.6.12-rc6 - * Sun Jun 12 15:15:02 2005 + * Linux kernel version: 2.6.12 + * Sat Jun 18 16:11:57 2005 */ #define AUTOCONF_INCLUDED #define CONFIG_PARISC 1 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-i386.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-i386.h 2005-06-17 06:32:13 UTC (rev 932) +++ linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-i386.h 2005-06-18 07:23:52 UTC (rev 933) @@ -1,7 +1,7 @@ /* * Automatically generated C config: don't edit - * Linux kernel version: 2.6.12-rc6 - * Sun Jun 12 15:14:11 2005 + * Linux kernel version: 2.6.12 + * Sat Jun 18 16:10:51 2005 */ #define AUTOCONF_INCLUDED #define CONFIG_X86 1 Modified: linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-ia64.h === --- linux-kernel-headers/branches/lkh-branch-2.6.12/autoconfs/autoconf-ia64.h 2005-06-17 06:32:13
Bug#314435: libc6-dev: struct timespec and nanosleep() not available with -std=c99
Hello Lars and Daniel, thanks much for the links and explanations! On Thu, Jun 16, 2005 at 01:37:34PM +0300, Lars Wirzenius wrote: The C standard guarantees (see page 166, 7.1.3, Reserved identifiers, if you have a copy) that the standard headers do not define identifiers that the C standard does not explicitly declare as defined by the standard, reserved for future versions of the standard, or reserved to the implementation. struct timespec and nanosleep are not such identifiers. Indeed. I've overseen that time.h is also defined by C99. I've changed my opinion regarding whether this is a libc6-dev bug. However, I still have a problem. My intention is to use -std=c99 and define macros like _BSD_SOURCE in order to document all portability issues at the top of the files. After I defined _POSIX_C_SOURCE to 200201L, I'm able to compile the file without problems. However, neither SUSv3, nor Linux man page say anything about it. That is why I used to think that struct timespec and nanosleep MUST be available after a bare #include time.h. Does POSIX specify whether the availability can be controlled with a macro? Should Linux man page be updated to mention _POSIX_C_SOURCE? BTW, defining _POSIX_SOURCE, which is described in the glibc documentation, didn't work for me. Is it a bug, or does POSIX.1 mean POSIX 1990 only? With kind regards, Baurzhan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Online computer solutions.
GET latest softwares, 99% savings. http://imryt.kr6hnjkdhu2rhl2.interdinelk.com Hell, there are no rules here--we're trying to accomplish something. Fine words! I wonder where you stole them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Buy me a Rolex
Get the Finest Rolex Watch Replica ! We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings http://www.chooseyourwatch4u.net/ you mescaline me jovial me you watershed me tachistoscope me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 07:56:10PM +0200, Vincent Lefevre wrote: Lots of Debian packages create local groups (and in fact, this is the only problem I have with local groups). So, what do you suggest? Not using Debian because it is a security bug? No. But if you want to use NIS you have to be familiar with the consequences. If your local NIS policy allows having groups with IDs 1000 in NIS maps, then you should better be prepared that automatic group creation _will_ fail and you have to fix it up manually. There is nothing Debian can do about it. $ ./grname doctex 42 (doctex) $ ./grname 42 42 (shadow) Yes, it is correct as far as libc is concerned. It is simply a system administration error. So, this is a bug in Debian. No, it's a bug in your local NIS policy if you allow group IDs 1000 being served by NIS and still expect automatic local system group creation to work. I don't have such information, but I could probably ask them. The problem is that they don't support Debian, so that their group id range will conflict with Debian's group id range (in particular because some group ids are hardcoded in Debian). Then you have no other option than to synchronize your local group IDs with NIS manually. NIS enforces a central policy that is defined by the NIS administrators. The package management system has no way to know about that policy. If you want to be part of a NIS setup you have to manually adapt the local system configuration to match the central policy. Of course, if you do not have a well-defined and well-designed NIS policy but rather it was just an ad-hoc setup then you will have difficulties... Moreover, if some group exists in the NIS database, why isn't it possible to have a copy (with the same group id) in /etc/groups? This could be useful when the NIS server is down, for instance. It is possible but you have to do it manually. This cannot be automated in general (think about the group ID being changed in NIS but not in your local copy). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314855: tr_TR.ISO-8859-9...LC_MONETARY: `int_curr_symbol' does not correspond to valid name
Package: locales Version: 2.3.5-1 Severity: serious Justification: the installation process breaks apt-get I just did an upgrade today, and locales fails to install, when it is working with tr_TR. Preparing to replace locales 2.3.2.ds1-21 (using /locales_2.3.5-1_all.deb) ... Unpacking replacement locales ... Setting up locales (2.3.5-1) ... Generating locales... [...] tr_TR.ISO-8859-9...LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217 dpkg: error processing locales (--configure): subprocess post-installation script returned error exit status 1 -- System Information: Debian Release: testing/unstable APT prefers experimental APT policy: (990, 'experimental'), (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_CA) Versions of packages locales depends on: ii debconf 1.4.51 Debian configuration management sy ii libc6 [glibc-2.3.5-1] 2.3.5-1GNU C Library: Shared libraries an locales recommends no packages. -- debconf information: * locales/default_environment_locale: None * locales/locales_to_be_generated: be_BY CP1251, bg_BG CP1251, br_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, cs_CZ ISO-8859-2, da_DK ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, de_AT ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, de_BE ISO-8859-1, de_CH ISO-8859-1, de_CH.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, de_DE ISO-8859-1, [EMAIL PROTECTED] UTF-8, de_DE.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, de_LU ISO-8859-1, el_GR ISO-8859-7, el_GR.UTF-8 UTF-8, en_AU ISO-8859-1, en_BW ISO-8859-1, en_CA ISO-8859-1, en_DK ISO-8859-1, en_GB ISO-8859-1, en_HK ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, en_IE ISO-8859-1, en_IN UTF-8, en_NZ ISO-8859-1, en_PH ISO-8859-1, en_SG ISO-8859-1, en_US ISO-8859-1, en_US.UTF-8 UTF-8, en_ZA ISO-8859-1, en_ZW ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, es_ES ISO-8859-1, es_US ISO-8859-1, et_EE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, eu_ES ISO-8859-1, fa_IR.UTF-8 UTF-8, [EMAIL PROTECTED] ISO-8859-15, fi_FI ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_BE ISO-8859-1, fr_CA ISO-8859-1, fr_CH ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, fr_LU ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, ga_IE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, gl_ES ISO-8859-1, gv_GB ISO-8859-1, he_IL ISO-8859-8, hi_IN.UTF-8 UTF-8, hr_HR ISO-8859-2, hu_HU ISO-8859-2, id_ID ISO-8859-1, is_IS ISO-8859-1, it_CH ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, it_IT ISO-8859-1, iw_IL ISO-8859-8, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, lt_LT ISO-8859-13, lv_LV ISO-8859-13, mi_NZ ISO-8859-13, mk_MK ISO-8859-5, mr_IN.UTF-8 UTF-8, ms_MY ISO-8859-1, mt_MT ISO-8859-3, [EMAIL PROTECTED] ISO-8859-15, nl_BE ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, nl_NL ISO-8859-1, nn_NO ISO-8859-1, no_NO ISO-8859-1, oc_FR ISO-8859-1, pl_PL ISO-8859-2, pt_BR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, pt_PT ISO-8859-1, ru_RU ISO-8859-5, ru_RU.KOI8-R KOI8-R, ru_RU.UTF-8 UTF-8, ru_UA KOI8-U, sk_SK ISO-8859-2, sl_SI ISO-8859-2, sq_AL ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, sv_FI ISO-8859-1, sv_SE ISO-8859-1, ta_IN UTF-8, te_IN UTF-8, th_TH TIS-620, tr_TR ISO-8859-9, uk_UA KOI8-U, vi _VN.UTF-8 UTF-8, zh_CN.GB18030 GB18030, zh_CN GB2312, zh_CN.GBK GBK, zh_CN.UTF-8 UTF-8, zh_HK BIG5-HKSCS, zh_HK.UTF-8 UTF-8, zh_TW Big5, da_DK.ISO-8859-15 ISO-8859-15, en_GB.ISO-8859-15 ISO-8859-15, en_US.ISO-8859-15 ISO-8859-15, sv_SE.ISO-8859-15 ISO-8859-15 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 314855
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.14 tags 314855 experimental Bug#314855: tr_TR.ISO-8859-9...LC_MONETARY: `int_curr_symbol' does not correspond to valid name There were no tags set. Tags added: experimental End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On 2005-06-18 23:55:13 +0200, GOMBAS Gabor wrote: No. But if you want to use NIS you have to be familiar with the consequences. If your local NIS policy allows having groups with IDs 1000 in NIS maps, then you should better be prepared that automatic group creation _will_ fail and you have to fix it up manually. There is nothing Debian can do about it. Is this rule of not having NIS group IDs 1000 standard? If so, is it possible to request that the NIS client ignores such groups? This would make sense. Why doesn't Debian give the choice to the user when assigning a gid? And why does it have hardcoded gids? i.e. why aren't gids allocated at installation time? I don't have such information, but I could probably ask them. The problem is that they don't support Debian, so that their group id range will conflict with Debian's group id range (in particular because some group ids are hardcoded in Debian). Then you have no other option than to synchronize your local group IDs with NIS manually. NIS enforces a central policy that is defined by the NIS administrators. The package management system has no way to know about that policy. Why not? For instance, there could be a file on the system that lists the gids not to be used for local groups. If you want to be part of a NIS setup you have to manually adapt the local system configuration to match the central policy. But why doesn't Debian let me do that? For instance, I modified some local gids to avoid clashes with NIS, but during a later upgrade with apt, they were set back to their original values. Moreover, if some group exists in the NIS database, why isn't it possible to have a copy (with the same group id) in /etc/groups? This could be useful when the NIS server is down, for instance. It is possible but you have to do it manually. This cannot be automated in general (think about the group ID being changed in NIS but not in your local copy). This wouldn't be a problem. I'm thinking of the slocate group, that currently exists in the NIS database. And in fact it would be much better to have such a group locally in a gid range that will not be used by the NIS administrators. Since /etc/group has the priority, this would work without any problem. More generally, it seems perfectly valid for a Debian package that needs to create a group for local use only to really create the group instead of reusing a NIS one. -- Vincent Lefvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
