Re: Patch from Fedora to return something semi-meaningful on exec alias fail

2014-01-08 Thread Robert Scheck
Hello all,

On Sun, 24 Nov 2013, Robert Scheck wrote:
 attached is a patch by Panu Matilainen who provided a patch to Fedora to
 return something semi-meaningful on exec alias fail. But as I am not a C
 developer, I do not have any clue if this patch is good or bad. However it
 is applied in Fedora already for some time and doesn't seem to cause issues
 there.

I noticed that I never got any feedback regarding this patch. Are there
chances that it might get added? Or are there issues? And if so, which?
http://rpm5.org/community/popt-devel/att-0264/popt-1.16-execfail.patch


Greetings,
  Robert


pgp9PjyHGXvJ7.pgp
Description: PGP signature


Patch suggestion to use $(libdir)/pkgconfig rather $(prefix)/lib/pkgconfig

2013-11-24 Thread Robert Scheck
Hello all,

attached is a tiny patch suggestion to use $(libdir)/pkgconfig rather
$(prefix)/lib/pkgconfig. Background is, that current causes on Fedora
x86_64 /usr/lib/pkgconfig while it should be /usr/lib64/pkgconfig.

Using $(libdir)/pkgconfig rather $(prefix)/lib/pkgconfig seems to be
common when searching on the Internet. However this patch is not really
compliant with Fedora's /%{_lib} vs. %{_libdir} handling before the
UsrMove with Fedora 17 (which can be ignored from my point of view).

Alternatively --with-pkgconfigdir or similar should be implemented, I
would like to discuss this option if this tiny patch is refused after
a review.


Greetings,
  Robert
Patch by Robert Scheck rob...@fedoraproject.org for popt = 1.16 which changes
$(pkgconfigdir) on 64 bit systems from /usr/lib/pkgconfig to 
/usr/lib64/pkgconfig.
Using $(libdir)/pkgconfig rather $(prefix)/lib/pkgconfig seems to be common when
searching on the Internet. This patch however is not really compliant with 
Fedora
/%{_lib} vs. %{_libdir} handling before the UsrMove with Fedora 17. 
Alternatively
--with-pkgconfigdir or similar should be implemented.

--- popt-1.16/Makefile.in   2010-05-04 22:55:59.0 
+0200
+++ popt-1.16/Makefile.in.pkgconfig 2013-11-24 15:06:43.0 
+0100
@@ -370,7 +370,7 @@
 libpopt_la_SOURCES = popt.c poptparse.c poptconfig.c popthelp.c poptint.c
 libpopt_la_LDFLAGS = -no-undefined @LTLIBINTL@ @LTLIBICONV@ \
$(am__append_1)
-pkgconfigdir = $(prefix)/lib/pkgconfig
+pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = popt.pc
 man_MANS = popt.3
 BUILT_SOURCES = popt.pc # popt.lcd
--- popt-1.16/Makefile.am   2010-05-04 22:55:54.0 
+0200
+++ popt-1.16/Makefile.am.pkgconfig 2013-11-24 15:02:21.0 
+0100
@@ -47,7 +47,7 @@
 libpopt_la_SOURCES = popt.c poptparse.c poptconfig.c popthelp.c poptint.c
 libpopt_la_LDFLAGS = -no-undefined @LTLIBINTL@ @LTLIBICONV@
 
-pkgconfigdir = $(prefix)/lib/pkgconfig
+pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = popt.pc
 
 if HAVE_LD_VERSION_SCRIPT


pgpg3lqh55JSM.pgp
Description: PGP signature


popt has problems with unicode characters

2013-11-24 Thread Robert Scheck
Hello all,

I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was
reported at Red Hat Bugzilla. However this does not feel for me like a
downstream thing but more relevant for popt upstream, thus relaying it:

- Forwarded message -
Hi.

Popt has apparently problems with unicode characters.
I tried to include some in the descrip and argDescrip field of the
option table, e.g.
- either directly foo“”bar
- or escaped foo\u201c\u201dbar
and then using the auto help functionallity.

