Bug#214898: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 11:10:55AM +0900, GOTO Masanori wrote: > At Wed, 22 Oct 2003 11:24:19 -0400, > Daniel Jacobowitz wrote: > > Currently, the default locale setting for the system can be accessed > > only through /etc/environment, which is a configuration file for PAM. > > Setting the locale for a daemon currently requires to parse this file, > > but it is just not the way to go. > > > > If, additionnaly to the /etc/environment stuff, the debconf-selected > > locale was put into /etc/default_locale (a file just containing the > > locale, nothing else), as suggested Ryan Murray, it would make it much > > easier for daemons to set their locale to the system default, without > > relying on an error-prone environment setting. > > Such a file would be necessary to get a correctly localized gdm for > > sarge. > > > > I think it is fairly easy to achieve, and it could even be used later > > (after the sarge release) to set the locale using a specific PAM module, > > instead of using pam_env. > > This wishlist needs a bit consideration. > > (1) We store locale setting for 2 files - /etc/environment, > /etc/default_locale. Is it good idea? > > (2) Why do you need to read /etc/default_locale instead of > /etc/environment? Is it hard to parse /etc/environment so hard? The locales package already gets it wrong, as it happens. :-) It assumes that quoting is supported when it isn't. I expect that others would make the same mistake. > (3) I guess gdm issue is the locale dialog in the login screen. Why > can't gdm read /etc/environment file? If you mean it's easier to > read /etc/default_locale than to parse /etc/environment, yes it > may become one of the reason. But does this change fix the gdm > issue? /etc/environment is a configuration file owned by PAM and parsed by the pam_env module at login time. As such, it's a good place to set the default locale for PAM sessions. However, all the world is not a PAM session. gdm before login is one example; init scripts are another; perhaps the "login:" banner is a third. I don't think it's right for these programs to be parsing a PAM configuration file when they aren't dealing with PAM sessions; they're a completely separate case. In fact, I can certainly imagine cases where I'd want the outside-a-session locale and the default PAM session locale to be different. Say I speak French, but most of my users are German, so for their benefit I decide that the default session locale should be German, but I want to see init scripts localized in French so that I can work out what's going on more easily. Or maybe I want to use LANG=C for init scripts but default to a Unicode locale for sessions where I expect terminal support to be better. It seems to me that having separate configuration for locales outside and inside a session could be useful in the same way as having different locales for different sessions. I'd suggest, though, that /etc/default_locale is a poor name for this; it sounds like it's the file you want to edit for the default locale throughout the system, when in fact it just applies to programs running before login. How about something like /etc/boot-locale or /etc/default/boot-locale, with a comment at the top when generated by locales explaining its purpose? Or maybe /etc/environment-prelogin or similar would be a better name, and it wouldn't have to be limited to locale configuration. Either way, the format should be simple and clearly specified somewhere that's easy to find so that people don't make the mistakes they do when trying to parse /etc/environment. I've cc'ed the PAM maintainer in case I've made any grievous errors in the above. Is there support for comments in /etc/environment? If so, we could also add a comment there directing people to /etc/default/boot-locale or whatever for things that are to affect programs that run before login. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#214898: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 11:10:55AM +0900, GOTO Masanori wrote: > At Wed, 22 Oct 2003 11:24:19 -0400, > Daniel Jacobowitz wrote: > > Currently, the default locale setting for the system can be accessed > > only through /etc/environment, which is a configuration file for PAM. > > Setting the locale for a daemon currently requires to parse this file, > > but it is just not the way to go. > > > > If, additionnaly to the /etc/environment stuff, the debconf-selected > > locale was put into /etc/default_locale (a file just containing the > > locale, nothing else), as suggested Ryan Murray, it would make it much > > easier for daemons to set their locale to the system default, without > > relying on an error-prone environment setting. > > Such a file would be necessary to get a correctly localized gdm for > > sarge. > > > > I think it is fairly easy to achieve, and it could even be used later > > (after the sarge release) to set the locale using a specific PAM module, > > instead of using pam_env. > > This wishlist needs a bit consideration. > > (1) We store locale setting for 2 files - /etc/environment, > /etc/default_locale. Is it good idea? > > (2) Why do you need to read /etc/default_locale instead of > /etc/environment? Is it hard to parse /etc/environment so hard? The locales package already gets it wrong, as it happens. :-) It assumes that quoting is supported when it isn't. I expect that others would make the same mistake. > (3) I guess gdm issue is the locale dialog in the login screen. Why > can't gdm read /etc/environment file? If you mean it's easier to > read /etc/default_locale than to parse /etc/environment, yes it > may become one of the reason. But does this change fix the gdm > issue? /etc/environment is a configuration file owned by PAM and parsed by the pam_env module at login time. As such, it's a good place to set the default locale for PAM sessions. However, all the world is not a PAM session. gdm before login is one example; init scripts are another; perhaps the "login:" banner is a third. I don't think it's right for these programs to be parsing a PAM configuration file when they aren't dealing with PAM sessions; they're a completely separate case. In fact, I can certainly imagine cases where I'd want the outside-a-session locale and the default PAM session locale to be different. Say I speak French, but most of my users are German, so for their benefit I decide that the default session locale should be German, but I want to see init scripts localized in French so that I can work out what's going on more easily. Or maybe I want to use LANG=C for init scripts but default to a Unicode locale for sessions where I expect terminal support to be better. It seems to me that having separate configuration for locales outside and inside a session could be useful in the same way as having different locales for different sessions. I'd suggest, though, that /etc/default_locale is a poor name for this; it sounds like it's the file you want to edit for the default locale throughout the system, when in fact it just applies to programs running before login. How about something like /etc/boot-locale or /etc/default/boot-locale, with a comment at the top when generated by locales explaining its purpose? Or maybe /etc/environment-prelogin or similar would be a better name, and it wouldn't have to be limited to locale configuration. Either way, the format should be simple and clearly specified somewhere that's easy to find so that people don't make the mistakes they do when trying to parse /etc/environment. I've cc'ed the PAM maintainer in case I've made any grievous errors in the above. Is there support for comments in /etc/environment? If so, we could also add a comment there directing people to /etc/default/boot-locale or whatever for things that are to affect programs that run before login. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Tue, Oct 28, 2003 at 01:14:16AM +0100, Denis Barbier wrote:
> On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote:
> > As some of you may have seen, there's a new version of glibc in unstable.
> > It has a couple of nice features - particularly for x86, where both
> > i686-optimized libraries and NPTL support are included. There are also
> > sparcv9 libraries. And the packaging has been totally redone for a number
> > of benefits.
> [...]
>
> When reading the sources I get the feeling that some bugs are back:
> #211733: typo in manpages/iconv.1
> #211984: typo in manpages/rpcgen.1
> #210301: locale-gen calls "unset POSIXLY_CORRECT" unconditionnally.
> About this one, I believe that test -n "${POSIXLY_CORRECT+set}"
> is a better fix, unless we know exactly what to do if
> POSIXLY_CORRECT is set to an empty value (this change is not
> included in the attached patch).
>
> Denis
Thank you very much. Looks like merge errors; I've fixed these (and
iconv.pod while I was there).
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote:
> As some of you may have seen, there's a new version of glibc in unstable.
> It has a couple of nice features - particularly for x86, where both
> i686-optimized libraries and NPTL support are included. There are also
> sparcv9 libraries. And the packaging has been totally redone for a number
> of benefits.
[...]
When reading the sources I get the feeling that some bugs are back:
#211733: typo in manpages/iconv.1
#211984: typo in manpages/rpcgen.1
#210301: locale-gen calls "unset POSIXLY_CORRECT" unconditionnally.
About this one, I believe that test -n "${POSIXLY_CORRECT+set}"
is a better fix, unless we know exactly what to do if
POSIXLY_CORRECT is set to an empty value (this change is not
included in the attached patch).
Denis
diff -ur --exclude=CVS debian/local/manpages/iconv.1
../glibc-package/debian/manpages/iconv.1
--- debian/local/manpages/iconv.1 2003-09-22 23:33:35.0 +0200
+++ ../glibc-package/debian/manpages/iconv.12003-10-25 22:20:13.0 +0200
@@ -214,7 +211,7 @@
.PP
\fB--output\fR, \fB\-o\fR \fIfile\fR
.PP
-Specify output file (instead of stdin)
+Specify output file (instead of stdout)
.PP
\fB--verbose\fR
.PP
diff -ur --exclude=CVS debian/local/manpages/rpcgen.1
../glibc-package/debian/manpages/rpcgen.1
--- debian/local/manpages/rpcgen.1 2003-09-22 23:33:35.0 +0200
+++ ../glibc-package/debian/manpages/rpcgen.1 2003-10-25 22:20:13.0 +0200
@@ -313,8 +313,9 @@
\f4\-m\f1,
\f4\-n\f1,
\f4\-s\f1,
-\f4\-s\Sc,
-\f4\-s\Ss
+\f4\-Sc\f1,
+\f4\-Sm\f1,
+\f4\-Ss\f1,
and
\f4\-t\f1
modes only).
@@ -343,6 +344,9 @@
Generate sample code to show the use of remote procedure and how to bind
to the server before calling the client side stubs generated by rpcgen.
.TP
+\f4\-Sm\f1
+Generate a sample Makefile which can be used for compiling the application.
+.TP
\f4\-Ss\f1
Generate skeleton code for the remote procedures on the server side. You would need
to fill in the actual code for the remote procedures.
--- debian/local/usr_sbin/locale-gen2003-09-22 23:33:35.0 +0200
+++ ../glibc-package/debian/locales/usr/sbin/locale-gen 2003-10-25 22:20:13.0
+0200
@@ -4,7 +4,10 @@
LOCALEGEN=/etc/locale.gen
LOCALES=/usr/share/i18n/locales
-unset POSIXLY_CORRECT
+if [ -n "$POSIXLY_CORRECT" ]; then
+ unset POSIXLY_CORRECT
+fi
+
[ -f $LOCALEGEN -a -s $LOCALEGEN ] || exit 0;
Re: Testing/help needed - experimental glibc version
On Fri, Oct 24, 2003 at 12:47:11PM +1000, Ian Wienand wrote: > On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: > > Sure, I suppose so. Send me a dpatch against the linux-kernel-headers > > package, please? > > Did you maybe mean a patch? It doesn't seem to use dpatches. Thanks! I'll get a new -3 into incoming (for what difference it makes, since it's still in NEW). > > -i > diff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch > linux-2.6.0-test7-bk/debian/patches/elf.h.patch > --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch 1970-01-01 > 00:00:00.0 + > +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 > 02:43:43.247988275 + > @@ -0,0 +1,12 @@ > +# Stop warnings about redefined symbols in glibc > +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 > 02:26:14.622024559 + > linux-2.6.0-test7-bk/include/asm-ia64/elf.h 2003-10-24 > 02:27:33.785109526 + > +@@ -42,8 +42,6 @@ > + */ > + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) > + > +-#define PT_IA_64_UNWIND 0x7001 > +- > + /* IA-64 relocations: */ > + #define R_IA64_NONE 0x00/* none */ > + #define R_IA64_IMM140x21/* symbol + addend, add imm14 */ -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
On Fri, Oct 24, 2003 at 12:47:11PM +1000, Ian Wienand wrote: > On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: > > Sure, I suppose so. Send me a dpatch against the linux-kernel-headers > > package, please? > > Did you maybe mean a patch? It doesn't seem to use dpatches. Thanks! I'll get a new -3 into incoming (for what difference it makes, since it's still in NEW). > > -i > diff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch > linux-2.6.0-test7-bk/debian/patches/elf.h.patch > --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch 1970-01-01 > 00:00:00.0 + > +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 02:43:43.247988275 > + > @@ -0,0 +1,12 @@ > +# Stop warnings about redefined symbols in glibc > +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 02:26:14.622024559 > + > linux-2.6.0-test7-bk/include/asm-ia64/elf.h 2003-10-24 02:27:33.785109526 > + > +@@ -42,8 +42,6 @@ > + */ > + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) > + > +-#define PT_IA_64_UNWIND 0x7001 > +- > + /* IA-64 relocations: */ > + #define R_IA64_NONE 0x00/* none */ > + #define R_IA64_IMM140x21/* symbol + addend, add imm14 */ -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: > Sure, I suppose so. Send me a dpatch against the linux-kernel-headers > package, please? Did you maybe mean a patch? It doesn't seem to use dpatches. -idiff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch linux-2.6.0-test7-bk/debian/patches/elf.h.patch --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch1970-01-01 00:00:00.0 + +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 02:43:43.247988275 + @@ -0,0 +1,12 @@ +# Stop warnings about redefined symbols in glibc +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 02:26:14.622024559 + linux-2.6.0-test7-bk/include/asm-ia64/elf.h2003-10-24 02:27:33.785109526 + +@@ -42,8 +42,6 @@ + */ + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) + +-#define PT_IA_64_UNWIND 0x7001 +- + /* IA-64 relocations: */ + #define R_IA64_NONE 0x00/* none */ + #define R_IA64_IMM14 0x21/* symbol + addend, add imm14 */
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 08:31:16AM -0400, Daniel Jacobowitz wrote: > Sure, I suppose so. Send me a dpatch against the linux-kernel-headers > package, please? Did you maybe mean a patch? It doesn't seem to use dpatches. -idiff -urN linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch linux-2.6.0-test7-bk/debian/patches/elf.h.patch --- linux-2.6.0-test7-bk-orig/debian/patches/elf.h.patch1970-01-01 00:00:00.0 + +++ linux-2.6.0-test7-bk/debian/patches/elf.h.patch 2003-10-24 02:43:43.247988275 + @@ -0,0 +1,12 @@ +# Stop warnings about redefined symbols in glibc +--- linux-2.6.0-test7-bk-orig/include/asm-ia64/elf.h 2003-10-24 02:26:14.622024559 + linux-2.6.0-test7-bk/include/asm-ia64/elf.h2003-10-24 02:27:33.785109526 + +@@ -42,8 +42,6 @@ + */ + #define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x8) + +-#define PT_IA_64_UNWIND 0x7001 +- + /* IA-64 relocations: */ + #define R_IA64_NONE 0x00/* none */ + #define R_IA64_IMM14 0x21/* symbol + addend, add imm14 */
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 02:02:51PM +1000, Ian Wienand wrote: > On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > > If you want to try it out, copy the relevant bits from i386.mk into > > ia64.mk in debian/sysdeps/; it should be pretty easy. > > The attached makes the build go a lot faster for me :) > > Also, as I mentioned in this thread > > http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html > > IA64 gets a lot of warnings from a redefined symbol. Should this be > modified with a dpatch in kernel-headers? Sure, I suppose so. Send me a dpatch against the linux-kernel-headers package, please? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 02:02:51PM +1000, Ian Wienand wrote: > On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > > If you want to try it out, copy the relevant bits from i386.mk into > > ia64.mk in debian/sysdeps/; it should be pretty easy. > > The attached makes the build go a lot faster for me :) > > Also, as I mentioned in this thread > > http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html > > IA64 gets a lot of warnings from a redefined symbol. Should this be > modified with a dpatch in kernel-headers? Sure, I suppose so. Send me a dpatch against the linux-kernel-headers package, please? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#214898: Testing/help needed - experimental glibc version
Josselin Mouette <[EMAIL PROTECTED]> said: > Le jeu 23/10/2003 à 04:10, GOTO Masanori a écrit : >> This wishlist needs a bit consideration. >> >> (1) We store locale setting for 2 files - /etc/environment, >> /etc/default_locale. Is it good idea? > > That's why I suggest to make it temporarily. The locale setting could > also be read here by PAM. > >> (2) Why do you need to read /etc/default_locale instead of >> /etc/environment? Is it hard to parse /etc/environment so hard? > > It is not hard, but you have to be careful with the fact > /etc/environment can contain spaces. > >> (3) I guess gdm issue is the locale dialog in the login screen. Why >> can't gdm read /etc/environment file? If you mean it's easier to >> read /etc/default_locale than to parse /etc/environment, yes it >> may become one of the reason. But does this change fix the gdm >> issue? > > Basically, the gdm maintainer refuses to include code to parse > /etc/environment. While I think parsing it would be a fine solution, I > also agree with the fact having a special file for this configuration > setting would be better. > > If you have arguments that can convince Ryan to parse /etc/environment > until there is a cleaner solution, please show them. Having it not > localized correctly when it is so easy to achieve is slightly annoying - > but I fear Ryan is one of those English-speaking maintainers who don't > care about proper i18n. Any idea of the choice made by others distros like RedHat or Mandrake to fix that problem? -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Bug#214898: Testing/help needed - experimental glibc version
Le jeu 23/10/2003 à 04:10, GOTO Masanori a écrit : > This wishlist needs a bit consideration. > > (1) We store locale setting for 2 files - /etc/environment, > /etc/default_locale. Is it good idea? That's why I suggest to make it temporarily. The locale setting could also be read here by PAM. > (2) Why do you need to read /etc/default_locale instead of > /etc/environment? Is it hard to parse /etc/environment so hard? It is not hard, but you have to be careful with the fact /etc/environment can contain spaces. > (3) I guess gdm issue is the locale dialog in the login screen. Why > can't gdm read /etc/environment file? If you mean it's easier to > read /etc/default_locale than to parse /etc/environment, yes it > may become one of the reason. But does this change fix the gdm > issue? Basically, the gdm maintainer refuses to include code to parse /etc/environment. While I think parsing it would be a fine solution, I also agree with the fact having a special file for this configuration setting would be better. If you have arguments that can convince Ryan to parse /etc/environment until there is a cleaner solution, please show them. Having it not localized correctly when it is so easy to achieve is slightly annoying - but I fear Ryan is one of those English-speaking maintainers who don't care about proper i18n. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Bug#214898: Testing/help needed - experimental glibc version
Josselin Mouette <[EMAIL PROTECTED]> said: > Le jeu 23/10/2003 à 04:10, GOTO Masanori a écrit : >> This wishlist needs a bit consideration. >> >> (1) We store locale setting for 2 files - /etc/environment, >> /etc/default_locale. Is it good idea? > > That's why I suggest to make it temporarily. The locale setting could > also be read here by PAM. > >> (2) Why do you need to read /etc/default_locale instead of >> /etc/environment? Is it hard to parse /etc/environment so hard? > > It is not hard, but you have to be careful with the fact > /etc/environment can contain spaces. > >> (3) I guess gdm issue is the locale dialog in the login screen. Why >> can't gdm read /etc/environment file? If you mean it's easier to >> read /etc/default_locale than to parse /etc/environment, yes it >> may become one of the reason. But does this change fix the gdm >> issue? > > Basically, the gdm maintainer refuses to include code to parse > /etc/environment. While I think parsing it would be a fine solution, I > also agree with the fact having a special file for this configuration > setting would be better. > > If you have arguments that can convince Ryan to parse /etc/environment > until there is a cleaner solution, please show them. Having it not > localized correctly when it is so easy to achieve is slightly annoying - > but I fear Ryan is one of those English-speaking maintainers who don't > care about proper i18n. Any idea of the choice made by others distros like RedHat or Mandrake to fix that problem? -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#214898: Testing/help needed - experimental glibc version
Le jeu 23/10/2003 à 04:10, GOTO Masanori a écrit : > This wishlist needs a bit consideration. > > (1) We store locale setting for 2 files - /etc/environment, > /etc/default_locale. Is it good idea? That's why I suggest to make it temporarily. The locale setting could also be read here by PAM. > (2) Why do you need to read /etc/default_locale instead of > /etc/environment? Is it hard to parse /etc/environment so hard? It is not hard, but you have to be careful with the fact /etc/environment can contain spaces. > (3) I guess gdm issue is the locale dialog in the login screen. Why > can't gdm read /etc/environment file? If you mean it's easier to > read /etc/default_locale than to parse /etc/environment, yes it > may become one of the reason. But does this change fix the gdm > issue? Basically, the gdm maintainer refuses to include code to parse /etc/environment. While I think parsing it would be a fine solution, I also agree with the fact having a special file for this configuration setting would be better. If you have arguments that can convince Ryan to parse /etc/environment until there is a cleaner solution, please show them. Having it not localized correctly when it is so easy to achieve is slightly annoying - but I fear Ryan is one of those English-speaking maintainers who don't care about proper i18n. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 02:02:51PM +1000, Ian Wienand wrote: > > If you want to try it out, copy the relevant bits from i386.mk into > > ia64.mk in debian/sysdeps/; it should be pretty easy. > The attached makes the build go a lot faster for me :) I've committed a slightly different fix to CVS. Thanks! Tks, Jeff Bailey
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > > I built the new packages on one of our boxes, it appears to work > > fine, however NPTL wasn't included. Before I look into it too much > > futher I thought I might do your packages support NPTL it on ia64, > > and are there any flags etc I need to turn it on? > No, it does not. I believe that everything that would be necessary > for ia64 to work is included in sarge at this point but I didn't want > to enable NPTL without really being able to test it. I have not manged to successfully compile a 2.6 kernel for ia64 (I haven't put alot of time into it, mind you). If someone can put a .deb of one up on people.debian.org somewhere for me, I'll cheerfully get NPTL running. If you're not a DD and want to help, please send clear instructions on how to usefully get a kernel built, including your .config file. There's otherwise no reason why ia64 shouldn't have NPTL. Tks, Jeff Bailey
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > If you want to try it out, copy the relevant bits from i386.mk into > ia64.mk in debian/sysdeps/; it should be pretty easy. The attached makes the build go a lot faster for me :) Also, as I mentioned in this thread http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html IA64 gets a lot of warnings from a redefined symbol. Should this be modified with a dpatch in kernel-headers? -i--- ./patch_against/glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:56:08.591766882 + +++ ./glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:57:36.305632995 + @@ -3,6 +3,9 @@ # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +# Use as many processors as there are available +NJOBS=$(shell if [ -f /proc/cpuinfo ] ; then echo `cat /proc/cpuinfo | grep 'processor' | wc -l` ; else echo 1 ; fi) + $(patsubst %,mkbuilddir_%,$(GLIBC_PASSES)) :: mkbuilddir_% : $(stamp)mkbuilddir_% $(stamp)mkbuilddir_%: $(stamp)patch-stamp $(LINUX_HEADER_DIR) @echo Making builddir for $(curpass) @@ -45,7 +48,7 @@ $(patsubst %,build_%,$(GLIBC_PASSES)) :: build_% : $(stamp)build_% $(stamp)build_%: $(stamp)configure_% @echo Building $(curpass) - $(MAKE) -C $(DEB_BUILDDIR) 2>&1 | tee -a $(log_build) + $(MAKE) -C $(DEB_BUILDDIR) -j $(NJOBS) 2>&1 | tee -a $(log_build) touch $@ $(patsubst %,check_%,$(GLIBC_PASSES)) :: check_% : $(stamp)check_%
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 02:02:51PM +1000, Ian Wienand wrote: > > If you want to try it out, copy the relevant bits from i386.mk into > > ia64.mk in debian/sysdeps/; it should be pretty easy. > The attached makes the build go a lot faster for me :) I've committed a slightly different fix to CVS. Thanks! Tks, Jeff Bailey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > > I built the new packages on one of our boxes, it appears to work > > fine, however NPTL wasn't included. Before I look into it too much > > futher I thought I might do your packages support NPTL it on ia64, > > and are there any flags etc I need to turn it on? > No, it does not. I believe that everything that would be necessary > for ia64 to work is included in sarge at this point but I didn't want > to enable NPTL without really being able to test it. I have not manged to successfully compile a 2.6 kernel for ia64 (I haven't put alot of time into it, mind you). If someone can put a .deb of one up on people.debian.org somewhere for me, I'll cheerfully get NPTL running. If you're not a DD and want to help, please send clear instructions on how to usefully get a kernel built, including your .config file. There's otherwise no reason why ia64 shouldn't have NPTL. Tks, Jeff Bailey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 09:44:57AM +1000, Ian Wienand wrote: > On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > > As some of you may have seen, there's a new version of glibc in unstable. > > It has a couple of nice features - particularly for x86, where both > > i686-optimized libraries and NPTL support are included. > > Hi, I've been silently following this and it looks really great. > > I built the new packages on one of our boxes, it appears to work fine, > however NPTL wasn't included. Before I look into it too much futher I > thought I might do your packages support NPTL it on ia64, and are > there any flags etc I need to turn it on? > > Thanks for your work, No, it does not. I believe that everything that would be necessary for ia64 to work is included in sarge at this point but I didn't want to enable NPTL without really being able to test it. If you want to try it out, copy the relevant bits from i386.mk into ia64.mk in debian/sysdeps/; it should be pretty easy. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
At Wed, 22 Oct 2003 11:24:19 -0400, Daniel Jacobowitz wrote: > On Wed, Oct 22, 2003 at 05:02:56PM +0200, Josselin Mouette wrote: > > Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > > > As some of you may have seen, there's a new version of glibc in unstable. > > > It has a couple of nice features - particularly for x86, where both > > > i686-optimized libraries and NPTL support are included. There are also > > > sparcv9 libraries. And the packaging has been totally redone for a number > > > of benefits. > > > > Do you intend to make these packages support a system-wide locale > > setting as explained in bug#214898 ? This is a one-liner change which > > would bring huge improvement for e.g. gdm or cups. Or do you think it > > should be discussed further, and/or wait for after sarge? > > These packages are to address a particular problem - updating the > version to support NPTL and TLS, without breaking everyone else. So in > this context, no. > > In general I don't handle locale-related bugs so you'll have to get a > response to that bug from one of our other glibc maintainers on > debian-glibc. OK, I check it. > Currently, the default locale setting for the system can be accessed > only through /etc/environment, which is a configuration file for PAM. > Setting the locale for a daemon currently requires to parse this file, > but it is just not the way to go. > > If, additionnaly to the /etc/environment stuff, the debconf-selected > locale was put into /etc/default_locale (a file just containing the > locale, nothing else), as suggested Ryan Murray, it would make it much > easier for daemons to set their locale to the system default, without > relying on an error-prone environment setting. > Such a file would be necessary to get a correctly localized gdm for > sarge. > > I think it is fairly easy to achieve, and it could even be used later > (after the sarge release) to set the locale using a specific PAM module, > instead of using pam_env. This wishlist needs a bit consideration. (1) We store locale setting for 2 files - /etc/environment, /etc/default_locale. Is it good idea? (2) Why do you need to read /etc/default_locale instead of /etc/environment? Is it hard to parse /etc/environment so hard? (3) I guess gdm issue is the locale dialog in the login screen. Why can't gdm read /etc/environment file? If you mean it's easier to read /etc/default_locale than to parse /etc/environment, yes it may become one of the reason. But does this change fix the gdm issue? Regards, -- gotom
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 10:13:44PM -0400, Daniel Jacobowitz wrote: > If you want to try it out, copy the relevant bits from i386.mk into > ia64.mk in debian/sysdeps/; it should be pretty easy. The attached makes the build go a lot faster for me :) Also, as I mentioned in this thread http://sources.redhat.com/ml/libc-alpha/2003-09/msg00256.html IA64 gets a lot of warnings from a redefined symbol. Should this be modified with a dpatch in kernel-headers? -i--- ./patch_against/glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:56:08.591766882 + +++ ./glibc-2.3.2.ds1/debian/rules.d/build.mk 2003-10-23 03:57:36.305632995 + @@ -3,6 +3,9 @@ # This little bit of magic makes it possible: xx=$(if $($(curpass)_$(1)),$($(curpass)_$(1)),$($(1))) +# Use as many processors as there are available +NJOBS=$(shell if [ -f /proc/cpuinfo ] ; then echo `cat /proc/cpuinfo | grep 'processor' | wc -l` ; else echo 1 ; fi) + $(patsubst %,mkbuilddir_%,$(GLIBC_PASSES)) :: mkbuilddir_% : $(stamp)mkbuilddir_% $(stamp)mkbuilddir_%: $(stamp)patch-stamp $(LINUX_HEADER_DIR) @echo Making builddir for $(curpass) @@ -45,7 +48,7 @@ $(patsubst %,build_%,$(GLIBC_PASSES)) :: build_% : $(stamp)build_% $(stamp)build_%: $(stamp)configure_% @echo Building $(curpass) - $(MAKE) -C $(DEB_BUILDDIR) 2>&1 | tee -a $(log_build) + $(MAKE) -C $(DEB_BUILDDIR) -j $(NJOBS) 2>&1 | tee -a $(log_build) touch $@ $(patsubst %,check_%,$(GLIBC_PASSES)) :: check_% : $(stamp)check_%
Re: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 09:44:57AM +1000, Ian Wienand wrote: > On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > > As some of you may have seen, there's a new version of glibc in unstable. > > It has a couple of nice features - particularly for x86, where both > > i686-optimized libraries and NPTL support are included. > > Hi, I've been silently following this and it looks really great. > > I built the new packages on one of our boxes, it appears to work fine, > however NPTL wasn't included. Before I look into it too much futher I > thought I might do your packages support NPTL it on ia64, and are > there any flags etc I need to turn it on? > > Thanks for your work, No, it does not. I believe that everything that would be necessary for ia64 to work is included in sarge at this point but I didn't want to enable NPTL without really being able to test it. If you want to try it out, copy the relevant bits from i386.mk into ia64.mk in debian/sysdeps/; it should be pretty easy. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
At Wed, 22 Oct 2003 11:24:19 -0400, Daniel Jacobowitz wrote: > On Wed, Oct 22, 2003 at 05:02:56PM +0200, Josselin Mouette wrote: > > Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > > > As some of you may have seen, there's a new version of glibc in unstable. > > > It has a couple of nice features - particularly for x86, where both > > > i686-optimized libraries and NPTL support are included. There are also > > > sparcv9 libraries. And the packaging has been totally redone for a number > > > of benefits. > > > > Do you intend to make these packages support a system-wide locale > > setting as explained in bug#214898 ? This is a one-liner change which > > would bring huge improvement for e.g. gdm or cups. Or do you think it > > should be discussed further, and/or wait for after sarge? > > These packages are to address a particular problem - updating the > version to support NPTL and TLS, without breaking everyone else. So in > this context, no. > > In general I don't handle locale-related bugs so you'll have to get a > response to that bug from one of our other glibc maintainers on > debian-glibc. OK, I check it. > Currently, the default locale setting for the system can be accessed > only through /etc/environment, which is a configuration file for PAM. > Setting the locale for a daemon currently requires to parse this file, > but it is just not the way to go. > > If, additionnaly to the /etc/environment stuff, the debconf-selected > locale was put into /etc/default_locale (a file just containing the > locale, nothing else), as suggested Ryan Murray, it would make it much > easier for daemons to set their locale to the system default, without > relying on an error-prone environment setting. > Such a file would be necessary to get a correctly localized gdm for > sarge. > > I think it is fairly easy to achieve, and it could even be used later > (after the sarge release) to set the locale using a specific PAM module, > instead of using pam_env. This wishlist needs a bit consideration. (1) We store locale setting for 2 files - /etc/environment, /etc/default_locale. Is it good idea? (2) Why do you need to read /etc/default_locale instead of /etc/environment? Is it hard to parse /etc/environment so hard? (3) I guess gdm issue is the locale dialog in the login screen. Why can't gdm read /etc/environment file? If you mean it's easier to read /etc/default_locale than to parse /etc/environment, yes it may become one of the reason. But does this change fix the gdm issue? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > As some of you may have seen, there's a new version of glibc in unstable. > It has a couple of nice features - particularly for x86, where both > i686-optimized libraries and NPTL support are included. Hi, I've been silently following this and it looks really great. I built the new packages on one of our boxes, it appears to work fine, however NPTL wasn't included. Before I look into it too much futher I thought I might do your packages support NPTL it on ia64, and are there any flags etc I need to turn it on? Thanks for your work, -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > As some of you may have seen, there's a new version of glibc in unstable. > It has a couple of nice features - particularly for x86, where both > i686-optimized libraries and NPTL support are included. Hi, I've been silently following this and it looks really great. I built the new packages on one of our boxes, it appears to work fine, however NPTL wasn't included. Before I look into it too much futher I thought I might do your packages support NPTL it on ia64, and are there any flags etc I need to turn it on? Thanks for your work, -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 02:00:50PM -0200, Felipe Almeida Lessa wrote: > Segundo os pergaminhos sagrados, alguém chamado Daniel Jacobowitz <[EMAIL > PROTECTED]> escreveu: > > > Now, we need to find the problems I _don't_ know about. I'd like for those > > who feel comfortable testing a new glibc - usual caveats about the quality > > of experimental software! - to give it a try. Use it, let us know what > > happens. Don't upload Debian packages to the archive built against it, > > obviously - they won't be installable because of the >= 2.3.2.ds1 dependency > > in shlibs. If you have a kernel above 2.4.something, below 2.6, and an > > i686, you'll get i686 optimized libraries - er, I don't know if they'll work > > on a Via C3, I didn't check :( Probably not. If you have a kernel at least > > 2.6.0-test on an i486 or above, you'll get NPTL. > > [Please CC me, I'm subscribed to debian-devel only] > > I'm using 2.6.0-test8 (compiled myself, just don't like distro > kernels) on a K6-II (i586) and NTPL just doesn't work. After dpkg > unpackaged the new libc6, it stopped working. I tried to open > aptitude again, and it said "Illegal instruction". I tried to reboot > but init failed just like the others -- had to SysRq-S SysRq-U > SysRq-B. After the (forced) reboot, init doesn't even print any > message. > > After all these things, I tried my ol' 2.4.22. Yeah, it works! But > not optimized (i586 < i686)... So I downgraded libc6* and locales to > unstable ones. OK, sounds like something's wrong with NPTL on a 586... could you test further? What I'd really like would be a core dump; unless core dumps are disabled (ulimit -c) you ought to have gotten one when aptitude crashed. FYI, with the new libc6 installed and 2.6.0-test8 you should be able to say "LD_ASSUME_KERNEL=2.4.22 aptitude" and that should work (disabling NPTL). So if you can get up a core file, load it up using LD_ASSUME_KERNEL=2.4.22 gdb aptitude core and give us the output of info registers disassemble -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
Segundo os pergaminhos sagrados, alguÃm chamado Daniel Jacobowitz <[EMAIL PROTECTED]> escreveu: > Now, we need to find the problems I _don't_ know about. I'd like for those > who feel comfortable testing a new glibc - usual caveats about the quality > of experimental software! - to give it a try. Use it, let us know what > happens. Don't upload Debian packages to the archive built against it, > obviously - they won't be installable because of the >= 2.3.2.ds1 dependency > in shlibs. If you have a kernel above 2.4.something, below 2.6, and an > i686, you'll get i686 optimized libraries - er, I don't know if they'll work > on a Via C3, I didn't check :( Probably not. If you have a kernel at least > 2.6.0-test on an i486 or above, you'll get NPTL. [Please CC me, I'm subscribed to debian-devel only] I'm using 2.6.0-test8 (compiled myself, just don't like distro kernels) on a K6-II (i586) and NTPL just doesn't work. After dpkg unpackaged the new libc6, it stopped working. I tried to open aptitude again, and it said "Illegal instruction". I tried to reboot but init failed just like the others -- had to SysRq-S SysRq-U SysRq-B. After the (forced) reboot, init doesn't even print any message. After all these things, I tried my ol' 2.4.22. Yeah, it works! But not optimized (i586 < i686)... So I downgraded libc6* and locales to unstable ones. Any suggestions? Cheers, Felipe Almeida Lessa. pgphasTprhMLg.pgp Description: PGP signature
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 05:02:56PM +0200, Josselin Mouette wrote: > Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > > As some of you may have seen, there's a new version of glibc in unstable. > > It has a couple of nice features - particularly for x86, where both > > i686-optimized libraries and NPTL support are included. There are also > > sparcv9 libraries. And the packaging has been totally redone for a number > > of benefits. > > Do you intend to make these packages support a system-wide locale > setting as explained in bug#214898 ? This is a one-liner change which > would bring huge improvement for e.g. gdm or cups. Or do you think it > should be discussed further, and/or wait for after sarge? These packages are to address a particular problem - updating the version to support NPTL and TLS, without breaking everyone else. So in this context, no. In general I don't handle locale-related bugs so you'll have to get a response to that bug from one of our other glibc maintainers on debian-glibc. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > As some of you may have seen, there's a new version of glibc in unstable. > It has a couple of nice features - particularly for x86, where both > i686-optimized libraries and NPTL support are included. There are also > sparcv9 libraries. And the packaging has been totally redone for a number > of benefits. Do you intend to make these packages support a system-wide locale setting as explained in bug#214898 ? This is a one-liner change which would bring huge improvement for e.g. gdm or cups. Or do you think it should be discussed further, and/or wait for after sarge? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 02:00:50PM -0200, Felipe Almeida Lessa wrote: > Segundo os pergaminhos sagrados, alguém chamado Daniel Jacobowitz <[EMAIL > PROTECTED]> escreveu: > > > Now, we need to find the problems I _don't_ know about. I'd like for those > > who feel comfortable testing a new glibc - usual caveats about the quality > > of experimental software! - to give it a try. Use it, let us know what > > happens. Don't upload Debian packages to the archive built against it, > > obviously - they won't be installable because of the >= 2.3.2.ds1 dependency > > in shlibs. If you have a kernel above 2.4.something, below 2.6, and an > > i686, you'll get i686 optimized libraries - er, I don't know if they'll work > > on a Via C3, I didn't check :( Probably not. If you have a kernel at least > > 2.6.0-test on an i486 or above, you'll get NPTL. > > [Please CC me, I'm subscribed to debian-devel only] > > I'm using 2.6.0-test8 (compiled myself, just don't like distro > kernels) on a K6-II (i586) and NTPL just doesn't work. After dpkg > unpackaged the new libc6, it stopped working. I tried to open > aptitude again, and it said "Illegal instruction". I tried to reboot > but init failed just like the others -- had to SysRq-S SysRq-U > SysRq-B. After the (forced) reboot, init doesn't even print any > message. > > After all these things, I tried my ol' 2.4.22. Yeah, it works! But > not optimized (i586 < i686)... So I downgraded libc6* and locales to > unstable ones. OK, sounds like something's wrong with NPTL on a 586... could you test further? What I'd really like would be a core dump; unless core dumps are disabled (ulimit -c) you ought to have gotten one when aptitude crashed. FYI, with the new libc6 installed and 2.6.0-test8 you should be able to say "LD_ASSUME_KERNEL=2.4.22 aptitude" and that should work (disabling NPTL). So if you can get up a core file, load it up using LD_ASSUME_KERNEL=2.4.22 gdb aptitude core and give us the output of info registers disassemble -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
Segundo os pergaminhos sagrados, alguém chamado Daniel Jacobowitz <[EMAIL PROTECTED]> escreveu: > Now, we need to find the problems I _don't_ know about. I'd like for those > who feel comfortable testing a new glibc - usual caveats about the quality > of experimental software! - to give it a try. Use it, let us know what > happens. Don't upload Debian packages to the archive built against it, > obviously - they won't be installable because of the >= 2.3.2.ds1 dependency > in shlibs. If you have a kernel above 2.4.something, below 2.6, and an > i686, you'll get i686 optimized libraries - er, I don't know if they'll work > on a Via C3, I didn't check :( Probably not. If you have a kernel at least > 2.6.0-test on an i486 or above, you'll get NPTL. [Please CC me, I'm subscribed to debian-devel only] I'm using 2.6.0-test8 (compiled myself, just don't like distro kernels) on a K6-II (i586) and NTPL just doesn't work. After dpkg unpackaged the new libc6, it stopped working. I tried to open aptitude again, and it said "Illegal instruction". I tried to reboot but init failed just like the others -- had to SysRq-S SysRq-U SysRq-B. After the (forced) reboot, init doesn't even print any message. After all these things, I tried my ol' 2.4.22. Yeah, it works! But not optimized (i586 < i686)... So I downgraded libc6* and locales to unstable ones. Any suggestions? Cheers, Felipe Almeida Lessa. pgp0.pgp Description: PGP signature
Re: Testing/help needed - experimental glibc version
On Wed, Oct 22, 2003 at 05:02:56PM +0200, Josselin Mouette wrote: > Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > > As some of you may have seen, there's a new version of glibc in unstable. > > It has a couple of nice features - particularly for x86, where both > > i686-optimized libraries and NPTL support are included. There are also > > sparcv9 libraries. And the packaging has been totally redone for a number > > of benefits. > > Do you intend to make these packages support a system-wide locale > setting as explained in bug#214898 ? This is a one-liner change which > would bring huge improvement for e.g. gdm or cups. Or do you think it > should be discussed further, and/or wait for after sarge? These packages are to address a particular problem - updating the version to support NPTL and TLS, without breaking everyone else. So in this context, no. In general I don't handle locale-related bugs so you'll have to get a response to that bug from one of our other glibc maintainers on debian-glibc. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
Le mar 21/10/2003 à 19:03, Daniel Jacobowitz a écrit : > As some of you may have seen, there's a new version of glibc in unstable. > It has a couple of nice features - particularly for x86, where both > i686-optimized libraries and NPTL support are included. There are also > sparcv9 libraries. And the packaging has been totally redone for a number > of benefits. Do you intend to make these packages support a system-wide locale setting as explained in bug#214898 ? This is a one-liner change which would bring huge improvement for e.g. gdm or cups. Or do you think it should be discussed further, and/or wait for after sarge? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 08:05:42PM -0500, Graham Wilson wrote: > [please CC me as I'm not subscribed.] > > On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > > Also, I'd like for porters to build and test this and send debian-glibc > > whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, > > PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, > > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > > I'm forgetting about are still up in the air. > > I can make a build of it for alpha and upload to unstable if the glibc > team would like. Experimental, but yes - unless Jeff's already started a build? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
[please CC me as I'm not subscribed.] On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > Also, I'd like for porters to build and test this and send debian-glibc > whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, > PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > I'm forgetting about are still up in the air. I can make a build of it for alpha and upload to unstable if the glibc team would like. -- gram signature.asc Description: Digital signature
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 08:05:42PM -0500, Graham Wilson wrote: > [please CC me as I'm not subscribed.] > > On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > > Also, I'd like for porters to build and test this and send debian-glibc > > whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, > > PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, > > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > > I'm forgetting about are still up in the air. > > I can make a build of it for alpha and upload to unstable if the glibc > team would like. Experimental, but yes - unless Jeff's already started a build? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/help needed - experimental glibc version
[please CC me as I'm not subscribed.] On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > Also, I'd like for porters to build and test this and send debian-glibc > whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, > PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > I'm forgetting about are still up in the air. I can make a build of it for alpha and upload to unstable if the glibc team would like. -- gram signature.asc Description: Digital signature
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > As some of you may have seen, there's a new version of glibc in unstable. Joey has kindly pointed out that I'm out of my mind. "There's a new version of glibc in experimental." -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > I'm forgetting about are still up in the air. I built -6 from CVS as of "Wed, 15 Oct 2003 00:09:07 +0100" on mips. All I can say at the moment is that it built cleanly (the machine is still busy rebuilding perl with (now hopefully) fixed msqs). More to come after that is resolved. Cheers, -- Guido signature.asc Description: Digital signature
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > As some of you may have seen, there's a new version of glibc in unstable. Joey has kindly pointed out that I'm out of my mind. "There's a new version of glibc in experimental." -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testing/help needed - experimental glibc version
As some of you may have seen, there's a new version of glibc in unstable. It has a couple of nice features - particularly for x86, where both i686-optimized libraries and NPTL support are included. There are also sparcv9 libraries. And the packaging has been totally redone for a number of benefits. However, the packaging was totally redone. And the glibc version updated from CVS. I and others have been running around fixing problems relative to the version currently in unstable, so most of them have been attended to but some remain. Here's the ones I know about: Documentation missing from various packages pt_chown is missing /usr/lib/debug doesn't have some important symlinks libc6-dev's dependency on libc6 has vanished The locales package has some dependency issues and the SUPPORTED file is missing Also, problems with some non-Debian software have been reported - I believe Citrix on i386 and a JVM on ia64. Now, we need to find the problems I _don't_ know about. I'd like for those who feel comfortable testing a new glibc - usual caveats about the quality of experimental software! - to give it a try. Use it, let us know what happens. Don't upload Debian packages to the archive built against it, obviously - they won't be installable because of the >= 2.3.2.ds1 dependency in shlibs. If you have a kernel above 2.4.something, below 2.6, and an i686, you'll get i686 optimized libraries - er, I don't know if they'll work on a Via C3, I didn't check :( Probably not. If you have a kernel at least 2.6.0-test on an i486 or above, you'll get NPTL. Also, I'd like for porters to build and test this and send debian-glibc whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else I'm forgetting about are still up in the air. Where to get it: Experimental after dinstall today. How to build it: You'll need the linux-kernel-headers package. Get it from http://ftp-master.debian.org/~dan/. Two ways; either create a fresh chroot and install the build dependencies there (which will remove libc6-dev temporarily!) or else install all the build dependencies except linux-kernel-headers, unpack a built linux-kernel-headers .deb, export LINUX_SOURCE pointing at /usr in the unpacked linux-kernel-headers tree, and use dpkg-buildpackage -d to ignore the dependency. We're counting on your help to get this package in shape (hopefully) for sarge! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Testing/help needed - experimental glibc version
On Tue, Oct 21, 2003 at 01:03:02PM -0400, Daniel Jacobowitz wrote: > alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else > I'm forgetting about are still up in the air. I built -6 from CVS as of "Wed, 15 Oct 2003 00:09:07 +0100" on mips. All I can say at the moment is that it built cleanly (the machine is still busy rebuilding perl with (now hopefully) fixed msqs). More to come after that is resolved. Cheers, -- Guido signature.asc Description: Digital signature
Testing/help needed - experimental glibc version
As some of you may have seen, there's a new version of glibc in unstable. It has a couple of nice features - particularly for x86, where both i686-optimized libraries and NPTL support are included. There are also sparcv9 libraries. And the packaging has been totally redone for a number of benefits. However, the packaging was totally redone. And the glibc version updated from CVS. I and others have been running around fixing problems relative to the version currently in unstable, so most of them have been attended to but some remain. Here's the ones I know about: Documentation missing from various packages pt_chown is missing /usr/lib/debug doesn't have some important symlinks libc6-dev's dependency on libc6 has vanished The locales package has some dependency issues and the SUPPORTED file is missing Also, problems with some non-Debian software have been reported - I believe Citrix on i386 and a JVM on ia64. Now, we need to find the problems I _don't_ know about. I'd like for those who feel comfortable testing a new glibc - usual caveats about the quality of experimental software! - to give it a try. Use it, let us know what happens. Don't upload Debian packages to the archive built against it, obviously - they won't be installable because of the >= 2.3.2.ds1 dependency in shlibs. If you have a kernel above 2.4.something, below 2.6, and an i686, you'll get i686 optimized libraries - er, I don't know if they'll work on a Via C3, I didn't check :( Probably not. If you have a kernel at least 2.6.0-test on an i486 or above, you'll get NPTL. Also, I'd like for porters to build and test this and send debian-glibc whatever patches were necessary. HPPA doesn't build yet (hi Carlos); i386, PowerPC, and S/390 will be in the archive this afternoon; sparc, ia64, alpha, and arm should be buildable; mips, mipsel, m68k, and whatever else I'm forgetting about are still up in the air. Where to get it: Experimental after dinstall today. How to build it: You'll need the linux-kernel-headers package. Get it from http://ftp-master.debian.org/~dan/. Two ways; either create a fresh chroot and install the build dependencies there (which will remove libc6-dev temporarily!) or else install all the build dependencies except linux-kernel-headers, unpack a built linux-kernel-headers .deb, export LINUX_SOURCE pointing at /usr in the unpacked linux-kernel-headers tree, and use dpkg-buildpackage -d to ignore the dependency. We're counting on your help to get this package in shape (hopefully) for sarge! -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
