Re: Release?
noticed that makefile dependencies are not right after configure, if i run make libpopt.la, i get errors about missing configmake.h so, dependency between libpopt.la and configmake.h is missing. otherwise library builds out fine. On Tue, Aug 26, 2014 at 1:31 PM, Jeffrey Johnson n3...@me.com wrote: On Aug 26, 2014, at 6:28 AM, Jeffrey Johnson n3...@me.com wrote: http://yum.jbj.org/pub/centos6/SRPMS.i386/popt-1.17-1.src.rpm typo (centos-6, not centos6) http://yum.jbj.org/pub/centos-6/SRPMS.i386/popt-1.17-1.src.rpm 73 de Jeff -- glen
Re: Release?
On Tue, 2014-08-26 at 06:28 -0400, Jeffrey Johnson wrote: I’m not sure how a popt release helps downstream distros, the major issue with popt is that nothing ever really changes. snip And there aren’t many exciting features in popt-1.17 either. There are lots of configuration changes for portability, but the underlying popt code hasn’t changed much this century. Mainly these changes, really. We already carry a patch to fix the pkg-config directory, which then needs two others to make the Makefile.am work with recent automake. Now I've run into a test-failure which also seems to be fixed in cvs but needs another 2-3 patches. All of this isn't much work, but it has to be done in lots of places again and again. For example I just took a look at the Fedora popt package[1] and they carry 3 other patches, some of which seem to be fixed upstream as well. And everyone who really needs the portability fixes would probably also be glad not having to deal with cvs or juggle patches. Cheers, Benedikt [1] http://pkgs.fedoraproject.org/cgit/popt.git/tree/ __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: Release?
On Aug 26, 2014, at 6:28 AM, Jeffrey Johnson n3...@me.com wrote: http://yum.jbj.org/pub/centos6/SRPMS.i386/popt-1.17-1.src.rpm http://yum.jbj.org/pub/centos6/SRPMS.i386/popt-1.17-1.src.rpm typo (centos-6, not centos6) http://yum.jbj.org/pub/centos-6/SRPMS.i386/popt-1.17-1.src.rpm http://yum.jbj.org/pub/centos-6/SRPMS.i386/popt-1.17-1.src.rpm 73 de Jeff
Re: Release?
On Aug 25, 2014, at 9:51 PM, Benedikt Morbach benedikt.morb...@googlemail.com wrote: Hello list, would it be possible to cut a new popt release to make life for downstream distributions a little bit easier? Here is popt-1.17 staged for release: http://yum.jbj.org/pub/centos6/SRPMS.i386/popt-1.17-1.src.rpm http://yum.jbj.org/pub/centos6/SRPMS.i386/popt-1.17-1.src.rpm Dunno when the code will be run through a test/release cycle, that’s a fair amount of work. I’m not sure how a popt release helps downstream distros, the major issue with popt is that nothing ever really changes. According to [1] the last release was done more than 4 years ago and there weren't many exciting features added in the meantime (at least as far as I can see) the little fixes do add up, especially the ones to the build-system and tests. And there aren’t many exciting features in popt-1.17 either. There are lots of configuration changes for portability, but the underlying popt code hasn’t changed much this century. There is some experimental support for a Bloom filter data type as well as an RPN calculator, neither of which will find much application use doing CLI option processing. 73 de Jeff
popt-1.14 release
I've built popt-1.14 for release in the next couple of days. The SRPM for popt-1.4 that I will be releasing is at http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.14-1.src.rpm Enjoy! 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
On Wed, 16 Jan 2008, Takao Fujiwara - Tokyo S/W Center wrote: 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. Yes, the patch solves mostly the problem. But there's still one problem with POPT_printf() (?) left, looks like a minor one, nevertheless it is a regression: popt 1.13 with your last patch: [EMAIL PROTECTED] kudzu --help Verwendung: kudzu [OPTION...] -s, --safesicheren Erkennungsmodus verwenden, der Hardware-Funktionen nicht beeinträchtigt -t, --timeout=INTEGER Zeitüberschreitung in Sekunden festlegen -p, --probe nur suchen, Informationen auf der Standardausgabe ausgeben -b, --bus=STRING nur angegebenen 'bus' untersuchen -c, --class=STRINGnur nach der angegebene 'class' suchen -f, --file=Datei für das Einlesen der Hardware-Informationen erkannte Hardware aus Datei lesen -k, --kernel=KernelversionNach Modulen für eine bestimmte Kernelversion suchen -q, --quiet Konfiguration ohne Benutzereingaben durchführen Help options: -?, --helpShow this help message --usage Display brief usage message And this is popt 1.13 with my latest patch: [EMAIL PROTECTED] kudzu --help Verwendung: kudzu [OPTION...] -s, --safe sicheren Erkennungsmodus verwenden, der Hardware-Funktionen nicht beeinträchtigt -t, --timeout=INTEGER Zeitüberschreitung in Sekunden festlegen -p, --probe nur suchen, Informationen auf der Standardausgabe ausgeben -b, --bus=STRING nur angegebenen 'bus' untersuchen -c, --class=STRING nur nach der angegebene 'class' suchen -f, --file=Datei für das Einlesen der Hardware-Informationen erkannte Hardware aus Datei lesen -k, --kernel=Kernelversion Nach Modulen für eine bestimmte Kernelversion suchen -q, --quiet Konfiguration ohne Benutzereingaben durchführen Help options: -?, --help Show this help message --usage Display brief usage message As of my point of view, something regarding POPT_printf() (?) and umlauts at -f, --file=Datei für das Einlesen der Hardware-Informationen seems to be mis-handled. Something is making that string one character smaller as it was and should be. Maybe we're even lacking the use of POPT_printf() some where in the code? Are you able to catch this minor thing also up? Thank you. And of course, thank you very much for your past work and for figuring out the real issue; I'm no C programmer, I'm just able to understand the code at least a bit. Greetings, Robert __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
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
On Sun, 13 Jan 2008, Takao Fujiwara wrote: When I run rpm --help or kudzu --help on [EMAIL PROTECTED] locale in Fedora 7, I don't find any problems. 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. Do you make sure your terminal emulater is launched on [EMAIL PROTECTED] locale instead of UTF-8 locales? My terminal emulator has the correct locales - same when connecting via SSH to that machine e.g. using PuTTY and Windows :) If you want to reproduce that, you could take the srpm popt-1.13-1 package in testing for Fedora 8, rip my patch out, rebuild and install it. Then you should see what I'm seeing. And what I'm seeing is no typical ISO-8859-1(5) vs. UTF-8 problem, I know them already. Greetings, Robert __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
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 Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
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
Re: popt-1.13 release
On Jan 11, 2008, at 2:49 AM, Takao Fujiwara - Tokyo S/W Center wrote: 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? In principle POPT_fprintf could be applied for popt options only. The context of popt options only is extremely difficult to identify however, because popt behvaior is driven by application data. No matter what, I'm not going to be accepting patches for popt such as POPT_fprintf (or the Solaris signed character fix) without explicit regression tests in the future. And I'm likely to revert to Robert Scheck's patch for the next version of popt as that seems to be closest to being explicitly identified as working. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Re: popt-1.13 release
On Dec 19, 2007, at 2:26 AM, Robert Scheck wrote: Moin Jeff, On Wed, 19 Dec 2007, Jeff Johnson wrote: See if the attached patch (the minimum necessary reversion to popt-1.12 afaict) fixes your linux problems. If the patch fixes the linux problems, I'll see if I can rework the Solaris patch to not break linux. Yes, it really fixes my Linux problems: OK, thanks for verify. Would you mind checking the attached patch? It adds POPT_next_char() to undo POPT_prev_char() wide character ptr positioning, and pretty much (if it works for you) points the finger at POPT_fprintf() being broken somehow. Note that POPT_fprintf() is supposed to translate from UTF-8 to whatever locale is desired using iconv(3). GNOME wishes to distribute only UTF-8 locale files, so popt gets to do the final conversion using iconv(3). 73 de Jeff d Description: Binary data
Re: popt-1.13 release
On Dec 15, 2007, at 7:34 PM, Robert Scheck wrote: Yes the colum spacing looks better, but whenever an umlaut (ä, ö, ü, Ä, Ö, Ü, ß) or similar should be displayed, it aborts somehow. Please note, that I can't reproduce when having LANG=C for example. Oh, and it's NOT kudzu having this problem, it's popt - so [EMAIL PROTECTED] rpm --help has just the same problem. See if the attached patch (the minimum necessary reversion to popt-1.12 afaict) fixes your linux problems. If the patch fixes the linux problems, I'll see if I can rework the Solaris patch to not break linux. 73 de Jeff d Description: Binary data
