Re: popt-1.13 release

[Takao Fujiwara - Tokyo S/W Center]

I burned DVD, installed Fedora 8 and could reproduced your problem.
Some of applications do not set bind_textdomain_codeset().

I think the attached patch will fix your main problem with removing your change 
of the workaround.

Thanks,
fujiwara

Robert Scheck wrote:

On Mon, 14 Jan 2008, Takao Fujiwara - Tokyo S/W Center wrote:


Robert Scheck wrote:


Fedora 7 has popt delivered with rpm, so it's an old popt version which
never saw your changes. And all popt packages I officially prepared for
Fedora 8 are currently undoing your changes per patch to avoid really any
regression for the Fedora users.


Hmm.., I mean I've already applied the POPT_printf parts with popt sources 
and I cannot reproduce your problem.



Well...rpm, kudzu and most of the rest were static linked to popt in Fedora
7. This changed with Fedora 8 the first time. If you really want to try to
reproduce this, go and rebuild all packages depending on popt first. Or try
Fedora 8 which doesn't link statically to popt any longer for rpm and kudzu
- at least it shouldn't.


Greetings,
  Robert



--- popt/poptint.c.orig 2008-01-16 10:20:39.0 +0900
+++ popt/poptint.c  2008-01-16 10:28:57.0 +0900
@@ -2,6 +2,24 @@
 #include stdarg.h
 #include poptint.h
 
+#if defined(HAVE_DCGETTEXT)  !defined(__LCLINT__)
+char *
+_D_ (const char * dom, const char * str)
+{
+  char * codeset = NULL;
+  char * retval = NULL;
+
+  if (!dom) 
+dom = textdomain (NULL);
+  codeset = bind_textdomain_codeset (dom, NULL);
+  bind_textdomain_codeset (dom, UTF-8);
+  retval = dgettext(dom, str);
+  bind_textdomain_codeset (dom, codeset);
+
+  return retval;
+}
+#endif
+
 #ifdef HAVE_ICONV
 static /[EMAIL PROTECTED]@*/ /[EMAIL PROTECTED]@*/ char *
 strdup_locale_from_utf8 (/[EMAIL PROTECTED]@*/ char *buffer)
--- popt/poptint.h.orig 2008-01-16 02:01:07.0 +0900
+++ popt/poptint.h  2008-01-16 02:34:38.0 +0900
@@ -105,7 +105,7 @@ struct poptContext_s {
 #endif
 
 #if defined(HAVE_DCGETTEXT)  !defined(__LCLINT__)
-#define D_(dom, str) dgettext(dom, str)
+#define D_(dom, str) _D_(dom, str)
 #define POPT_(foo) D_(popt, foo)
 #else
 #define D_(dom, str) str

Re: popt-1.13 release

[Takao Fujiwara - Tokyo S/W Center]

Actually I'm not sure what is your problem.
Which applications do you try?

It seems recently some of modules, GTK, Bonobo and GNOME session, uses goption. 
When the application uses --help options, it includes the output of both 
goption and popt.
goption has the current encoding but popt is UTF-8 then you may encounter the 
problem.
Could you apply POPT_fprintf() for popt options only?

Thanks,
fujiwara

Robert Scheck wrote:

On Mon, 31 Dec 2007, Takao Fujiwara - Tokyo S/W Center wrote:


Is your problem fixed by replacing char++ with POPT_next_char() ?
If it's right, I think POPT_fprintf() does need to be reverted.



I'm a bit clueless regarding the code. It's mostly Jeff's work and I hacked
the rest to get a working popt for Fedora. Replacing POPT_fprintf() by
the previous fprintf() seems to work around the problems, which ends from
my point of view in: POPT_fprintf() has problems with non-ASCII characters
when the locale isn't a UTF8 one.

Do you mean ch++; vs. ch = POPT_next_char(ch)? I can't see any big
difference there, as far as POPT_fprintf() vs. fprintf() brought visible
results to me only.


Greetings,
  Robert




__
POPT Library   http://rpm5.org
Developer Communication List   popt-devel@rpm5.org