popt reacts quite strangely sometimes it justs works and the characters
are printed correctly, sometimes it however skips the unicode characters
and all between them, but not necessarily for all the unicode characters
used
ie.
\u201cfoo\u201d bar \u201cbaz\u201d
may become
bar “bar”
when printed.


Cheers,
Chris.
- End forwarded message -

Foreign references for this request are:

 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666430
 - https://bugzilla.redhat.com/show_bug.cgi?id=811801


Greetings,
  Robert


pgp6_bEuE9fgr.pgp
Description: PGP signature


POPT_CONTEXT_NO_EXEC and POPT_CONTEXT_POSIXMEHARDER not documented

2013-11-24 Thread Robert Scheck
Hello all,

I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was
reported at Red Hat Bugzilla. However this does not feel for me like a
downstream thing but more relevant for popt upstream, thus relaying it:

- Forwarded message -
Hi.

The popt(3) manpage does basically not document the flags to poptGetContext():
   POPT_CONTEXT_NO_EXEC Ignore exec expansions
   POPT_CONTEXT_POSIXMEHARDER   Options cannot follow arguments

I could not find information on the web what these two _actually_ do.


Cheers,
Chris.
- End forwarded message -

Foreign references for this request are:

 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666431
 - https://bugzilla.redhat.com/show_bug.cgi?id=811805


Greetings,
  Robert


pgpcwLbCLfwDX.pgp
Description: PGP signature


apparently wrong types in the manpage

2013-11-24 Thread Robert Scheck
Hello all,

