Re: popt-1.13 release

2007-12-18 Thread Jeff Johnson


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


Re: popt-1.13 release

2007-12-19 Thread Jeff Johnson


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

2008-01-11 Thread Jeff Johnson


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: Allow equal after a short option

2008-03-08 Thread Jeff Johnson


On Mar 8, 2008, at 12:02 PM, Wayne Davison wrote:


I think it would be nice to allow an equal to separate a short option
letter from its abutting argument.  e.g. these commands using the  
test1

executable would all work the same:

 ./test1 -2 foo
 ./test1 -2=foo
 ./test1 -2foo
 ./test1 --arg2 foo
 ./test1 --arg2=foo

Since this has been a syntax error in released versions of popt, this
should not cause a compatibility problem.  This fix requires my prior
patch to make sure that short-option parsing doesn't have longArg set.



I think the patch is a reasonable extension, but there's more to do:

[EMAIL PROTECTED] popt]$ make check
...
make  check-TESTS
make[2]: Entering directory `/X/src/popt'
Running tests in /X/src/popt
Running test test1 - 1.
Running test test1 - 2.
Running test test1 - 3.
Running test test1 - 4.
Running test test1 - 5.
Running test test1 - 6.
Running test test1 - 7.
Running test test1 - 8.
Running test test1 - 9.
Test test1 -2 foo failed with: arg1: 0 arg2:  rest: foo != arg1:  
0 arg2: foo


Would you mind looking at the problem? Thanks ...

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


Re: Any interest in eliminating sprintf(), strcpy(), and strcat()?

2008-03-08 Thread Jeff Johnson


On Mar 8, 2008, at 1:42 PM, Wayne Davison wrote:


In rsync I eliminated all use of sprintf(), strcpy(), and strcat(),
replacing them with snprintf(), strlcpy(), and strlcat().  Would  
you be

interested in such changes if appropriate compatibility functions were
defined?

For instance, I could imagine a configure test to see if snprintf()
returns a -1 on overflow, and a test to see if its limit is off by 1
(some don't count the '\0').  Then, a simple wrapper function would
handle both those conditions in a simple way (i.e. -1 could be mapped
to the limit-value+1 without need to compute the real overflow length
because popt doesn't ever call snprintf() expecting to find out how
much bigger its buffer needs to be -- the limit would just be used to
be extra sure that overflow was impossible.

I have compatibility functions for strlcpy() and strlcat() that I  
could
snag from rsync.  These functions are better than strncpy() and  
strncat()

as their limit value is the size of the buffer (unlike strncat()), and
the destination string will always be '\0'-terminated (unlike  
strncpy()).


I have most of the changes written for an earlier version (rsync  
includes

a version of 1.10.2 at present) that I could adapt for 1.14.



I can take a look, and am not averse to changing, but even snprintf  
has portability

problems wrto popt, and strlfoo is likely even more problematic.

There's *LOTS* of popt use around, so I tend to track with least- 
common-denominator

as much as possible.

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


Re: Allow equal after a short option

2008-03-09 Thread Jeff Johnson


On Mar 9, 2008, at 10:14 AM, Wayne Davison wrote:


On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:

/bin/echo on my system is unmodified from
Fedora 9 coreutils-6.10-4.fc9.i386


Interesting.  So, what do you get with a manual run?

/bin/echo --foo --bar
/bin/echo -- --foo --bar



[EMAIL PROTECTED] popt]$ /bin/echo --foo --bar
--bar
[EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar
--foo --bar

Heh, I believe the answer starts to become clearer:
	The echo(1) from Fedora coreutils-6.10-4.fc9.i386 dares to be  
different.

The root cause is what I needed to understand. Thanks for the patience.


I see all the option information output literally, including the --.
What do you get if you try a make check using that perl -e patch
instead of echo?  Does it still succeed for you?


I added the longArg = NULL, am seeing the same failure on test # 9.


Very weird.  I don't see how my change could affect a short option's
separated arg.  Attached is an even safer version of the change that
ensures that the only time it ever sets longArg to NULL is if the
longArg was set to oe + 1 upon finding an equal sign.

I also tried using valgrind in the test suite:

result=`valgrind $builddir/$prog $*`

and the test-run didn't turn up any errors.



Your
longArg = NULL;
patch seems fine. The issue I'm seeing is here:
...
origOptString++;
if (*origOptString != '\0')
con-os-nextCharArg = origOptString;
#ifdef  NOTYET  /* XXX causes test 9 failure. */
con-os-nextCharArg = origOptString +  
(*origOptString == '=');

#endif
}

if (opt == NULL) return POPT_ERROR_BADOPT;  /* XXX can't  
happen */

...

If I turn that line on, popt make check (and rpm -q) breaks.

There's a class of problems, particularly with recursions like popt,  
that can fool valgrind.


Meanwhile, below is a rewrite of POPT_fprintf, essentially identical  
to the man vsnprintf

example. See what you think ...

(aside) I swear I wrote this code before, likely early June 2007,  
when the need for va_copy
on amd64/ppc was discovered. The issue was discussed at some length  
on [EMAIL PROTECTED]

during the 1st two weeks of June 2007.

int
POPT_fprintf (FILE * stream, const char * format, ...)
{
char * b = NULL, * ob = NULL;
size_t nb = 1;
int rc;
va_list ap;

while ((b = realloc(b, nb)) != NULL) {
va_start(ap, format);
rc = vsnprintf(b, nb, format, ap);
va_end(ap);
if (rc  -1  (size_t)rc  nb)
break;
if (rc  -1)/* glibc 2.1 */
nb = rc + 1;
else/* glibc 2.0 */
nb += (nb = 1 ? 100 : nb);
ob = b;
}

rc = 0;
if (b != NULL) {
#ifdef HAVE_ICONV
ob = strdup_locale_from_utf8(b);
if (ob != NULL) {
rc = fprintf(stream, %s, ob);
free(ob);
} else
#endif
rc = fprintf(stream, %s, b);
free (b);
} else if (ob != NULL)
free(ob);

return rc;
}

73 de Jeff

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


popt-1.14 release

2008-04-02 Thread Jeff Johnson

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


Permit arg units (like 100Kb), add getdate?

2008-05-01 Thread Jeff Johnson

While using popt in another program, I came across 2 usage
cases that might be usefully internalized in popt.

One usage case was an attempt to specify a memory limit as
--memory 16777216
Adding unit scaling, e.g.
--memory 16Mb
--memory 16384Kb
would not be hard to add using something like
POPT_ARG_INT | POPT_ARGFLAG_UNITS
with the usual Kb/Kib Mb/Mib Gb/Gib tokens to prescale.

Another possible popt-1.15 usage case is getdate.y, which is wonderfully
useful for time/date argument input. While it is
rather easy to use getdate.y through a popt callback, perhaps
its time to push getdate.y into libpopt, and add a
POPT_ARG_DATE
distinguished method to make it as easy as possible to use getdate.y.

I'm also seeing a need for a KEY=VALUE comma separated list popt
sub-table option parser (there's a mouthful ;-)

I'm starting to see
--option K1=V1,K2=V2,K3=V3
occurrences more often. I can think of a couple ways to use popt
to recursively parse KEY=VALUE settings, either by keeping track
of a chained popt table that is used iff a specific --option is  
encountered,

or by overloading the pointer field to be used as a option specific
subtable parse.

Opinions?

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


Named bit fields ala ancient BSD %b format

2008-05-01 Thread Jeff Johnson

While I'm thinking about popt features, here is another:

The BSD kernel (iirc) devised a means to map bit files to names
using a %b format.

A string was used to map bit# - name. E.g. here's an example
from some rpmdb code that I use for output purposes

static const char * dbtFlags =
\20\1APPMALLOC\2ISSET\3MALLOC\4PARTIAL\5REALLOC\6USERMEM 
\7DUPOK;


The same technique (of nerdy embedded octal in a string) can be used  
to assign names to bits in a set,

permitting option parsing (using the format string above):

--option PARTIAL,DUPOK

to save the value 0x48 (i.e. (1  3) | (1  6)) into the target  
storage.


OTOH, generating the %b format string can be tedious, and perhaps
a more general table like (this from LZMA):

typedef struct {
const char *name;
uint64_t id;
   } name_id_map;

with name = NULL as table end sentinel should be done.

Opinions?

73 De Jeff

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


Re: Some umlaut issues in popt 1.15 (the old thing again)

2008-05-25 Thread Jeff Johnson


On May 25, 2008, at 9:19 AM, Robert Scheck wrote:


Hello all,

I've claimed that I can see some umlaut issues with popt 1.14 and I  
really
would like to see it solved, now. Reproducer is for me as follows.  
Using
popt-1.13-3 from Fedora 8, 9 or Rawhide, I simply executed the  
following:


$ [EMAIL PROTECTED] rpm --help  rpm-1.13-iso
$ LANG=de_DE.UTF-8 rpm --help  rpm-1.13-utf

Using popt 1.15 from latest CVS checkout, I also did the following:

$ [EMAIL PROTECTED] rpm --help  rpm-1.15-iso
$ LANG=de_DE.UTF-8 rpm --help  rpm-1.15-utf

Results are now as follows using file(1) to compare:

popt-1.13-iso: ISO-8859 text# as expected
popt-1.13-utf: UTF-8 Unicode text   # as expected

popt-1.15-iso: Non-ISO extended-ASCII text  # NOT as expected
popt-1.15-utf: UTF-8 Unicode text   # as expected



Hmmm, file(1) can be tricked and is perhaps unreliable as a test.

I've written this toy reproducer script:

#!/bin/bash

sudo make -C /X/popt/popt-1.13 install  /dev/null  echo ==  
1.13-3.fc9 installed

[EMAIL PROTECTED] rpm --help  /tmp/popt-1.13-iso
LANG=de_DE.UTF-8 rpm --help  /tmp/popt-1.13-utf
diff -u /tmp/popt-1.13-{iso,utf}

sudo make -C /X/src/popt install  /dev/null  echo == 1.15  
installed

[EMAIL PROTECTED] rpm --help  /tmp/popt-1.15-iso
LANG=de_DE.UTF-8 rpm --help  /tmp/popt-1.15-utf
diff -u /tmp/popt-1.15-{iso,utf}

With popt-1.13-3.fc9 installed (with the popt-1.13-popt_fprintf patch  
applied), I see
differences rendering umlaut's between the output from the 2 locales  
for both 1.13 and 1.15.


(aside) the description column _IS_ aligned, which is/was the rather  
feeble reproducer

 for this issue during popt-1.14 release.

And here is what file(1) has to say on the matter:
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.13-iso
/tmp/popt-1.13-iso: ISO-8859 English text
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.15-iso
/tmp/popt-1.15-iso: Non-ISO extended-ASCII English text
reproducing your results here.

I have most certainly removed the encoding conversion in popt-1.14 so  
that the --help
columns are aligned. Which likely explains the file(1) output, iconv  
is _NOT_ being
performed, because doing the iconv conversion visibly destroyed the -- 
help column alignment.


So a little more help please. What problem should I focus on? Having  
only American
English kinda hampers my abilities to fix this issue, I really don't  
know what to expect
with de_DE locale encoded display output (although I'm way more  
familiar with
rpm --help than kudzu or random GNOME --help). I can most easily  
detect column alignment

issues, duh.

And sure I want to fix _ALL_ the popt problems. Just which one first?


Once my LANG is [EMAIL PROTECTED] for popt = 1.14, the ISO-8859 text  
seems not
sane to be written somehow. Please note, that popt 1.13, I was  
using here
is not the vanilla one, the following patch was applied (no matter  
what it

does exactly):

http://cvs.fedora.redhat.com/viewcvs/*checkout*/devel/popt/ 
popt-1.13-popt_fprintf.patch



Greetings,
  Robertpopt-1.13-iso.gzpopt-1.13-utf.gzpopt-1.15- 
iso.gzpopt-1.15-utf.gz


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


Re: Some umlaut issues in popt 1.15 (the old thing again)

2008-05-25 Thread Jeff Johnson
Here's a summary from trying to sort the dueling umlaut encoding -  
--help column alignment

issue which started here:
http://rpm5.org/community/popt-devel/0061.html

jbj_ what I need if you wish me to fix in popt-1.15 is a better  
test. we don't disagree that popt-1.15-iso is broken. we do disagree  
whether popt-1.13-iso works or not. I will sort the file(1)  
difference, but I don't think that test is gonna be strong enough  
(but I will find out tomorrow).
jbj_ i expect columns to stop aligning, the other problem. I can  
work the column alignment rather than the umlauts destruction if you  
prefer. but I have dueling bugs atm.
jbj_ I'll also see about adding a make check reproducer to popt.  
your popt-devel post with rpm --help reproducer is exactly what I  
needed to attempt. thank you.
rsc np. Let's see how testing develops. A replay of one of the  
previous patches is not such hard as I got you - if needed for 1.14+  
or so


On May 25, 2008, at 6:34 PM, Jeff Johnson wrote:



On May 25, 2008, at 9:19 AM, Robert Scheck wrote:


Hello all,

I've claimed that I can see some umlaut issues with popt 1.14 and  
I really
would like to see it solved, now. Reproducer is for me as follows.  
Using
popt-1.13-3 from Fedora 8, 9 or Rawhide, I simply executed the  
following:


$ [EMAIL PROTECTED] rpm --help  rpm-1.13-iso
$ LANG=de_DE.UTF-8 rpm --help  rpm-1.13-utf

Using popt 1.15 from latest CVS checkout, I also did the following:

$ [EMAIL PROTECTED] rpm --help  rpm-1.15-iso
$ LANG=de_DE.UTF-8 rpm --help  rpm-1.15-utf

Results are now as follows using file(1) to compare:

popt-1.13-iso: ISO-8859 text# as expected
popt-1.13-utf: UTF-8 Unicode text   # as expected

popt-1.15-iso: Non-ISO extended-ASCII text  # NOT as expected
popt-1.15-utf: UTF-8 Unicode text   # as expected



Hmmm, file(1) can be tricked and is perhaps unreliable as a test.

I've written this toy reproducer script:

#!/bin/bash

sudo make -C /X/popt/popt-1.13 install  /dev/null  echo  
== 1.13-3.fc9 installed

[EMAIL PROTECTED] rpm --help  /tmp/popt-1.13-iso
LANG=de_DE.UTF-8 rpm --help  /tmp/popt-1.13-utf
diff -u /tmp/popt-1.13-{iso,utf}

sudo make -C /X/src/popt install  /dev/null  echo == 1.15  
installed

[EMAIL PROTECTED] rpm --help  /tmp/popt-1.15-iso
LANG=de_DE.UTF-8 rpm --help  /tmp/popt-1.15-utf
diff -u /tmp/popt-1.15-{iso,utf}



My script here was flawed, ... libdir=/lib ... was also needed for  
make install. Now fixed.


With popt-1.13-3.fc9 installed (with the popt-1.13-popt_fprintf  
patch applied), I see
differences rendering umlaut's between the output from the 2  
locales for both 1.13 and 1.15.


(aside) the description column _IS_ aligned, which is/was the  
rather feeble reproducer

 for this issue during popt-1.14 release.

And here is what file(1) has to say on the matter:
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.13-iso
/tmp/popt-1.13-iso: ISO-8859 English text
[EMAIL PROTECTED] popt]$ file /tmp/popt-1.15-iso
/tmp/popt-1.15-iso: Non-ISO extended-ASCII English text
reproducing your results here.

I have most certainly removed the encoding conversion in popt-1.14  
so that the --help
columns are aligned. Which likely explains the file(1) output,  
iconv is _NOT_ being
performed, because doing the iconv conversion visibly destroyed the  
--help column alignment.


So a little more help please. What problem should I focus on?  
Having only American
English kinda hampers my abilities to fix this issue, I really  
don't know what to expect
with de_DE locale encoded display output (although I'm way more  
familiar with
rpm --help than kudzu or random GNOME --help). I can most easily  
detect column alignment

issues, duh.

And sure I want to fix _ALL_ the popt problems. Just which one first?





hth

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


Re: cross-compilation of popt 1.14 fails

2008-10-09 Thread Jeff Johnson


On Oct 9, 2008, at 2:55 PM, Paul Smith wrote:


Hi all;

If I try to cross-compile popt 1.14, the configure fails (I'm
cross-compiling for powerpc):

checking for string.h... (cached) yes
checking for va_copy() function... configure: error: cannot  
run test program while cross compiling

See config.log' for more details.

I worked around this by pre-setting the variable in the environment  
when

invoking configure:

ac_cv_va_copy=C99 ./configure ...

It would be nice if cross-compiling were supported.



Fixed a couple of days ago.

Here's the dinky patch:

Index: CHANGES
===
RCS file: /v/rpm/cvs/popt/CHANGES,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -b -B -w -p -r1.85 -r1.86
--- CHANGES 18 Sep 2008 18:16:28 -  1.85
+++ CHANGES 4 Oct 2008 19:23:50 -   1.86
@@ -1,4 +1,5 @@
 1.14 - 1.15:
+- jbj: fix: remove AC_CHECK_VA_COPY check, va_copy is no longer  
used.

 - jbj: add eo.po and id.po (Translation Project).
 - jbj: updated da.po (Translation Project).
 - jbj: extend coverage to several additional setup routines.
Index: configure.ac
===
RCS file: /v/rpm/cvs/popt/configure.ac,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -b -B -w -p -r1.43 -r1.44
--- configure.ac18 Sep 2008 18:16:28 -  1.43
+++ configure.ac4 Oct 2008 19:23:50 -   1.44
@@ -43,7 +43,6 @@ AC_SYS_LARGEFILE

 AC_ISC_POSIX
 AM_C_PROTOTYPES
-AC_CHECK_VA_COPY

 AC_CHECK_HEADERS(float.h glob.h langinfo.h libintl.h mcheck.h  
unistd.h)


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


Re: [PATCH] Compile popt under Windows using gnulib

2008-10-25 Thread Jeff Johnson

(let's move this to popt-devel instead of rpm-devel)

On Oct 25, 2008, at 11:42 AM, Richard W.M. Jones wrote:


On Sat, Oct 25, 2008 at 11:31:49AM -0400, Jeff Johnson wrote:

FYI: patches to popt-devel@rpm5.org, please. I'll take
patches however they are sent however. *shrug*

I can't tie builds of popt to gnulib, even for cross-compiles,  
there's

way too many
projects that depend on popt.


Gnulib is a source code library, not a library library, so in normal
usage Gnulib source files are included in the final tarball:

http://www.gnu.org/software/gnulib/manual/gnulib.html#Library-vs-Reusable-Code

So there's no extra dependency.



Yes, I know what gnulib is.

There most certainly is an extra dependency.

If gnulib is internal, there is additional bloat in the tarball, and
maintenenace of the internal copy.

If gnulib is external, it imposes Yet Another prereqisite for building  
popt.



As for whether you store the Gnulib files inside your version control
system, that is a slightly different issue, discussed here:

http://www.gnu.org/software/gnulib/manual/gnulib.html#VCS-Issues


What could be done is disable the usage of glob(3)
if glob is not available through configure tests.


While I agree this is one way to do it, it does mean that Windows
users get one less feature.  AIUI globbing is used to implement the
/etc/popt.d/* directory (?), hard-coded in the source unfortunately.



A new port to cross-compiled MingW will never miss the feature.


There's actually another portability issue which Gnulib can help with
in the future - namely, random/srandom missing.  I hacked around this
in the patch I just sent, but Gnulib will solve it properly (and also
for other platforms, not just Windows, which lack these calls).  I've
got a patch for Gnulib lined up to provide the random family of
functions.



There is nothing in the world (except bero  Ark linux) that
uses or needs the ability to read
/etc/popt.d/*
files.

The /etc/popt.d/* functionality is already conditioned on

#if HAVE_GLOB_H

and should quietly just drop out of -lpopt already.

You already can add the feature by compiling popt with
include (and perhaps library) paths that permit configure
to find glob.h

Meanwhile the other patches to retrofit srand instead of srandom
likely need functionality disabled rather than retrofitted as well,  
because

there is little increase in portability if srand is used instead of
srandom. Yes, gnulib might provide srand but not srandom but
that misses the semantic point below.

Truly, when was the last time you needed a CLI option that
returned a random number in a range for any executable purpose
whatsoever?

I cannot justify adding gnulib everywhere for obscure
and undocumented and perhaps pointless -lpopt functionality.

There are way way too many projects that depend on popt to
justify adding gnulib to popt.

OTOH, that's my POV. You are the first ever to suggest adding
gnulib. Find enough support for adding gnulib to popt and I
will certainly do so. ATM, you, and you alone, are the only person
advocating adding gnulib to popt.

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


Fwd: Adding poptSecuritySaneFile to popt-1.15?

2008-12-19 Thread Jeff Johnson

(resent, dunno where the 1st message went)

I kind of like the idea of using a '@' before
a file path as an attention marker to increase
the file validation checks, and so I'm likely to
refactor the functionality out of rpm and into
popt-1.15 as part of simplifying rpm configuration/initialization.

At the same time, I will probably add a new
poptReadConfigFiles() method whose argument
will be a colon separated list of configuration
file paths to read.

Any other opinions?

73 de Jeff

Begin forwarded message:


From: Jeff Johnson n3...@mac.com
Date: December 18, 2008 3:15:33 PM EST
To: popt-devel@rpm5.org
Subject: Adding poptSecuritySaneFile to popt-1.15?

I'm currently catching up with popt changes, including adding a
--[no]option toggle flag and a precedence group to options, and
perhaps attaching a table to carry named bits in a single option enum.

I see this code in rpm using popt: basically paths can be prefixed  
with

an '@' attention marker, which will do stricter sanity checks
on files as in:

int rpmSecuritySaneFile(const char *filename)
{
   struct stat sb;
   uid_t uid;

   if (stat(filename, sb) == -1)
   return 1;
   uid = getuid();
   if (sb.st_uid != uid)
   return 0;
   if (!S_ISREG(sb.st_mode))
   return 0;
   if (sb.st_mode  (S_IWGRP|S_IWOTH))
   return 0;
   return 1;
}

...

   /* work-off each resulting file from the path element */
   for (i = 0; i  ac; i++) {
   const char *fn = av[i];
#if defined(RPM_VENDOR_OPENPKG) /* security-sanity-check-rpmpopt-and- 
rpmmacros */

   if (fn[0] == '@' /* attention */) {
   fn++;
   if (!rpmSecuritySaneFile(fn)) {
   rpmlog(RPMLOG_WARNING, existing POPT  
configuration file \%s\ considered INSECURE -- not loaded\n, fn);

   continue;
   }
   }
#endif
   (void)poptReadConfigFile(optCon, fn);
   av[i] = _free(av[i]);
   }

Should I drop the '@' prefix on file path attention! convention  
into popt instead?


Its easy enough to do, although perhaps access(2) rather
than stat(2) might be slightly better owner checking.

73 de Jeff




smime.p7s
Description: S/MIME cryptographic signature


Re: Adding poptSecuritySaneFile to popt-1.15?

2008-12-19 Thread Jeff Johnson


On Dec 19, 2008, at 11:04 AM, Ralf S. Engelschall wrote:


On Fri, Dec 19, 2008, Jeff Johnson wrote:


(resent, dunno where the 1st message went)


I don't know, never seen on the list...


I kind of like the idea of using a '@' before a file path as an
attention marker to increase the file validation checks, and so I'm
likely to refactor the functionality out of rpm and into popt-1.15 as
part of simplifying rpm configuration/initialization.

At the same time, I will probably add a new poptReadConfigFiles()
method whose argument will be a colon separated list of configuration
file paths to read.

Any other opinions?


As long as the particular security check (here rpmSecuritySaneFile
for RPM_VENDOR_OPENPKG) embedded into POPT can be optionally still
overridden from within RPM (in case one needs some additional checks  
or

a different error message or whatever) I'm happy. Perhaps an optional
callback does the trick.


I really like the in-band '@' attention grabber. I 'spose I can expose
a global callback vector if you wsh to override poptSecuritySaneFile()
for some purpose down the road ...

Basically I'm just gonna merge the code from rpm - popt, removing
RPM_VENDOR_OOPENPKG, no other change.

The ulterior motive is unrelated to popt, but rather refactoring
RPM's use of popt. I haven't a clue anymore of what gets read from
where in RPM, and so am hoping to bury some of the functionality that
I __DO__ understand while composting the rest of RPM initialization.

I'd really like to not have to engineer Yet Another callback into popt,
what's there is bad enough to maintain. But I can try for a table
driven callback if you prefer to a global vector override, I'm
not particularly fond of globals either.

Thanks for comments.

73 de Jeff

smime.p7s
Description: S/MIME cryptographic signature


Re: Adding poptSecuritySaneFile to popt-1.15?

2008-12-19 Thread Jeff Johnson


On Dec 19, 2008, at 11:11 AM, Ralf S. Engelschall wrote:


On Fri, Dec 19, 2008, Ralf S. Engelschall wrote:


On Fri, Dec 19, 2008, Jeff Johnson wrote:


(resent, dunno where the 1st message went)


I don't know, never seen on the list...


I kind of like the idea of using a '@' before a file path as an
attention marker to increase the file validation checks, and so  
I'm
likely to refactor the functionality out of rpm and into popt-1.15  
as

part of simplifying rpm configuration/initialization.

At the same time, I will probably add a new poptReadConfigFiles()
method whose argument will be a colon separated list of  
configuration

file paths to read.

Any other opinions?


As long as the particular security check (here rpmSecuritySaneFile
for RPM_VENDOR_OPENPKG) embedded into POPT can be optionally still
overridden from within RPM (in case one needs some additional  
checks or

a different error message or whatever) I'm happy. Perhaps an optional
callback does the trick.


BTW, under RPM_VENDOR_OPENPKG the @ attention marker is not just  
used

for POPT files. It is also used for RPM macro files and Lua script
files! So, please be careful that instead of a factoring out not a
partial removal happens to the functionality.



Understood. What I like is the idea of a '@' attention in-band, not  
which particular

config file reading has chosen '@' attention.

I will likely drill similar into lua bootstrapping (if not there  
already).

I like consistency no matter what. But there are other issues to deal
with there permitting external system lua module loading that have
to be addressed. I have no intent of changing anything, but as you know,
the embedded lua is all snarled up throughout rpm misc/rpmio/lib ...


For completeness reasons, here is how OpenPKG 4 configures RPM 5:

| [...]
| #   determine POPT option, RPM macros and Lua script file paths
| RPMPOPT=%{l_prefix}/lib/openpkg/rpmpopt
| RPMPOPT=$RPMPOPT:%{l_prefix}/etc/openpkg/rpmpopt
| RPMPOPT=$RPMPOPT:%{l_prefix}/etc/openpkg/rpmpopt.d/*
| RPMPOPT=$RPMPOPT:~/.openpkg/rpmpopt
| RPMPOPT=$RPMPOPT:@../../.openpkg/rpmpopt
| RPMPOPT=$RPMPOPT:@../.openpkg/rpmpopt
| RPMPOPT=$RPMPOPT:@./.openpkg/rpmpopt
| RPMMACROS=%{l_prefix}/lib/openpkg/rpmmacros
| RPMMACROS=$RPMMACROS:%{l_prefix}/etc/openpkg/rpmmacros
| RPMMACROS=$RPMMACROS:%{l_prefix}/etc/openpkg/rpmmacros.d/*
| RPMMACROS=$RPMMACROS:~/.openpkg/rpmmacros
| RPMMACROS=$RPMMACROS:@../../.openpkg/rpmmacros
| RPMMACROS=$RPMMACROS:@../.openpkg/rpmmacros
| RPMMACROS=$RPMMACROS:@./.openpkg/rpmmacros
| RPMLUA=%{l_prefix}/lib/openpkg/rpmlua
| RPMLUA=$RPMLUA:%{l_prefix}/etc/openpkg/rpmlua
| RPMLUA=$RPMLUA:%{l_prefix}/etc/openpkg/rpmlua.d/*
| RPMLUA=$RPMLUA:~/.openpkg/rpmlua
| RPMLUA=$RPMLUA:@../../.openpkg/rpmlua
| RPMLUA=$RPMLUA:@../.openpkg/rpmlua
| RPMLUA=$RPMLUA:@./.openpkg/rpmlua
|
| #   configure program
| ./configure \
| --cache-file=./config.cache \
| --prefix=%{l_prefix} \
| --mandir=%{l_prefix}/man \
| --includedir=%{l_prefix}/include/openpkg \
| --with-name=OpenPKG RPM \
| --with-path-cfg=%{l_prefix}/etc/openpkg \
| --with-path-rpmpopt=$RPMPOPT \
| --with-path-macros=$RPMMACROS \
| --with-path-rpmlua=$RPMLUA \
| [...]

As you can see, the attention markers are especially used on all paths
relative to the current working directory. This allows OpenPKG to  
use a
very flexible file-system layout with RPM (based on some additional  
RPM

macro hacking) while at the same time not open a security hole.



Thanks for the clear and explcit example, that will help me find what  
I'm

not supposed to break ;-)

73 de Jeff

smime.p7s
Description: S/MIME cryptographic signature


Re: [PATCH] added pkgconfig support for popt

2009-07-24 Thread Jeff Johnson


On Jul 24, 2009, at 11:03 AM, Ralf S. Engelschall wrote:



Only true if you install POPT into standard system locations. But if I
install POPT with --includedir=/usr/include/popt --libdir=/usr/lib/ 
popt

the pkg-config file still allows me to build and link against POPT
without having to know its particular install locations (assuming that
at least the popt.pc is in a standard location or at least in the
PKG_CONFIG_PATH -- or whatever the name of this variable is). So, yes
and no, it can be considered a little bit overkill for POPT, but in
general it is already useful just because it encapsulates/remembers  
the

install locations.



Point taken. Good, there's a usage case at least. There's so
much fussing with popt for little known purpose.

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


Re: [CVS] RPM: popt/ popt.pc.in

2009-08-12 Thread Jeff Johnson


On Aug 12, 2009, at 10:47 AM, devzero2000 wrote:


Sorry if i disgress, but i want take advantage of your attention. It  
might be useful to migrate the autofu popt to version 2 of  
autoconf / automake? It is something I can certainly do, if you  
agree. I prefer to ask first.




Feel free to do whatever. All I expect is that this sequence
of operations continues to work:
./autogen.sh# -- this already adds config.rpath multiple 
times,
# and introduces a dependency on perl 
for no important reason
make clean
make check

Note that my definition of work is rather *ahem* loose. But
yes popt needs to build flawlessly everywhere.

My guess is that upgrading to Newer! Better! Bestest! AutoFu
in popt is going to run afoul of someone's build system choices
with Older! Reliable! Unchanging! AutoFu down the road.

73 de Jeff


Breakage with --help

2009-09-02 Thread Jeff Johnson

I just noticed this flaw while teaching FreeBSD cp(1) to use popt:

 LANG=C ./cp --help
Usage: lt-cp [OPTION...]
  -H  -L  - 
P  -R  -a, --archive
-f, --force -i, --interactive   -l, -- 
link  -n, --noclobber -p, --preserve  - 
r  -v, --verbose

Help options:
  -?, --helpShow this help message
  --usage   Display brief usage message

Usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpv] source_file  
target_file
   cp [-R [-H | -L | -P]] [-f | -i | -n] [-alpv] source_file ...  
target_directory



The popt table looks like this (i.e.  for description):

...
  { NULL,'H', POPT_ARG_NONE,NULL, (int)'H',
N_(), NULL },
...

Somebody make sure I fix this flaw please.

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


Re: test1-55 failes on Solaris

2009-09-25 Thread Jeff Johnson


On Sep 25, 2009, at 3:34 AM, Dagobert Michelsen wrote:


Hi,

I am currently trying to build libpopt 1.15 on Solaris 8 with
Sun Studio 11. After successfull compilation I have a failing
test:



I doubt that --help formatting is a serious issue in popt.

Its likely a cosmetic issue. Comparing large multiline strings in shell
with escaped characters is annoying. It looks like
the test is failing because test1 != lt-test1 in argv[0].
argv[0] is/was changed by libtool.

73 de Jeff


Running test test1 - 55.
Test test1 --usage failed with: Usage: test1 [-I?] [-c|-- 
cb2=STRING] [--arg1] [-2|--arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG] != Usage: lt-test1 [-I?] [-c|--cb2=STRING] [--arg1]  
[-2|--arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG]

FAIL: testit.sh


Further inspection shows

+ run test1 test1 - 55 Usage: lt-test1 [-I?] [-c|--cb2=STRING] [-- 
arg1] [-2|--arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG] --usage

prog=test1
+ shift
name=test1 - 55
+ shift
answer=Usage: lt-test1 [-I?] [-c|--cb2=STRING] [--arg1] [-2|-- 
arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG]

+ shift
+ echo Running test test1 - 55.
Running test test1 - 55.
+ /home/dam/mgar/pkg/libpopt/trunk/work/build-isa-sparcv8/popt-1.15/ 
test1 --usage
HOME=/home/dam/mgar/pkg/libpopt/trunk/work/build-isa-sparcv8/ 
popt-1.15

result=Usage: test1 [-I?] [-c|--cb2=STRING] [--arg1] [-2|--arg2=ARG]
   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG]

+ [ Usage: lt-test1 [-I?] [-c|--cb2=STRING] [--arg1] [-2|--arg2=ARG]
   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG] != Usage: test1 [-I?] [-c|--cb2=STRING] [--arg1] [-2|-- 
arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG] ]
+ echo Test test1 --usage failed with: Usage: test1 [-I?] [-c|-- 
cb2=STRING] [--arg1] [-2|--arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   [-f|--float=FLOAT] [-d|--double=DOUBLE] [--randint=INT]
   [--randlong=LONG] [--randlonglong=LONGLONG] [--argv] [-- 
bitset]
   [--bitclr] [--bitxor] [--nstr=STRING] [--lstr=STRING] [-I|-- 
inc]
   [-c|--cb=STRING] [--longopt] [-?|--help] [--usage] [-- 
simple=ARG] != Usage: lt-test1 [-I?] [-c|--cb2=STRING] [--arg1]  
[-2|--arg2=ARG]

   [-3|--arg3=ANARG] [-onedash] [--optional=STRING] [--val]
   [-i|--int=INT] [-l|--long=LONG] [-L|--longlong=LONGLONG]
   

Re: Test failure for popt 1.16

2010-05-11 Thread Jeff Johnson

On May 10, 2010, at 7:57 PM, Pieter Bowman wrote:

 I did builds of popt 1.16 on a number of our systems here.  Test 59
 failed on a number of the systems with the following output:
 

The fix for the failure in popt-1.16 make check is likely (I have
easy no easy means of testing across all the platforms that you have)
as simple as the atached patch.

If you can confirm that the patch works, I'll re-roll the popt-1.16
tarballs, and re-release (it hasn't been announced anywhere)
the popt-1.16 tarball.

hth

73 de Jeff
==
Index: test1.c
===
RCS file: /v/rpm/cvs/popt/test1.c,v
retrieving revision 1.44
diff -p -u -w -r1.44 test1.c
--- test1.c 26 Jul 2009 16:38:25 -  1.44
+++ test1.c 11 May 2010 18:50:39 -
@@ -252,7 +252,7 @@ int main(int argc, const char ** argv)
 resetVars();
 /*...@=modobserver@*/
 /*...@-temptrans@*/
-optCon = poptGetContext(test1, argc, argv, options, 0);
+optCon = poptGetContext(test1, argc, argv, options, 
POPT_CONTEXT_KEEP_FIRST);
 /*...@=temptrans@*/
 (void) poptReadConfigFile(optCon, ./test-poptrc);
 (void) poptReadDefaultConfig(optCon, 1);


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


Re: popt-1.16: patch for building on NetBSD-current

2010-06-05 Thread Jeff Johnson

On Jun 5, 2010, at 9:29 AM, Thomas Klausner wrote:

 Hi!
 
 Since NetBSD-5.99.11, glob_pattern_p is included in libc.
 
 The attached patch fixes the resulting compilation problem. Please
 include it in the next release.
 

I'd rather see a HAVE_GLOB_PATTERN_P test in AutoFu, with
all the bleary platform tests isolated in system.h, than
having a Sysiphean litter of
+#if defined(__NetBSD__)
+#include sys/param.h
+#endif 
platform tests everywhere in the code.

No worries, I'll adjust your patch to my fetishism ...

Thanks for the report. Holler at me if the issue slips, I won't
be working on POPT 2.0 quite yet, a few more weeks to clear some space.

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


Re: Disallowing args

2010-06-05 Thread Jeff Johnson

On Jun 5, 2010, at 12:48 PM, Wayne Davison wrote:

 On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson n3...@mac.com wrote:
 but
--foo bar
 returns bar in the argument list?
 
 Yes.  The user may well have wanted it to be in the arg list.  There's no way 
 for the program to know that the user didn't just toss some options in the 
 middle of some args (which I do all the time these days, like starting my 
 rsync source/dest args, and then tossing in a --remove-source-files, 
 --backup, or what-not at wherever I am in the list), so I wouldn't want to 
 see an error for something like this:
 
 rsync -aiv --del file --remove-source-args some/dir host:/dest/dir
 
 ... just because --del doesn't take an arg.
 
 The other way to fix the error is to morph --foo=bar behavior to be 
 identical to --foo bar, i.e. an extra argument failure.
 
 I don't see how that would work for something like rsync that takes any 
 number of command-line args outside the options.
 

Well determistic behavior works, just not very useful ;-) I'm not
arguing, just there's issues like POSIX_ME_HARDER that get factored
into --foo=bar error handling, all mind numbingly tedious.

Your patch is likely what I will add, I'm a very lazy schmuck.

 Anything you want to see in POPT 2.0? I'm collecting features ...
 
 A couple ideas off the top of my head:
 An incrementing option -- repeated use adds 1 to the variable instead of 
 setting it to the same value.

How about a full blown RPN calculator to handle not just increment/decrement,
but all arithmetic operations, on option values. infix - postfix just isn't 
that hard, and the whole
mess is just a teensy stack and a switch.

I've got several RPN calculators floating around in RPM code these days that 
could
be dropped into POPT without any effort whatsoever. Nor is a RPM calculator very
hard to implement.
 Multiple long names separated by | in the long-name string (though that 
 could really just be defined as an alias, it might be nice to auto-gen the 
 alias).

There's already Bloom filters fin POPT 1.16 for opaquely handling multiple 
option value strings
(the bar in --foo bar). That partly addresses the need for fewer popt table 
entries/aliases/execs.
(aside)
The usage case is for RPM which has 100 hash algorithm names buried into popt 
tables,
and I need to collapse down to a single popt table entry for my own maintenance 
sanity.

Full pattern matching, either *RE or fnmatch(3), would not be hard. The pdksh 
extensions
to fnmatch globs would handle your specific alternation request.

And POPT is already linking fnmatch(3).

If you have any other RFE's just drop a note here ... and blame Rusty Russell 
for encouraging POPT 2.0 ;-)

73 de Jeff


Re: Disallowing args

2010-06-05 Thread Jeff Johnson

On Jun 5, 2010, at 12:42 PM, Danny Sung wrote:

 On 06/05/2010 8:56 AM, Jeff Johnson wrote:
 
 (aside)
 Anything you want to see in POPT 2.0? I'm collecting features ...
 
 
 Since you're collecting features... =)
 
 One thing I'd like is to extend the help/usage capability just a little.
 

Well reworking --help is one of the primary motivations for POPT 2.0.

Hysterically, encoding was rammed into POPT by GNOME way back when.
While the scheme is workable, the original change _HAD_ to be done
as an addition to preserve ABI, and so all of the i18n for --help
is rather awkwardly done.

To make matters worse, another patch from GNOME wanted POPT to undertake
localization transforms from UTF8 to whatever was in LC_ALL etc.

While iconv(3) makes the character encoding transform as trivial as deciding
the to - from locales, its hardly trivial to make that decision reliably
based solely on a desired LC_ALL environment variable (the from locale cannot
be determined reliably, and hackery like trying various from locales like
glib does is hardly sound engineering).

The killer is that the data needed to find --help alignment reproducers is 
application resident,
and application chosen, and the GNOME developers who forced the iconv(3) into
POPT just aren't helping with reproducers. I have no interest in supporting
POPT functionality that noone is willing to help maintain any more.

So the short answer is:
All of the --help handling needs to be scrapped and reworked in POPT 
2.0.

For starters, 30-40% of the code is --help related, and _ALL_ of the bug reports
I've heard for years are
But --help columns don't align!

Enough already ... bring on the --help bulldozers!

 So I'd like to be able to have more descriptive usage parameters (eg. to 
 cover left-over arguments).  I addition it'd be nice to have a little 
 description/summary of what the program to do.  I realize you can do this 
 with a custom help function.  But it'd be nice if these were standard 
 elements.
 
 Other niceties might be:
 - a way to indicate parameters enabled by default (eg. having a '*' next to 
 them in the help)

There is already
#define POPT_ARGFLAG_SHOW_DEFAULT 0x0080U /*! show default value 
in --help */
as well as
#define POPT_ARGFLAG_OPTIONAL   0x1000U  /*! arg may be missing */
wired into --help output.

 
 - An additional structure that could provide detailed help on argDescription 
 elements.  For example, rpm has an option:
  --queryformat=QUERYFORMATuse the following query format
   It'd be nice if there were a section of help that could describe what 
 QUERYFORMAT could be.  So obviously it's not going to be a full man page, but 
 perhaps it could just show supported % format options or something like that.

This is a different issue. There is already the 6th/7th fields in POPT tables,
the problem is really information overload from --help. At some point man(1)
or info(1) is a better approach than --help, particularly for RPM which has
an entire eco-system of option processing and far too many options
to be reasonably displayed with --help (because the info is not very helpful).

(aside)
Note that RPM is _ROUTINELY adding
#define POPT_ARGFLAG_DOC_HIDDEN 0x4000U /*! don't show in 
help/usage */ 
there's zillions of options in RPM that noone knows about. My guess is that 
there's
more hidden than displayed options these days, usually disablers that noone 
ever
really needs to use.

   I use something like this in my code, but I have specific keys like 
 [replaceme] that I convert.  And I put just the acceptable keys in the help 
 cause I just need a quick reminder of what they are.  But it clutters the 
 option help a little.  I'd be fine with specifying FORMATSTRING in the 
 option help.  Then have perhaps an arg help down below that shows what values 
 FORMATSTRING understands.
 
 
 I'm not sure exactly how you could support these without breaking 
 compatability with existing apps.  Perhaps a new datatype something like:
 

FYI: POPT 2.0 is all about breaking compatibility. There's only so much
that can be done with obscure overloadings of the existing 7-tuple in
popt table entries.

 enum poptOptionType {
   POPT_OPTION,
   POPT_ARG,
   POPT_USAGE,
 };
 
 union poptDetailedOption {
   poptOptionType optType;
   struct poptShortOption;
   struct poptArgHelp;
   struct poptUsageHelp;
 }
 
 struct poptShortOption {  /* same as poptOption but with a type field */
poptOptionType optType;
const char * longName;
char shortName;
int argInfo;
void * arg;
int val;
const char * descrip;
const char * argDescrip;
 };
 
 
 I'm not sure this would give the desired effect.. but the thought would be 
 that it'd turn your options table to something like this:
 
 poptDetailedOption optionsTable[] = {
{ POPT_OPTION, bps, 'b', POPT_ARG_INT, speed, 0,
signaling rate in bits-per-second, BPS },
{ POPT_ARG, FORMATSTRING, Possible

Re: POPT's API has designed in memory leaks. What to do?

2010-06-07 Thread Jeff Johnson

On Jun 7, 2010, at 10:37 AM, Mark Hatle wrote:

 The way I've usually addressed this is to either add an option to the library 
 that changes the default behavior from strdup to passing the address with the 
 expectation of const.
 

I'd rather _NOT_ go the Have it your own way! route in
a API/ABI becuase it adds yet another datum that needs to
be extracted from lusers doing POPT support.

 Either by adding const style prototypes/functions, or by using some mechanism 
 to change the behavior of all of the functions.
 

(aside)
Well I've gone multiple ways with the C borkage of const char **
vs char *const * in POPT and RPM. These days there's so much spewage
from GCC that I don't believe that compilers or language hints solve
any real world issue. But I can/will go to PROT_READ mandatory hardware
enforcement using mmap(2) if that is what is desired. Its easier
to implement the code than it is to discuss the various religion's
coding fetishism's Yet Agin. But I digress ...

Note that it _WAS_ GCC's writable strings that forced the malloc
into POPT in the first place, where POPT sometimes returned
strings from RO memory, and sometimes from argv, and the morons were confused.
Adding the strdup() to POPT was 1 less issue to worry about. Another digression 
...

 My biggest concern is the potential retrofit of existing apps that expect the 
 current behavior.. but I agree with many of the submitters.. popt really 
 should be sending const points and then the app needs to strdup.
 

And so legacy compatibility again again again. POPT 2.0 is a major change
with no compatibility implied or intended. Meanwhile I will strive to
make the change as painless as possible. But there are issues (aka deep hacks)
that have been in POPT for a decade that aren't the right thing to do. And even
though I've overloaded just about everything possible in the 7-tuple of a
POPT table item, there are these issues:

0) overloading with bit masks and long - void * punning is quite 
mysterious to most.

1) bits in certain fields are _ALREADY_ ambiguous for certain values, 
with
subtle conventional contextual tests of other entries needed while 
using POPT.

2) there's a need for Yet Another Pointer for callbacks with context 
(changing item #5
from int to long would suffice but is instantly incompatible so 
I'd rather do something
less mysterious).

Thanks for comments however. And ignore my scarcasm if it offends.

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


Re: Disallowing args

2010-06-17 Thread Jeff Johnson

On Jun 5, 2010, at 11:39 AM, Wayne Davison wrote:

 Here's something that was recently fixed for the popt that is included
 with rsync: rejecting an arg to an option that doesn't take an arg.
 
 Attached is a patch.  A new error code, POPT_ERROR_UNWANTEDARG, was
 created to make the error message nice.  This handles both -l=value
 and --long-arg=value where neither one is supposed to take a value.
 
 ..wayne..
 arg-error.patch


Hmmm, I'll get this fix worked in down the road. Certainly a bug.

(aside)
All this code is actively being simplified for POPT 2.0 so
that I can more easily follow the logic path.

Meanwhile in the future, if you could send a patch against some
POPT release that I can find (I tried all the way back to
the popt-1_11-release tag, patch doesn't apply), or at least provide some hint
about what code repository the patch applies to (the patch itself seems
to have been edited), that would certainly help.

Please also note that I won't accept any patch that doesn't
pass make check regression tests. If you _REALLY_ want
to make sure that odd POPT corner cases like args given to
an option return an error, adding a reproducer to the
test cases too.

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


POPT 2.0: another malloc issue

2010-06-17 Thread Jeff Johnson
This is another ancient (circa 1997) in POPT.

The argv returned through certain interfaces ('d have
to check, but the issue bites me every couple months)
has everything allocated in one contiguous blob so
that an experienced/lazy programmer just has to do

const char * s = bing bang boom;
int ac = 0;
const char ** av = NULL;
int rc = poptParseArgvString(s, ac, av_;



if (av)
free(av);

i.e. no loop over that strings in the array is needed.

The issue is that there are corner cases that do
not conform to general expectations, where a string
can be reallocated, or otherwise manipulated freely
without considering whether the memory is part of
an argv array returned from POPT.

(As an experienced/lazy programmer I use this POPT (and RPM)
functionality a fair amount).

The problem is that in order to attempt tuples by parsing
a CSV attached to a single option like
--option bing,bang,boom
uniformly with POPT_ARG_ARGV (and I can think of several other
usage cases for tuples), how the memory was allocated
affects how tuple merges are implemented.

I'm likely to change the behavior in POPT 2.0 to allocate
all the strings independently to simplify tuple merging.

Which means that applications will have to explicitly write the
loop (and its trivial to add a helper function in POPT) to do
for (i = 0; i  ac; i++)
if (av[i]) free(av[i])
free(av);

But I can be convinced otherwise, and perhaps *shudder* arrange
for a Have it your own way! selector logic if I absolutely MUST
do that.

Personally I'd rather see KISS even if incompatible. It just
ain't that big a deal to write a loop where needed.

But -- as always -- this means I'm forced to debug everyone's
widdle valgrind exercises if/when POPT is abused and used incorrectly.

73 de Jeff


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


POPT 2.0: renaming to popt2 vs. loader maps and ELF versioned symbols

2010-06-17 Thread Jeff Johnson
There's a thread on gcrypt-devel that is directly
relevant to POPT library compatibility and symbol handling:

http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

(You will get a 403 Forbidden for the gcrypt-devel archives, go find a mirror)

And for reference, there's Drepper's deep dark chocolate DSO guidance here:

http://people.redhat.com/drepper/dsohowto.pdf


(aside)
And gcrypt-devel is unrelated to generating 64bit RSA keypairs using
a RPN calculator in POPT. ;-)

There are (at least) two approaches to adding symbol versioning
and visibility to a DSO library.

1) use a loader map
already implemented in POPT, just opt-in and so
never used.

2) use GCC __attribute__((visibility)) voo-doo
Using __attribute__ can be used to do opt-out symbol hiding
without the modest overhead of loader maps.

The other (and different) issue is symbol versioning. The connection
to visibility is largely because a loader map can also be used
to add symbol versions quite easily.

(aside)
There's also the distantly related/coupled issue (if I choose to
add ELF symbols to the RPN calculator) of using
dlsym() # in POSIX and should be portable
versus
dlvsym()# GNU extensions necessary with versioned symbol lookup

I can/will chase down a straw-man implementation using loader maps
and versioned symbols for compatibility over the next month
because I _REALLY_ think renaming to popt2 is just wussiness.

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


Re: POPT 2.0: version stamping in includes

2010-06-18 Thread Jeff Johnson

On Jun 18, 2010, at 9:03 PM, Michael Jennings wrote:
 
 Ah, okay.  I guess I was envisioning for runtime checks:
 
  void *f = dlopen(NULL, RTLD_LAZY);
  if (dlsym(f, popt_something)) {
...
  }
 

Any idea how portably POSIX dlsym() is in 2010?

There's the GNUish dlvsym() that needs figgering if I attempt
compatibility with symbol versioning too.

73 de Jeff

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


A better example usage case for POPT_ARG_BITSET

2010-06-21 Thread Jeff Johnson
One of the more subtle additions in popt-1.16 is
 POPT_ARG_BITSET

This a Bloom filter data type that parses option
arguments as a CSV and adds to the bit set.

What is difficult to describe is why/how Bloom filters
work (wikipedia does an excellent job) and particularly
how to describe
Why would I _EVER_ need Bloom filters doing CLI option parsing?

So here's a perfectly sane usage case that I'll be implementing in RPM
shortly.

One of the mysteries in RPM is %config handling. In short, a file path
marked with %config is handled with a state machine that tries to
avoid accidentally discarding local customizations during upgrade.

However, what is often needed is a means (through POPT options) to
disable some functionality, or also to negate the behavior (like grep -v)

Since there are like 300K possible file paths on existing systems, this is a 
rather
complex task if arrays/lists are used to attach a per-file disabler using POPT.

One can certainly fiddle up the application code to process POPT
options in any number of ways.

Or (as I'm gonna do) one can let POPT_ARG_BITSET do most of the heavy lifting 
for you
handling a large estimated universe (in this case potentially 300K file paths)
with almost no additional application code needed. This POPT helper
int poptBitsChk(poptBits bits, const char * s);
will return TRUE/FALSE depending on whether a string was mentioned (or not).

There's already a a test case (popt/tdict.c) based on /usr/share/dict/words
in popt code.

Fiddle around with tdict.c if you wish to attempt using POPT_ARG_BITSET
in some application.

Wayne: RSYNC+POPT likely has zillions of usage cases for POPT_ARG_BITSET
with large unknown(a priori) populations of file paths (and enablers/disablers
attached to a specific path). Note that the default expected population size
in POPT is way too small for 300K+ file paths (from popt/popt.h):

#define _POPT_BITS_N1024U/* estimated population */
#define _POPT_BITS_M((3U * _POPT_BITS_N) / 2U)
#define _POPT_BITS_K16U  /* no. of linear hash combinations */

but can be overridden by assigning values to

/*...@unchecked@*/
extern unsigned int _poptBitsN;
/*...@unchecked@*/
extern  unsigned int _poptBitsM;
/*...@unchecked@*/
extern  unsigned int _poptBitsK;

There's also the attached bit of deep dark chocolate from RPM code (where
the POPT_ARG_BITSET Bloom filter implementation in POPT was swiped from)
if interested in an optimal set of parameters with a false positive
failure rate less than specified for a given estimated population size.

See the appended routine.

(aside)
I left rpmbfParams() (the mnemonic is RPMBF == RPM Bloom Filter, duh) routine
out of POPT largely because of the math complexity and no clearly established
usage case for POPT_ARG_BITSET so far. I also hadn't implemented rpmbfParams()
yet at the time I did the port to POPT ;-).

I almost certainly will include some variant of the attached routine
to estimate optimal bitset parameters in POPT 2.0 before I'm done.

hth

73 de Jeff
===
void rpmbfParams(size_t n, double e, size_t * mp, size_t * kp)
{
static size_t _nmin = 10;
static size_t _n = 1;
static size_t _nmax = 1 * 1000 * 1000 * 1000;
static double _emin = 1.0e-10;
static double _e = 1.0e-4;
static double _emax = 1.0e-2;
size_t m;
size_t k;

/* XXX sanity checks on (n,e) args. */
if (!(n = _nmin  _n = _nmax))
n = _n;
if (!(e = _emin  _e = _emax))
e = _e;

m = (size_t)((n * log(e)) / (log(1.0 / pow(2.0, log(2.0 + 0.5);
k = (size_t) ((m * log(2.0)) / n);
if (mp) *mp = m;
if (kp) *kp = k;
}






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


Re: popt with msvc?

2010-10-27 Thread Jeff Johnson

On Oct 27, 2010, at 12:25 AM, Matt Arsenault wrote:

 
 On Oct 26, 2010, at 11:27 PM, Jeff Johnson wrote:
 What test are failing? Like long long and double, the tests are quite 
 complete
 over data types and It Really Doesn't Matter: hardly ant program needs/uses
 long long and double CLI options.
 
 test1 - 19, 20, 21, 22, 23, 60, 61

19-23 are testing alias/exec functionality from test-poptrc.
If you can live without alias/exec (and you likely can,
only rpm makes heavy/serious use of popt alias/exec afaik).

60-61 are just cosmetic --help comparisons. If popt alias/exec
isn't functional, then the --help display will fail too.

 test3 - 51, 52, 53
 
 I just sort of haphazardly threw things together until it built, so I may 
 have broken something. I quickly added cmake to try building it since I have 
 no idea how to get autotools to work with VS. 

Yes the AutoFu chains are getting rather daunting. The basic trick
with autotools, is use configure, and avoid using the autotools, on
tricky platforms.

I haven't a clue how to get AutoFu to work with VS either.

You might try older POPT tarballs. The basic functionality of POPT hasn't 
changed since
forever, nor has the API, nor are there significant bugs. Older tarballs might
have less AutoFu.

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


Re: popt with msvc?

2010-10-28 Thread Jeff Johnson

On Oct 28, 2010, at 12:50 AM, Matt Arsenault wrote:

 
 Other than those failed tests, I do now have it working without the need to 
 revert to an older version.
 

If you send alon a patch for VS, I'll try to carry that in popt (I don't do VS 
or Windoze but ..)
There's a patch for Xcode in popt already ... popt changes little enough that 
VS might be
maintainable in spite of bit rot.

The gnulib approach used by Mingw is way way overkill for a teensy library like 
POPT imho.

73 de Jeff


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


Re: AW: INFO: Popt 1.14 license evaluation - response appreciated

2011-03-14 Thread Jeff Johnson

On Mar 14, 2011, at 7:41 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote:

 Hello,
  
 I was wondering if you could respond to my question ? Are ou going to get the 
 issues sorted out regarding the license texts ?
  

I thought this reply (Mark Hatle is part of the the @rpm5.org project that 
maintains POPT)
was sufficient:

http://rpm5.org/community/popt-devel/0245.html

If Mark's answer is not sufficient to get the issues sorted out, you will 
have to
be more specific about what the issue(s) are than mailing a highlighted
web form from an automated scanner in order for me to tell what issues
remain.

What I see is that your automated scanner is confused about generated
files from GNU tools using in POPT.

73 de Jeff

 Best regards,
 Gerlinde Hulin
  
  
 _
 Von: Hulin, Gerlinde (E D EA SOL D TC1) 
 Gesendet:   Thursday, March 03, 2011 10:15 AM
 An: 'popt-devel@rpm5.org'
 Cc: Hufnagel, Michael (E D EA SOL EN)
 Betreff:INFO: Popt 1.14 license evaluation - response appreciated
  
 Hello,
 Am doing the liecense clearing for open source components in our department. 
 I did the clearing your component popt1.4.
 I scanned all files of popt 1.14 for license informations. Unfortunately 
 there are issues regarding the popt licenses. Most of the licenses does not 
 match with the MIT license. Some files are under the GPL (wich is 
 irreversible !), and 2 license informations are not correct. Jef Johnson told 
 me to post to this email in order to get the issues sorted out.
 On the home page popt is stated as MIT style license 
 http://freshmeat.net/tags/mitx-consortium-license.  But here is what I found:
 1)  Global Licenses
  
 MIT style - disclaimer X Consortium for promotion Copyright (c) 1998  Red 
 Hat Software
  
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the Software), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
  
 The above copyright notice and this permission notice shall be included in
 all copies or substantial portions of the Software.
  
 THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
 X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
 AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  
 Except as contained in this notice, the name of the X Consortium shall not be
 used in advertising or otherwise to promote the sale, use or other dealings
 in this Software without prior written authorization from the X Consortium.
 36 \artifact.unpacked\popt-1.14\COPYING
 294 \artifact.unpacked\popt-1.14\install-sh
 3070 \artifact.unpacked\popt-1.14\config.sub
 2250 \artifact.unpacked\popt-1.14\config.guess
 14434 \artifact.unpacked\popt-1.14\ltmain.sh
 125 \artifact.unpacked\popt-1.14\popthelp.c
 47 \artifact.unpacked\popt-1.14\poptint.h
 0 \artifact.unpacked\popt-1.14\test1.c
 0 \artifact.unpacked\popt-1.14\po\sv.po
 0 \artifact.unpacked\popt-1.14\po\vi.po
 0 \artifact.unpacked\popt-1.14\po\fr.po
 0 \artifact.unpacked\popt-1.14\po\pl.po
 0 \artifact.unpacked\popt-1.14\po\de.po
 44 \artifact.unpacked\popt-1.14\popt.h
 49 \artifact.unpacked\popt-1.14\poptparse.c
 2797 \artifact.unpacked\popt-1.14\popt.3
 50 \artifact.unpacked\popt-1.14\poptconfig.c
  
  
 2)  Other Licenses – NO NOT USE – license issue
 Open Issue... /* (C) 1998-2002 Red Hat, Inc. -- Licensing details are in 
 the COPYING
file accompanying popt source distributions, available from 
ftp://ftp.rpm.org/pub/rpm/dist. */ ... This strin occurs in many 
 places but the
 this link here is not correct
 Wrong license information # This file is distributed under the same 
 license as the popt package.
 # This file is put in the public domain.
 0 \artifact.unpacked\popt-1.14\po\fi.po
  
 Dual License GPL or LGPL without any version number - this is wrong  /*
 Popt Library Test Program Number Too 
 
 -- a real world test of popt bugs --
 Copyright (C) 1999 US Interactive, Inc.
 This program can be used under the GPL or LGPL at your
 whim as long as this Copyright remains attached.  
 */
 0 \artifact.unpacked\popt-1.14\test2.c
  

  
 3)  Other Licenses
 GPL V2 or later Reference with Autoconf Exception_cct
  
 This file is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 

Re: AW: INFO: Popt 1.14 license evaluation - response appreciated

2011-03-14 Thread Jeff Johnson

On Mar 14, 2011, at 7:41 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote:

 Hello,
  
 I was wondering if you could respond to my question ? Are ou going to get the 
 issues sorted out regarding the license texts ?

Is the most important issue -- highlighted in RED -- the fact that
the POPT license is no longer available at
ftp://ftp.rpm.org/pub/rpm/dist

If that's the issue, you will have to contact the owners of the rpm.org domain
(i.e. Red Hat) and tell them to put their license where oit belongs.

I've left the original license text in POPT exactly as written for historical 
continuity.

But if changing a URI is all that you want/need, I can/will change the URI.

73 de Jeff


  
 Best regards,
 Gerlinde Hulin
  
  
 _
 Von: Hulin, Gerlinde (E D EA SOL D TC1) 
 Gesendet:   Thursday, March 03, 2011 10:15 AM
 An: 'popt-devel@rpm5.org'
 Cc: Hufnagel, Michael (E D EA SOL EN)
 Betreff:INFO: Popt 1.14 license evaluation - response appreciated
  
 Hello,
 Am doing the liecense clearing for open source components in our department. 
 I did the clearing your component popt1.4.
 I scanned all files of popt 1.14 for license informations. Unfortunately 
 there are issues regarding the popt licenses. Most of the licenses does not 
 match with the MIT license. Some files are under the GPL (wich is 
 irreversible !), and 2 license informations are not correct. Jef Johnson told 
 me to post to this email in order to get the issues sorted out.
 On the home page popt is stated as MIT style license 
 http://freshmeat.net/tags/mitx-consortium-license.  But here is what I found:
 1)  Global Licenses
  
 MIT style - disclaimer X Consortium for promotion Copyright (c) 1998  Red 
 Hat Software
  
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the Software), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
  
 The above copyright notice and this permission notice shall be included in
 all copies or substantial portions of the Software.
  
 THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
 X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
 AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  
 Except as contained in this notice, the name of the X Consortium shall not be
 used in advertising or otherwise to promote the sale, use or other dealings
 in this Software without prior written authorization from the X Consortium.
 36 \artifact.unpacked\popt-1.14\COPYING
 294 \artifact.unpacked\popt-1.14\install-sh
 3070 \artifact.unpacked\popt-1.14\config.sub
 2250 \artifact.unpacked\popt-1.14\config.guess
 14434 \artifact.unpacked\popt-1.14\ltmain.sh
 125 \artifact.unpacked\popt-1.14\popthelp.c
 47 \artifact.unpacked\popt-1.14\poptint.h
 0 \artifact.unpacked\popt-1.14\test1.c
 0 \artifact.unpacked\popt-1.14\po\sv.po
 0 \artifact.unpacked\popt-1.14\po\vi.po
 0 \artifact.unpacked\popt-1.14\po\fr.po
 0 \artifact.unpacked\popt-1.14\po\pl.po
 0 \artifact.unpacked\popt-1.14\po\de.po
 44 \artifact.unpacked\popt-1.14\popt.h
 49 \artifact.unpacked\popt-1.14\poptparse.c
 2797 \artifact.unpacked\popt-1.14\popt.3
 50 \artifact.unpacked\popt-1.14\poptconfig.c
  
  
 2)  Other Licenses – NO NOT USE – license issue
 Open Issue... /* (C) 1998-2002 Red Hat, Inc. -- Licensing details are in 
 the COPYING
file accompanying popt source distributions, available from 
ftp://ftp.rpm.org/pub/rpm/dist. */ ... This strin occurs in many 
 places but the
 this link here is not correct
 Wrong license information # This file is distributed under the same 
 license as the popt package.
 # This file is put in the public domain.
 0 \artifact.unpacked\popt-1.14\po\fi.po
  
 Dual License GPL or LGPL without any version number - this is wrong  /*
 Popt Library Test Program Number Too 
 
 -- a real world test of popt bugs --
 Copyright (C) 1999 US Interactive, Inc.
 This program can be used under the GPL or LGPL at your
 whim as long as this Copyright remains attached.  
 */
 0 \artifact.unpacked\popt-1.14\test2.c
  

  
 3)  Other Licenses
 GPL V2 or later Reference with Autoconf Exception_cct
  
 This file is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your 

Re: Please remove the following content

2011-07-05 Thread Jeff Johnson

On Jul 5, 2011, at 4:32 AM, Hulin, Gerlinde (E D EA SOL D TC1) wrote:

 
 
 Hello,
 The following two mails got in your archive without my agreeement. I cannot
 accept that my complete adress and email contact is online.

My memory of the series of events leading to these messages goes like this:

- You sent mail privately asking about POPT licensing.
- I replied that the concerns should be posted to popt-devel@rpm5.org.

POPT is an open-source project that conducts matters transparently and 
publicly,
particular for matters like license audits.

- You posted publicly here:
http://rpm5.org/community/popt-devel/0244.html
- The issues were replied to here:
http://rpm5.org/community/popt-devel/0245.html

You did ask (and received an answer) on a public mailing list.

- You (again) requested a resolution to your issues here:
http://rpm5.org/community/popt-devel/0246.html
- You received two replies here:
http://rpm5.org/community/popt-devel/0247.html
http://rpm5.org/community/popt-devel/0248.html

And now you wish to undo actions that you initiated, with replies
as requested, because you dod not consent to publishing your
contact information on line?

At a minimum, your contact information is in more than the two messages
you are requesting being removed. And removing only 2 messages is _NOT_ 
considering that
the public popt-devel@rpm5.org mailing list is reflected in many
other locations on the internet.

Even if I removed the messages in popt-devel@rpm5.org, you seem to have
given (imho, I am not a lawyer) implied consent by initiating actions that
contained your contact info and choosing to publish on a public mailing list.

I can/will remove the messages in popt-devel@rpm5.org if there is better
reason than that you did not realize what public and transparent means
when you requested information. Otherwise, consistent with policy @rpm5.org,
I'd prefer to leave the public record exactly as is: other actions, like
removing messages and otherwise changing the public record, are inconsistent
with the intents and goals of a FL/OSS project.

73 de Jeff


 
 Please remove the conent from the archive
 
 http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html
 http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html
 
 Thank you very much
 
 Best regards,
 Gerlinde Hulin
 
 -Original Message-
 From: Mail Archive Support [mailto:themailarch...@gmail.com] 
 Sent: Wednesday, June 29, 2011 10:34 PM
 To: Hulin, Gerlinde (E D EA SOL D TC1)
 Subject: Re: Please remove the following content
 
 Gerlinde,
 
 All the information we have on that list can be found here:
 http://www.mail-archive.com/popt-devel@rpm5.org/info.html
 
 Beyond that, we do not know the contact information for the mailing
 list administrators.  Most mailing list services have a -owner
 address where you can reach the list admin (for example, if the list
 is gos...@jab.org then the list admin can likely be reached at
 gossip-ow...@jab.org).  If this does not work, you will need to search
 for the website that hosts the mailing list, or post a question to the
 mailing list.
 
 Tom
 Support
 The Mail Archive
 
 On Wed, Jun 29, 2011 at 8:35 AM, Hulin, Gerlinde (E D EA SOL D TC1)
 gerlinde.hu...@siemens.com wrote:
 Hello,
 Who is the list administrator ? Since this email got published without my 
 aproval I do not know who added this content. However you can see from my 
 email account that my email account is in the two web pages.
 _http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html_
 _http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html_
 Best regards,
 Gerlinde Hulin
 
 -Original Message-
 From: Mail Archive Support [mailto:themailarch...@gmail.com]
 Sent: Wednesday, June 29, 2011 4:53 PM
 To: Hulin, Gerlinde (E D EA SOL D TC1)
 Subject: Re: Please remove the following content
 
 Gerlinde,
 
 Thanks for writing.  The Mail Archive's policy is to delete messages
 only with the approval of the list administrator.  We are providing a
 free service for list administrators and the admin needs to be the
 final decision maker on archived list content.
 
 Please discuss your request with the list admin and have him contact
 us directly if he wishes to remove the posts from the archive.
 
 Tom
 Support
 The Mail Archive
 
 On Wed, Jun 29, 2011 at 12:25 AM, Hulin, Gerlinde (E D EA SOL D TC1)
 gerlinde.hu...@siemens.com wrote:
 Hello,
 The following two mails got in your archive without my agreeement. I cannot
 accept that my complete adress and email contact is online.
 
 Please remove the conent from the archive
 
 _http://www.mail-archive.com/popt-devel@rpm5.org/msg00245.html_
 _http://www.mail-archive.com/popt-devel@rpm5.org/msg00246.html_
 
 Thank you very much
 
 Best regards,
 Gerlinde Hulin
 
 
 
 
 
 
 
 --
 Support
 The Mail Archive
 www.mail-archive.com
 
 
 
 
 -- 
 Support
 The Mail Archive
 www.mail-archive.com
 

Re: Support for variable number of arguments in popt

2011-09-07 Thread Jeff Johnson

On Sep 7, 2011, at 4:44 AM, Christian Schmidt wrote:

 Hi,
 
 I'm trying to parse a command line that can contain multiple variable
 number of arguments for a parameter, e.g.
 
 program -r /dev/sda /dev/sdb -m /dev/sdc /dev/sdd -b 16m …
 

Traditionally, uglix was designed with the model
PROGRAM OPTIONS ARGUMENTS
and that is captured in strict POSIX (and still common on *BSD systems iirc).

The default option processing enhances --options=arg to take the next
item, and there is the = that has been added to introduce some form
of stickiness.

What you are seeking with multiple arguments to a single option
(and I understand well why you are attempting) isn't well supported
anywhere afaik. The usual solution is to embed white space within
quotes like

program -r /dev/sda /dev/sdb -m /dev/sdc /dev/sdd -b 16m

 The reason for the space separated lists is simply shell expansion.
 Given existing device nodes you could write program -r /dev/sd[ab] -m
 /dev/sd[cd] -b 16m ... to reach the same. Similar expansion could be
 done with {a..z} or wildcard patterns. However this is not a case of
 leftover arguments since the context (in the above example, -r or -m) is
 relevant.
 

Got it.

 So far I tried to use POPT_ARG_ARGV (which expects one -r/-m for each
 argument) as well as poptPeekArg from within a r/m handler to look at
 the next word in the command line. However, poptPeekArg only seems to
 work after all arguments are parsed.
 

Yes I can believe that poptPeekArg() isn't going to work for what you
intend. I _MIGHT_ be able to make poptPeekArg() work that way, but
its rather tricky to unravel nested coroutine recursions to get
that job done. The implementation would likely need a backtracking
parser so that all the options copuld be parsed out to determine
what exactly the next argument should be. POPT is already doing
that to support the rather obscure !#:+ syntax used by popt aliases.

(aside)
The syntax choice was derived from KSH/BASH … but its dreadfully obscure
shell functionality and only !#:+ is implemented in POPT.

Here's some usage examples from /usr/lib/rpm/rpmpopt:

#   [--dbpath DIRECTORYuse database in DIRECTORY
rpm alias --dbpath  --define '_dbpath !#:+'
#   [--ftpport port]  port number of ftp server (or proxy)
rpm alias --ftpport --define '_ftpport !#:+'
#   [--ftpproxy host] hostname or IP of ftp proxy
rpm alias --ftpproxy--define '_ftpproxy !#:+'
#   [--httpport port] port number of http server (or proxy)
rpm alias --httpport--define '_httpport !#:+'
#   [--httpproxy host]hostname or IP of http proxy
rpm alias --httpproxy   --define '_httpproxy !#:+'

You _MIGHT_ be able to consume the next two arguments by rewriting -m/-r
with an alias, and then rewriting what is passed to the program with
a POPT_ARGFLAG_DOC_HIDDEN helper option (--mstuff/--rstuff used in example) like

program alias -m--mstuff !#:+ --mstuff !#:+
program alias -r--rstuff !#:+ --rstuff !#:+

if the number of arguments to -m and -r is always 2 strings.

 Is there a way to realize what I'm trying within the current version of
 popt, and if not, would there be any interest (or chance of being added)
 implementing a POP_ARG_LIST that would act like POPT_ARG_ARGV, but take
 all arguments until the next parameter starting with a -?
 

There's likely some other alternatives using a POPT callback (caveat: it
would require peeping into POPT internal data structures)

And its possible to rewind/restart POPT argument processing, but that
too is quite tricky (RPM used to do multiple passes on options/args
in order to extract one option that then modified how the options were
further processed: total PITA to maintain and not KISS reliable engineering …)

hth

73 de Jeff
 Regards,
 Christian
 __
 POPT Library   http://rpm5.org
 Developer Communication List   popt-devel@rpm5.org

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