glibc_2.3.6.ds1-13etch5_i386.changes ACCEPTED
Accepted: glibc-doc_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/glibc-doc_2.3.6.ds1-13etch5_all.deb glibc_2.3.6.ds1-13etch5.diff.gz to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.diff.gz glibc_2.3.6.ds1-13etch5.dsc to pool/main/g/glibc/glibc_2.3.6.ds1-13etch5.dsc libc6-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dbg_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dbg_2.3.6.ds1-13etch5_i386.deb libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dev_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-dev_2.3.6.ds1-13etch5_i386.deb libc6-i686_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-i686_2.3.6.ds1-13etch5_i386.deb libc6-pic_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-pic_2.3.6.ds1-13etch5_i386.deb libc6-prof_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-prof_2.3.6.ds1-13etch5_i386.deb libc6-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libc6-udeb_2.3.6.ds1-13etch5_i386.udeb libc6-xen_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6-xen_2.3.6.ds1-13etch5_i386.deb libc6_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/libc6_2.3.6.ds1-13etch5_i386.deb libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb to pool/main/g/glibc/libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb locales-all_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/locales-all_2.3.6.ds1-13etch5_i386.deb locales_2.3.6.ds1-13etch5_all.deb to pool/main/g/glibc/locales_2.3.6.ds1-13etch5_all.deb nscd_2.3.6.ds1-13etch5_i386.deb to pool/main/g/glibc/nscd_2.3.6.ds1-13etch5_i386.deb Override entries for your package: glibc-doc_2.3.6.ds1-13etch5_all.deb - optional doc glibc_2.3.6.ds1-13etch5.dsc - required libs libc6-amd64_2.3.6.ds1-13etch5_i386.deb - standard libs libc6-dbg_2.3.6.ds1-13etch5_i386.deb - extra libdevel libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-dev_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-i686_2.3.6.ds1-13etch5_i386.deb - extra libs libc6-pic_2.3.6.ds1-13etch5_i386.deb - optional libdevel libc6-prof_2.3.6.ds1-13etch5_i386.deb - extra libdevel libc6-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer libc6-xen_2.3.6.ds1-13etch5_i386.deb - extra libs libc6_2.3.6.ds1-13etch5_i386.deb - required libs libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb - extra debian-installer locales-all_2.3.6.ds1-13etch5_i386.deb - extra libs locales_2.3.6.ds1-13etch5_all.deb - standard libs nscd_2.3.6.ds1-13etch5_i386.deb - optional admin Announcing to [EMAIL PROTECTED] Closing bugs: 460226 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-isocodes-devel] Timezones?
On Sun, Jan 20, 2008 at 11:20:01AM +0100, Christian Perrier wrote: (if answering, please keep CC and put X-PTS-Approved: yes in headers so that [EMAIL PROTECTED] gets the mail) Quoting Clytie Siddall ([EMAIL PROTECTED]): Hi guys :) I'm in the middle of one of my running efforts to get developers to use iso-codes as a plugin/library for their software, so they won't have long lists of language names, country names, currency names etc. in their programs which we have to translate over and over again, and which they invariably fail to keep accurate or current. In this case, it's Evolution (GNOME). While paging through the huge Evolution translation file, I note that, in addition to a lo-o-ng list of language names, and an equally long list of time/date data they could get from the locale, Evo lists timezones. e.g. #. #.* These are the timezone names from the Olson timezone data. #.* We only place them here so gettext picks them up for translation. #.* Don't include in any C files. #. #: ../calendar/zones.h:7 msgid Africa/Abidjan msgstr Châu Phi/Abidjan Any chance iso-codes will take on timezones? Could be interesting. But not necessarily the way to go. However, that'd require some coordination with fellow people who (well) maintain such stuff. In Debian, the tzdata package is now well developed and maintained, for instance. I don't really know if timezones are normalized in some way. If they are, it could make sense to imagine moving this to iso-codes (so that it could benefit people outside Debian). But timezones data goes far beyond simple names: it includes information about the shift wrt UTC as well as Daylight Savings Time information. If timezones aren't normalized, I think it would maybe make more sense to keep this in a separate package/distribution. tzdata now works on a Zone/City basis. I am not sure the iso-codes also define city names. Then I guess it is mainly a question for the translators. We don't mind if the names are translated by hand or using the data from iso-codes as long as we have a .po file to drop in debian/po. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-isocodes-devel] Timezones?
Thanks very much for your helpful and enthusiastic answers. :) On 21/01/2008, at 9:20 PM, Aurelien Jarno wrote: On Sun, Jan 20, 2008 at 11:20:01AM +0100, Christian Perrier wrote: (if answering, please keep CC and put X-PTS-Approved: yes in headers so that [EMAIL PROTECTED] gets the mail) Quoting Clytie Siddall ([EMAIL PROTECTED]): Hi guys :) I'm in the middle of one of my running efforts to get developers to use iso-codes as a plugin/library for their software, so they won't have long lists of language names, country names, currency names etc. in their programs which we have to translate over and over again, and which they invariably fail to keep accurate or current. In this case, it's Evolution (GNOME). While paging through the huge Evolution translation file, I note that, in addition to a lo-o-ng list of language names, and an equally long list of time/date data they could get from the locale, Evo lists timezones. e.g. #. #.* These are the timezone names from the Olson timezone data. #.* We only place them here so gettext picks them up for translation. #.* Don't include in any C files. #. #: ../calendar/zones.h:7 msgid Africa/Abidjan msgstr Châu Phi/Abidjan Any chance iso-codes will take on timezones? Could be interesting. But not necessarily the way to go. However, that'd require some coordination with fellow people who (well) maintain such stuff. In Debian, the tzdata package is now well developed and maintained, for instance. I don't really know if timezones are normalized in some way. If they are, it could make sense to imagine moving this to iso-codes (so that it could benefit people outside Debian). But timezones data goes far beyond simple names: it includes information about the shift wrt UTC as well as Daylight Savings Time information. If timezones aren't normalized, I think it would maybe make more sense to keep this in a separate package/distribution. tzdata now works on a Zone/City basis. I am not sure the iso-codes also define city names. Then I guess it is mainly a question for the translators. We don't mind if the names are translated by hand or using the data from iso-codes as long as we have a .po file to drop in debian/po. From the translator POV, the great advantages of standardizing these lists via iso-codes are: 1. the original strings are comprehensive, accurate and correctly spelt (!) 2. we only have to translate them once, and maintain that single translation You might be amazed at the number of programs which still have mis- spelt, inaccurate and messy lists of language names, country names etc. And we have to translate them again, and again, and submit detailed bug reports about the inadequacies of the original strings. So I'm even keener to support iso-codes, including implementing other information that needs standardizing. ;) BTW, even if you haven't listed city names yet, and it would be impractible to list _all_ city names, the timezones are based on regions and sub-regions, so they are related to iso_3166-2. Perhaps the city names could be classified as part of a regional name. For example, as in: South Australia/Adelaide the timezone is the capital city tagged on to the state name. The above is my timezone (+0930, currently +0130), and it is often left out of supposed comprehensive timezone lists. ;) Thanks for all your good work. :) from Clytie Vietnamese Free Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n
Re: [Pkg-isocodes-devel] Timezones?
Hi, My vote would be not to merge tzdata translations into iso-codes, but perhaps they could share a PO compendium, etc. The reason is that iso-codes should not be tied to programs, and similarly for tzdata; despite the (current) lack of iso-codes package in debian-volatile, they should be updateable between releases, when there is a change in the data, and program compatability should not be affected. If the timezone translations are stored in the iso-codes package, then we would need to update the iso-codes package whenever either the iso-codes or timezones data are updated. BTW, the Zone/City division tzdata is, to my knowledge, not arbitrary: not all cities are listed. but ones for which there were significant time zone differences in the past. e.g I live in Galway, Ireland. Ireland and the UK share the same timezone now, even though it gets called e.g. British Summer Time in the summer and Irish Summer Time in Ireland, they are in fact changed at the same time. If you look at tzselect, etc. The time zones are listed as Europe/Dublin and Europe/London. This is (to my knowledge) NOT for simple political reasons of different countries: for a while when timezones were originally created, Dublin and London did not share the same timezone. As an astronomer, if I get a dataset, such as comet observations in Galway at the turn of the (19th) century, then I can use the Europe/Dublin tz to record them, knowing that Dublin Time prevailed at that time, even when it was several minutes different from London time. This (among other reasons) is why several cities are often used for the same tz; it is for historical rather than random arbitrary reasons. - Alastair On 21 Jan 2008, at 11:08, Clytie Siddall wrote: Thanks very much for your helpful and enthusiastic answers. :) On 21/01/2008, at 9:20 PM, Aurelien Jarno wrote: On Sun, Jan 20, 2008 at 11:20:01AM +0100, Christian Perrier wrote: (if answering, please keep CC and put X-PTS-Approved: yes in headers so that [EMAIL PROTECTED] gets the mail) Quoting Clytie Siddall ([EMAIL PROTECTED]): Hi guys :) I'm in the middle of one of my running efforts to get developers to use iso-codes as a plugin/library for their software, so they won't have long lists of language names, country names, currency names etc. in their programs which we have to translate over and over again, and which they invariably fail to keep accurate or current. In this case, it's Evolution (GNOME). While paging through the huge Evolution translation file, I note that, in addition to a lo-o-ng list of language names, and an equally long list of time/date data they could get from the locale, Evo lists timezones. e.g. #. #.* These are the timezone names from the Olson timezone data. #.* We only place them here so gettext picks them up for translation. #.* Don't include in any C files. #. #: ../calendar/zones.h:7 msgid Africa/Abidjan msgstr Châu Phi/Abidjan Any chance iso-codes will take on timezones? Could be interesting. But not necessarily the way to go. However, that'd require some coordination with fellow people who (well) maintain such stuff. In Debian, the tzdata package is now well developed and maintained, for instance. I don't really know if timezones are normalized in some way. If they are, it could make sense to imagine moving this to iso-codes (so that it could benefit people outside Debian). But timezones data goes far beyond simple names: it includes information about the shift wrt UTC as well as Daylight Savings Time information. If timezones aren't normalized, I think it would maybe make more sense to keep this in a separate package/distribution. tzdata now works on a Zone/City basis. I am not sure the iso-codes also define city names. Then I guess it is mainly a question for the translators. We don't mind if the names are translated by hand or using the data from iso-codes as long as we have a .po file to drop in debian/po. From the translator POV, the great advantages of standardizing these lists via iso-codes are: 1. the original strings are comprehensive, accurate and correctly spelt (!) 2. we only have to translate them once, and maintain that single translation You might be amazed at the number of programs which still have mis- spelt, inaccurate and messy lists of language names, country names etc. And we have to translate them again, and again, and submit detailed bug reports about the inadequacies of the original strings. So I'm even keener to support iso-codes, including implementing other information that needs standardizing. ;) BTW, even if you haven't listed city names yet, and it would be impractible to list _all_ city names, the timezones are based on regions and sub-regions, so they are related to iso_3166-2. Perhaps the city names could be classified as part of a regional name. For example, as in: South Australia/Adelaide the timezone is the capital city tagged on to the state name.
Re: [Pkg-isocodes-devel] Timezones?
Clytie Siddall a écrit : Thanks very much for your helpful and enthusiastic answers. :) On 21/01/2008, at 9:20 PM, Aurelien Jarno wrote: On Sun, Jan 20, 2008 at 11:20:01AM +0100, Christian Perrier wrote: (if answering, please keep CC and put X-PTS-Approved: yes in headers so that [EMAIL PROTECTED] gets the mail) Quoting Clytie Siddall ([EMAIL PROTECTED]): Hi guys :) I'm in the middle of one of my running efforts to get developers to use iso-codes as a plugin/library for their software, so they won't have long lists of language names, country names, currency names etc. in their programs which we have to translate over and over again, and which they invariably fail to keep accurate or current. In this case, it's Evolution (GNOME). While paging through the huge Evolution translation file, I note that, in addition to a lo-o-ng list of language names, and an equally long list of time/date data they could get from the locale, Evo lists timezones. e.g. #. #.* These are the timezone names from the Olson timezone data. #.* We only place them here so gettext picks them up for translation. #.* Don't include in any C files. #. #: ../calendar/zones.h:7 msgid Africa/Abidjan msgstr Châu Phi/Abidjan Any chance iso-codes will take on timezones? Could be interesting. But not necessarily the way to go. However, that'd require some coordination with fellow people who (well) maintain such stuff. In Debian, the tzdata package is now well developed and maintained, for instance. I don't really know if timezones are normalized in some way. If they are, it could make sense to imagine moving this to iso-codes (so that it could benefit people outside Debian). But timezones data goes far beyond simple names: it includes information about the shift wrt UTC as well as Daylight Savings Time information. If timezones aren't normalized, I think it would maybe make more sense to keep this in a separate package/distribution. tzdata now works on a Zone/City basis. I am not sure the iso-codes also define city names. Then I guess it is mainly a question for the translators. We don't mind if the names are translated by hand or using the data from iso-codes as long as we have a .po file to drop in debian/po. From the translator POV, the great advantages of standardizing these lists via iso-codes are: 1. the original strings are comprehensive, accurate and correctly spelt (!) 2. we only have to translate them once, and maintain that single translation I don't think it is very easy to change the names in tzdata (except if they are wrong). They are standardized among various UNIX systems, so the only way it can work is by importing the names from tzdata into iso-codes. Also a patch to change the names will be difficult to maintain wrt new upstream versions. From my point of view, this has to be done in the reverse way, that is importing cities from tzdata into iso-codes, and then using the translation from iso-codes in tzdata. You might be amazed at the number of programs which still have mis- spelt, inaccurate and messy lists of language names, country names etc. And we have to translate them again, and again, and submit detailed bug reports about the inadequacies of the original strings. So I'm even keener to support iso-codes, including implementing other information that needs standardizing. ;) BTW, even if you haven't listed city names yet, and it would be impractible to list _all_ city names, the timezones are based on regions and sub-regions, so they are related to iso_3166-2. Perhaps the city names could be classified as part of a regional name. For example, as in: South Australia/Adelaide the timezone is the capital city tagged on to the state name. The above is my timezone (+0930, currently +0130), and it is often left out of supposed comprehensive timezone lists. ;) This is not as easy. Timezones sometimes depends on the city, and can differ from city to city within the same region. For example there are a few cities which don't apply DST rules, while their region applies it. Also tzdata provides timezone information for the current date, but also in the past, back to early 20th century, when timezones where far less standardized than now. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
r2790 - in glibc-package/trunk/debian: . patches/any
Author: aurel32
Date: 2008-01-21 20:10:46 + (Mon, 21 Jan 2008)
New Revision: 2790
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/patches/any/local-ldso-disable-hwcap.diff
Log:
[ Aurelien Jarno ]
* patches/any/local-ldso-disable-hwcap.diff: enable tls/ directory even
when hardware capabilities are disabled. This workarounds a bug in
nvidia-glx. Closes: #453480.
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2008-01-21 01:52:58 UTC (rev
2789)
+++ glibc-package/trunk/debian/changelog2008-01-21 20:10:46 UTC (rev
2790)
@@ -8,8 +8,13 @@
* patches/hurd-i386/cvs-epfnosupport.diff: new patch to fix socket()
error for IPV6.
- -- Aurelien Jarno [EMAIL PROTECTED] Sat, 19 Jan 2008 12:01:23 +0100
+ [ Aurelien Jarno ]
+ * patches/any/local-ldso-disable-hwcap.diff: enable tls/ directory even
+when hardware capabilities are disabled. This workarounds a bug in
+nvidia-glx. Closes: #453480.
+ -- Aurelien Jarno [EMAIL PROTECTED] Mon, 21 Jan 2008 21:07:44 +0100
+
glibc (2.7-6) unstable; urgency=low
[ Aurelien Jarno ]
Modified: glibc-package/trunk/debian/patches/any/local-ldso-disable-hwcap.diff
===
--- glibc-package/trunk/debian/patches/any/local-ldso-disable-hwcap.diff
2008-01-21 01:52:58 UTC (rev 2789)
+++ glibc-package/trunk/debian/patches/any/local-ldso-disable-hwcap.diff
2008-01-21 20:10:46 UTC (rev 2790)
@@ -5,32 +5,38 @@
# DP: Upstream status: Debian-Specific
# DP: Status Details: This isn't going to be acceptable upstream, we
# DP: only need it because we support in-place upgrades.
-# DP: Date: 2003-10-28, (Updated 2005-01-02 gotom, 2007-05-20 aurel32)
+# DP: Date: 2003-10-28, (Updated 2005-01-02 gotom, 2007-05-20 aurel32,
+# DP: 2008-01-21 aurel32)
--- elf/dl-sysdep.c.orig
+++ elf/dl-sysdep.c
-@@ -408,6 +408,20 @@
+@@ -408,6 +408,25 @@
/* For TLS enabled builds always add 'tls'. */
++cnt;
+ if (__access (/etc/ld.so.nohwcap, F_OK) == 0)
+{
-+ /* If hwcap is disabled, we only have the base directory to search. */
-+ result = (struct r_strlenpair *) malloc (sizeof (*result));
++ /* If hwcap is disabled, we only have the base directory and tls to
search. */
++ *sz = 2;
++ result = (struct r_strlenpair *) malloc (*sz * sizeof (*result) + 3 +
1);
+ if (result == NULL)
-+ goto no_memory;
++goto no_memory;
+
-+ result[0].str = (char *) result; /* Does not really matter. */
-+ result[0].len = 0;
++ result[0].str = (char *) (result + *sz);
++ result[0].len = 3 + 1;
++ result[1].str = (char *) (result + *sz);
++ result[1].len = 0;
++ cp = __mempcpy ((char *) (result + *sz), tls, 3);
++ *cp = '/';
+
-+ *sz = 1;
++ *max_capstrlen = result[0].len;
+ return result;
+}
+
/* Create temporary data structure to generate result table. */
temp = (struct r_strlenpair *) alloca (cnt * sizeof (*temp));
m = 0;
-@@ -482,8 +496,11 @@
+@@ -482,8 +501,11 @@
*sz = 1 cnt;
result = (struct r_strlenpair *) malloc (*sz * sizeof (*result) + total);
if (result == NULL)
@@ -44,6 +50,7 @@
if (cnt == 1)
{
+
--- elf/dl-cache.c.orig
+++ elf/dl-cache.c
@@ -244,6 +244,7 @@
@@ -66,7 +73,7 @@
#define HWCAP_CHECK \
if (GLRO(dl_osversion) lib-osversion GLRO(dl_osversion))\
continue; \
-+ if (disable_hwcap lib-hwcap != 0) \
++ if (disable_hwcap (lib-hwcap ~_DL_HWCAP_TLS_MASK) != 0) \
+ continue; \
if (_DL_PLATFORMS_COUNT \
(lib-hwcap _DL_HWCAP_PLATFORM) != 0 \
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
r2791 - glibc-package/trunk/debian/sysdeps
Author: aurel32 Date: 2008-01-21 20:29:36 + (Mon, 21 Jan 2008) New Revision: 2791 Modified: glibc-package/trunk/debian/sysdeps/sh4.mk Log: Fix comment Modified: glibc-package/trunk/debian/sysdeps/sh4.mk === --- glibc-package/trunk/debian/sysdeps/sh4.mk 2008-01-21 20:10:46 UTC (rev 2790) +++ glibc-package/trunk/debian/sysdeps/sh4.mk 2008-01-21 20:29:36 UTC (rev 2791) @@ -1,6 +1,6 @@ # Some tests assume a fast machine TIMEOUTFACTOR=4 -# Requires Linux 2.6.9 for NPTL +# Requires Linux 2.6.11 for NPTL libc_MIN_KERNEL_SUPPORTED = 2.6.11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