I am forwarding a message of Christoph Anton Mitterer (Cc'ed) which was
reported at Red Hat Bugzilla. However this does not feel for me like a
downstream thing but more relevant for popt upstream, thus relaying it:

- Forwarded message -
Hi.

The manpage has the following table in the section 1. THE OPTION TABLE:
   Value   Descriptionarg Type
   POPT_ARG_NONE   No argument expected   int
   POPT_ARG_STRING No type checking to be performed   char *
   POPT_ARG_ARGV   No type checking to be performed   char **
   POPT_ARG_SHORT  An short argument is expected  short
   POPT_ARG_INTAn integer argument is expectedint
   POPT_ARG_LONG   A long integer is expected long
   POPT_ARG_LONGLONG   A long long integer is expectedlong long
   POPT_ARG_VALInteger value taken from val   int
   POPT_ARG_FLOAT  An float argument is expected  float
   POPT_ARG_DOUBLE A double argument is expected  double

Apparently all types but char* and char** (i.e. int, short, long,
long long, float and double) need to be pointers to the respective types.


Cheers,
Chris.
- End forwarded message -

Foreign references for this request are:

 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666248
 - https://bugzilla.redhat.com/show_bug.cgi?id=811804


Greetings,
  Robert


pgphWkwycZLBC.pgp
Description: PGP signature


Re: Patch from Fedora containing popt(3) manpage fixes

2013-11-24 Thread Robert Scheck
Hello Jeff,

On Sun, 24 Nov 2013, Jeffrey Johnson wrote:
 My brainfart, sorry. The 1st patch I applied made the changes and I got 
 tricked.
 
 Now checked in.

awesome, thank you!


Greetings,
  Robert


pgpDQ8bcfzb8W.pgp
Description: PGP signature


Re: ARM 64 bit support (aarch64) starting with autoconf 2.69

2013-11-24 Thread Robert Scheck
Hello Jeff,

On Sun, 24 Nov 2013, Jeffrey Johnson wrote:
 There's perhaps portability issues moving to later AutoFu
 (but I use autoconf 2.69 all the time in popt).
 
 Likely the easiest fix is to rerun autogen.sh (or use autoreconf):
 you could just do that on aarch64 as well.
 
 Will that work?

yes, that will work. I just got this report by the aarch64 team - with the
pointer that I ideally should work with upstream to get this upstream done
for the future. It's up to you, I can run autoreconf on downstream as well
if you like that more.


Greetings,
  Robert


pgpEj1USlzPSz.pgp
Description: PGP signature


Re: Preliminary popt-1.14-1 packages

2008-02-19 Thread Robert Scheck
Good evening...

On Sat, 16 Feb 2008, Jeff Johnson wrote:
 All that remains AFAIK is to finish integrating UTF-8 and POPT_fprintf() 
 patches.

 'Twould be nice to find bugs before, not immediately after, release. ;-)

Okay, here we go what looks strange to me with popt 1.14 from your possible
pre-release:

Abfrage-Optionen (mit -q oder --query):
  -c, --configfilesAlle Konfigurationsdateien 
anzeigen
  -d, --docfiles   Alle Dokumentationsdateien 
anzeigen
  --dump   Grundlegende Datei-Informationen 
auflisten
  -l, --list   Alle Dateien im Paket auflisten
  --queryformat=ABFRAGE-FORMAT Folgendes Abfrage-Format benutzen
  -s, --state  Anzeigen der ZustÀnde der 
aufgelisteten Dateien
  -a, --allAbfrage aller Pakete
  -f, --file   Abfragen/ÃŒberprÃŒfen eines 
Pakets, das die Datei besitzt
  -g, --group  Abfragen/ÃŒberprÃŒfen eines 
Pakets einer Gruppe
  -p, --packageAbfragen/ÃŒberprÃŒfen einer 
Paket-Datei
  -W, --ftswalkAbfragen/ÃŒberprÃŒfen von mit 
Durchlaufen des Dateibaumes von OBEN
  --pkgid  Abfragen/ÃŒberprÃŒfen von 
Paketen mit der Paket-Kennung
  --hdrid  Abfragen/ÃŒberprÃŒfen von 
Paketen mit Header-Kennung
  --fileid Abfragen/ÃŒberprÃŒfen von 
Paketen mit Datei-Kennung
  --specfile   Abfragen einer Spec-Datei 
  --triggeredbyAbfragen eines Pakets gesteuert 
vom Paket
  --whatrequires   Abfrage nach Paketen, die eine 
FÀhigkeit benötigen
  --whatprovides   Abfrage nach Paketen, die eine 
FÀhigkeit bereitstellen
  --nomanifest Dateien nicht als Paket-Liste 
verarbeiten

What happend to the umlauts? Hopefully, they're looking same broken to you
as for me. With older popt (e.g. 1.13) it looks like this:

Abfrage-Optionen (mit -q oder --query):
  -c, --configfilesAlle Konfigurationsdateien anzeigen
  -d, --docfiles   Alle Dokumentationsdateien anzeigen
  --dump   Grundlegende Datei-Informationen 
auflisten
  -l, --list   Alle Dateien im Paket auflisten
  --queryformat=ABFRAGE-FORMAT Folgendes Abfrage-Format benutzen
  -s, --state  Anzeigen der Zustände der 
aufgelisteten Dateien
  -a, --allAbfrage aller Pakete
  -f, --file   Abfragen/überprüfen eines Pakets, 
das die Datei besitzt
  -g, --group  Abfragen/überprüfen eines Pakets 
einer Gruppe
  -p, --packageAbfragen/überprüfen einer Paket-Datei
  -W, --ftswalkAbfragen/überprüfen von mit 
Durchlaufen des Dateibaumes von OBEN
  --pkgid  Abfragen/überprüfen von Paketen mit 
der Paket-Kennung
  --hdrid  Abfragen/überprüfen von Paketen mit 
Header-Kennung
  --fileid Abfragen/überprüfen von Paketen mit 
Datei-Kennung
  --specfile   Abfragen einer Spec-Datei
  --triggeredbyAbfragen eines Pakets gesteuert vom 
Paket
  --whatrequires   Abfrage nach Paketen, die eine 
Fähigkeit benötigen
  --whatprovides   Abfrage nach Paketen, die eine 
Fähigkeit bereitstellen
  --nomanifest Dateien nicht als Paket-Liste 
verarbeiten

At kudzu it looks same strange with latest popt:

$ [EMAIL PROTECTED] kudzu --help
kudzu: Symbol `poptHelpOptions' has different size in shared object, consider 
re-linking
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   

Re: popt-1.13 release

2008-01-16 Thread Robert Scheck
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

2008-01-13 Thread Robert Scheck
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

2008-01-13 Thread Robert Scheck
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