Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)
Package: locales Version: 2.3.2.ds1-20 Severity: wishlist Many Debian machines don't have the en_DK locale installed. This locale is important to have ISO-8601 date format in applications that use the locales. So, it should be included by default in the generated locales. Alternatively, there could be some specific locale named ISO8601 or something like that. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1) Versions of packages locales depends on: ii debconf 1.4.46 Debian configuration management sy ii libc6 [glibc-2.3.2.ds1-20] 2.3.2.ds1-20 GNU C Library: Shared libraries an -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297010: linux-kernel-header: O_NOATIME needed for lvm
GOTO Masanori [EMAIL PROTECTED] writes: At Mon, 28 Feb 2005 03:48:00 +0100, Goswin von Brederlow wrote: Bastian's patch is just a workaround around the bug not its solution. ...So why did you submit this bug as severity: critical assigned to linux-kernel-header? What the real solution to fix this report? Can your problem be fixed to define O_NOATIME in lvm2 or linux-kernel-headers package? Regards, -- gotom I assigned the bug is to both. The headers because they have the bug and lvm because it can work around it (thereby reducing its severity to normal). If you don't think l-k-h oder libc6-dev should implement the O_NOATIME it documents then please reassign it to lvm2 alone with an explanation. That is your perogative as maintainer but I stand by my decision that it is a critical bug and both packages are involved. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297769: glibc: sched_setaffinity() provides obsolete interface
Package: glibc
Severity: grave
Justification: renders package unusable
The current Sarge glibc still provides the obsolete 2-argument
interface for sched_setaffinity(). As more software is starting to
use this system call, this is becoming a real issue because developers
will have to create a special version just for Debian.
Specifically, sched.h in libc6{,.1} currently declares:
extern int sched_setaffinity (__pid_t __pid, __const cpu_set_t *__mask)
__THROW;
whereas the proper interface has 3 arguments:
extern int sched_setaffinity (__pid_t __pid, size_t __cpusetsize,
__const cpu_set_t *__cpuset) __THROW;
(likewise for sched_getaffinity()).
Please fix this problem before Sarge goes out the door.
--david
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing')
Architecture: ia64
Kernel: Linux 2.6.11-rc2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)
On Wed, Mar 02, 2005 at 05:37:38PM +0100, Vincent Lefevre wrote: Package: locales Version: 2.3.2.ds1-20 Severity: wishlist Many Debian machines don't have the en_DK locale installed. This locale is important to have ISO-8601 date format in applications that use the locales. So, it should be included by default in the generated locales. Alternatively, there could be some specific locale named ISO8601 or something like that. That does not make sense, applications do not need any locale to write dates in the formats described in ISO 8601. Using locales for this task will cause trouble (e.g. if LC_ALL is set) without benefit. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297798: libc6: dlerror valgrind error
Package: libc6 Version: 2.3.2.ds1-20 Severity: critical Justification: breaks unrelated software the following statement AC_RaiseExc( AC_Critical, AC_For(Myself), AC_Private( AC_ ), Cannot load PEX %s of %s : %s, Fn, Name, dlerror() ); which basically serves as a printf gives following valgrind error ==8220== Invalid read of size 1 ==8220==at 0x1B906788: strlen (mac_replace_strmem.c:189) ==8220==by 0x1C0EB249: AC_vfnprintf (fnprintf_A.c:299) ==8220==by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9) ==8220==by 0x1C0EA02D: AC_VLog (ActivatorErrorHandling_A.c:136) ==8220==by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202) ==8220==by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268) ==8220==by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35) ==8220==by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent (P_Repo2Manager_A.c:759) ==8220==by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196) ==8220==by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776) ==8220==by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995) ==8220==by 0x1B910DC8: FindBehavior (StdRootManager.c:1457) ==8220==by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023) ==8220==by 0x1C0EBF42: AC_FindBehaviorByCID (ActivatorLoader_A.c:98) ==8220==by 0x804866D: main (main.c:8) ==8220== Address 0x1C4F5E58 is 0 bytes inside a block of size 74 free'd ==8220==at 0x1B907460: free (vg_replace_malloc.c:153) ==8220==by 0x1C1284FA: _dlerror_run (dlerror.c:140) ==8220==by 0x1C128153: dlsym (dlsym.c:51) ==8220==by 0x1C0FE263: write (vg_libpthread.c:2369) ==8220==by 0x1C0EFF1D: AC_WriteExt (ActivatorIo_A.c:112) ==8220==by 0x1C0EAAF8: AC_WriteToFd (fdprintf_A.c:4) ==8220==by 0x1C0EACAC: fmtout (fnprintf_A.c:63) ==8220==by 0x1C0EB8A9: AC_vfnprintf (fnprintf_A.c:506) ==8220==by 0x1C0EAB39: AC_vfdprintf (fdprintf_A.c:9) ==8220==by 0x1C0EAB70: AC_fdprintf (fdprintf_A.c:17) ==8220==by 0x1C0E9FB0: AC_VLog (ActivatorErrorHandling_A.c:118) ==8220==by 0x1C0EA3EC: AC_VRaiseExc (ActivatorErrorHandling_A.c:202) ==8220==by 0x1C0EA559: AC_RaiseExc (ActivatorErrorHandling_A.c:268) ==8220==by 0x1C5FDA8D: Repo2Pex_Load (PEX_A.c:35) ==8220==by 0x1B9192DA: Repo2Mgr_FindAndLoadParcelOfComponent (P_Repo2Manager_A.c:759) ==8220==by 0x1B90CADE: TOREPO_FindAndLoadParcel (REPO.c:196) ==8220==by 0x1B90E8A9: ILoadComponent (StdRootManager.c:776) ==8220==by 0x1B90F763: CheckCompRefQuality (StdRootManager.c:995) ==8220==by 0x1B910DC8: FindBehavior (StdRootManager.c:1457) ==8220==by 0x1B9128BD: Wrap_FindBehavior (StdRootManager.c:2023) ==8220== if i interpret this correctly then dlsym (used somewhere in the write function of valgrind), causes a free of the return string of a dlerror() which is still needed by my application because it wants to printf it. if that free occurs all the time it might break other applications too. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)
On 2005-03-02 22:11:05 +0100, Denis Barbier wrote: That does not make sense, applications do not need any locale to write dates in the formats described in ISO 8601. Using locales for this task will cause trouble (e.g. if LC_ALL is set) without benefit. Some developers (e.g. Mozilla's) don't want to display the date in anything other than the locales. -- Vincent Lefèvre [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]
Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)
On Thu, Mar 03, 2005 at 02:15:38AM +0100, Vincent Lefevre wrote: On 2005-03-02 22:11:05 +0100, Denis Barbier wrote: That does not make sense, applications do not need any locale to write dates in the formats described in ISO 8601. Using locales for this task will cause trouble (e.g. if LC_ALL is set) without benefit. Some developers (e.g. Mozilla's) don't want to display the date in anything other than the locales. Do you have an URL where this is discussed? Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297742: locales: Locale en_DK should be included by default (ISO-8601 support)
On 2005-03-03 08:06:48 +0100, Denis Barbier wrote: On Thu, Mar 03, 2005 at 02:15:38AM +0100, Vincent Lefevre wrote: Some developers (e.g. Mozilla's) don't want to display the date in anything other than the locales. Do you have an URL where this is discussed? https://bugzilla.mozilla.org/show_bug.cgi?id=140814 -- Vincent Lefèvre [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]
