AFAIK, this is the penultimate first/next release of popt as a
separate project:
http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.11-1.src.rpm
I may have to rebuild once more to get the i18n contacts updated.
Anybody willing to try and QA the packaging would be most welcome.
I'm alway
On Jun 14, 2007, at 8:11 AM, Ralf S. Engelschall wrote:
I have one subtle issue on my RPM/POPT todo list since a longer
time: POPT's use of the ancient 32V AT&T UNIX alloca(3), a machine-,
compiler-, and system-dependent and especially non-POSIX (and hence
less portable) function whose use is e
On Jun 14, 2007, at 7:42 AM, Ralf S. Engelschall wrote:
On Tue, Jun 12, 2007, Jeff Johnson wrote:
AFAIK, this is the penultimate first/next release of popt as a
separate
project:
http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.11-1.src.rpm
Any reason why this is still not stored
On Jun 14, 2007, at 8:50 AM, Arkadiusz Miskiewicz wrote:
On Thursday 14 of June 2007, Ralf S. Engelschall wrote:
On Tue, Jun 12, 2007, Jeff Johnson wrote:
AFAIK, this is the penultimate first/next release of popt as a
separate
project:
http://wraptastic.org/pub/i386-linux/SRPMS/popt
On Jun 14, 2007, at 9:14 AM, Ralf S. Engelschall wrote:
Puhhh... I usually at least would avoid like hell to change the
external
and well-established API of POPT ;-) That's why I just concentrate on
build environment, portability and internal cleanups here.
Wuss. ;-)
popt-2.0 with the h
w00t!
Yes with the necessary va_end patch.
Enjoy!
73 de Jeff
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
On Jun 19, 2007, at 4:30 PM, Anders F Björklund wrote:
Jeff Johnson wrote:
w00t!
Yes with the necessary va_end patch.
Wondered why my RPM installation suddently stopped working...
Turned out that I updated the outstanding ports and didn't
really browse through entire list. So it up
On Jun 21, 2007, at 4:46 PM, Anders F Björklund wrote:
This causes spectacular failures like not finding "rpmq":
$ rpm -qa
rpm: -qa: Invalid argument
Downgrading to popt 1.10_4 again fixed it, will try to
figure out how to make the two co-exist... (rpm/popt)
Found the reason for why it could
A release of popt-1.12 with recent fixes is staged at
http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.12-1.src.rpm
I'll likely release this weekend. Any sanity checks on the packaging
are appreciated.
73 de Jeff
__
P
I've just signed and uploaded popt-1.12 tarball and *.rpm packages.
Here's the changelog:
1.11 -> 1.12
- jbj: plug a memory leak.
- jbj: fix index thinko.
- jbj: add vi.po (Translation Project).
- jbj: add nl.po (Translation Project).
Enjoy!
73 de Jeff
__
On Aug 13, 2007, at 5:49 PM, Robert Scheck wrote:
Good evening all,
I'll get the popt maintainer at Fedora and Panu from Red Hat is
likely to
get co-maintainer once the package is reviewed. And for reviewing a
package
there should be no open bug reports at all, so I'm walking through
the
On Aug 14, 2007, at 3:14 AM, Robert Scheck wrote:
On Mon, 13 Aug 2007, Jeff Johnson wrote:
What is the copyright issue? Claiming "claimed about this" helps
nothing.
The files test3.c, popint.c and system.h are missing the license
header.
AFAIK these files were introduced by
On Aug 14, 2007, at 4:49 AM, Göran Uddeborg wrote:
- Bugzilla Bug 102254: popt messages need explicit domain with
dgettext()
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102254
-> As per http://rpm5.org/cvs/chngview?cn=8187, this bug report
IMHO
seems to be partially solv
On Aug 14, 2007, at 5:16 PM, Robert Scheck wrote:
Evening Jeff,
On Tue, 14 Aug 2007, Jeff Johnson wrote:
and there's at least one other old popt "bug" report in bugzilla
misassigned to rpm.
which one exactly? Hopefully, you don't want to play hide and seek
with
On Oct 5, 2007, at 5:04 PM, Bernhard Rosenkraenzer wrote:
Hi,
The attached patch makes popt parse all files in /etc/popt.d in
addition
to /etc/popt -- this makes it easier to include default popt config
files in
the packages of applications using popt.
Added. Thanks for the patch.
73 d
Added. Thanks for the patch.
73 de Jeff
On Nov 3, 2007, at 12:21 PM, Emanuele Giaquinta wrote:
Index: poptconfig.c
===
RCS file: /v/rpm/cvs/popt/poptconfig.c,v
retrieving revision 1.31
diff -u -r1.31 poptconfig.c
--- poptconfig.c
The recent changes are likely sufficient (imho) to justify
releasing popt.
These are bout the only things that I see today that should
be cleaned up some:
1) strdup_locale_from_utf8() should be rewritten.
There are obvious simplifications, such as collapsing the flow
to call iconv only on
I've built a release candidate for popt-1.13.
The source package is at
http:/wraptastic.org/pub/i386-linux/SRPMS/popt-1.13-1.src.rpm
This will likely become the final popt-1.13 release (assuming I
did not screw something up) this weekend.
Here's the the changes 1.12 -> 1.13:
1.12 -> 1.13:
On Dec 6, 2007, at 5:41 PM, Danny Sung wrote:
Hi, the popt source code references [EMAIL PROTECTED] as the
maintainer, but that bounced, so hopefully this is the right place
to send this...
Sorry if this is old news to people... I /just/ discovered a
memory leak in my use of poptGetNext
I've built popt-1.13 packages at
ftp://wraptastic.org/pub/i386-linux/SRPMS/popt-1.13-1.src.rpm
This will be released as popt-1.13 through rpm5.org after receiving
3 positive reports
of WORKSFORME or Thursday evening, which ever comes first.
Here's the final changelog for popt-1.13:
1.12
On Dec 12, 2007, at 1:50 AM, Ralf S. Engelschall wrote:
On Tue, Dec 11, 2007, Jeff Johnson wrote:
I've built popt-1.13 packages at
ftp://wraptastic.org/pub/i386-linux/SRPMS/popt-1.13-1.src.rpm
URL does not exist, cannot fetch.
Sorry. Daemons restarted, try http.
Also, reminder
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 pro
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
So
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
I've been rewriting pcregrep to use popt instead the last week.
One of the side effects of teaching pcregrep to use popt is
that I've found some time to work on popt as well.
I will merge the patches posted to before
popt-1.14.
Meanwhile, since the patches have mostly to do with --help colu
Hi --
I've merged (as much as I am comfortable) the several patches
since popt-1.13. There are some widely divergent styles of fixing
essentially a simple problem, that strlen() cannot be used to calculate
display alignment with multibyte characters.
Attached (for convenience) are the changes I'
I've built popt-1.14-1 packages from HEAD on Fedora/i386.
You should be able to find the packages at
http://wraptastic.org/pub/i386-linux/SRPMS/popt-1.14-1.src.rpm
http://wraptastic.org/pub/i386-linux/RPMS/popt-1.14-1.i386.rpm
All that remains AFAIK is to finish integrating UTF-8 and PO
On Feb 19, 2008, at 3:22 PM, Robert Scheck wrote:
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
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
On Mar 8, 2008, at 12:10 PM, Wayne Davison wrote:
The attached patch turns on more extensive warnings in gcc (-W) and
then
fixes a bunch of unused-arg warnings and one signed/unsigned
comparison
warning. Non-gcc compilers should be unaffected.
This should help to find problems in the futu
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
On Mar 8, 2008, at 12:56 PM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
0 arg2: foo"
I'm not seeing that error with the CVS version. I do no
On Mar 8, 2008, at 12:56 PM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
0 arg2: foo"
I'm not seeing that error with the CVS version. I do no
On Mar 8, 2008, at 11:24 PM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 06:11:09PM -0500, Jeff Johnson wrote:
Hmmm, we appear to have different behavior wrto echo. Your
patch changes testit.sh to include an explicit "--", which (when
I last fixed testit.sh like 3 weeks ago) does
On Mar 9, 2008, at 12:26 AM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 10:42:36AM -0800, Wayne Davison wrote:
(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 bu
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
On Mar 9, 2008, at 10:51 AM, Jeff Johnson wrote:
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)
This should have been
if (rc > -1 &
On Mar 9, 2008, at 5:38 PM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
to the "man vsnprintf" example. See what you think ...
Looks good. I did some tweaking based on
On Mar 9, 2008, at 6:22 PM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
[EMAIL PROTECTED] popt]$ /bin/echo --foo --bar
--bar
[EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar
--foo --bar
OK, Let's hope that your echo will not drop anything if the
On Mar 9, 2008, at 6:36 PM, Wayne Davison wrote:
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
Running test test1 - 9.
Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
0 arg2: foo"
I can get that failure if the line I ad
On Mar 9, 2008, at 7:13 PM, Wayne Davison wrote:
I'm curious why the xmalloc() function (and its brethren) exits with a
fatal error on only some systems and not on all systems? I would
think
that the code should use the exiting functions in all cases, and just
provide differing versions of
On Mar 9, 2008, at 7:59 PM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 07:26:31PM -0400, Jeff Johnson wrote:
There are some subtleties however with xstrdup. [... mtrace related
issues ...]
Right, that's why I preserved the HAVE_MCHECK_H version using its own
malloc() call (it's
On Mar 9, 2008, at 10:00 PM, Wayne Davison wrote:
On Sun, Mar 09, 2008 at 08:27:25PM -0400, Jeff Johnson wrote:
Using xmalloc just opens up a can-of-worms while lusers fuss about
non-gcc compiler extension portability.
Aha, I had failed to notice that the "? :" bit was a gcc
Added, will be in popt-1.14. Thanks for the patch.
73 de Jeff
On Mar 27, 2008, at 12:01 PM, Stanislav Brabec wrote:
Hallo.
Attached patch allows to build popt-1.13 on both glibc and uclibc
based systems.
Henning Heinold pointed to the problem and added @[EMAIL PROTECTED]
Adding AM_ICONV_LI
On Mar 26, 2008, at 11:13 AM, Wayne Davison wrote:
I made a couple more places use stpcpy() in the code, optimizing
away a
couple strlen() calls in the process. I also tweaked the help code
that
was abbreviating a long value using "..." to allow a string to fit
if it
can, rather than alwa
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
On Apr 2, 2008, at 1:46 PM, Jeff Johnson wrote:
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!
I've released popt-1.14. You can now find
On Apr 26, 2008, at 6:40 PM, Dmitry V. Levin wrote:
Hi,
I wonder why the libpopt.vers version script exports _init and _fini
symbols?
Not so much exports the symbols as permits exposure.
Dynamic linker calls _init/_fini anyway.
Regular application can use these symbols only via dlsym(3).
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
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 =
"
On May 2, 2008, at 2:24 AM, Ralf S. Engelschall wrote:
On Thu, May 01, 2008, Jeff Johnson wrote:
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
A common paradigm when using CLI options is to select 1-of-N mutually
exclusive
options.
ATM, the burden of detecting "mutually exclusive" is up to the
application, not popt.
There's room (if I'm careful) for adding bits (I *think* I can
squeeze out 8 bits) for a "mutually exclusive"
gro
Not sure where this msg went ... apologies if duplicated.
Begin forwarded message:
From: Jeff Johnson <[EMAIL PROTECTED]>
Date: May 5, 2008 3:18:06 PM EDT
To: popt-devel@rpm5.org
Subject: Adding lcov/gcov coverage testing
I'm going to add coverage testing for popt based on lcov
SSIA
(aside) I've wanted to have the abilty to attach popt alias/exec to
argv[0] from
poptrc configuration using fnmatch(3) for years. Only legacy forward
compatibility has stopped me ...
For portability to the fnmatch(3) deprived, I'll work up a strncmp match
to handle a trailing "*" splat
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:
$ [
velops. 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
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 co
(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 , please. I'll take
patches however they are sent however. *shrug*
I can't tie builds of
FWIW, I checked in a patch to check for srandom()
and disable (by returning POPT_ERROR_BADOPERATION) if
HAVE_SRANDOM was not defined when popt was built.
I think we both agree that popt not building if
srandom() is not present is a flaw no matter whether
its solved by disabling POPT_ARGFLAG_RANDO
lifying 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
Date: December 18, 2008 3:15
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" ma
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 '@'
On Dec 19, 2008, at 11:13 AM, Jeff Johnson wrote:
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
popt competes for mind share with getopt, and
particularly with GNU getopt_long, the Debian added borkedness (jmnsho).
Should I add a getopt(3)/getopt_long(3) wrapper onto
popt to lower the barrier to converting from getopt_long(3)?
I personally don't care a bit because I use popt instead
of get
On Dec 20, 2008, at 3:06 AM, Ralf S. Engelschall wrote:
Ah, yes, as long as one can still build a POPT without these two
symbols
(to avoid conflicts) this would be a really nice addition for POPT. I
would say: go for it as long as is an _optional_ feature!
I should likely state the under
On Dec 19, 2008, at 1:11 PM, Jeff Johnson wrote:
Opinions? Otherwise the patch is mostly *yawn* ...
I've checked in a mostly complete "attention" API into popt.
There's a couple nit-picks left to finish up:
1) '@' ends up colliding with extended '@(/A|/
There's an odd behavior with popt that bites me every
other year or so in RPM that I should describe.
Note that RPM uses popt in ways no other program does (and
likely in ways that no other program should use popt).
E.g., RPM has 3 separate contextual meanings for -i:
1) -i as in --insta
Its likely as good a time as any to release popt-1.15,
as I'm never sure when I will have time to work on popt.
My reason for releasing now is so that I can start using
two new features in popt, and start phasing out legacy
compatible retrofit code:
The first "feature" is POPT_ARGFLAG_TOGGLE, wh
On Jul 22, 2009, at 3:05 PM, Ralf S. Engelschall wrote:
On Tue, Jul 21, 2009, devzero2000 wrote:
Very thiny patch for integrating pkg-config(1) support for popt
library into popt itself.
Exept for the hard-coded version "1.15" in configure.ac
this looks good and should be taken over.
I m
On Jul 23, 2009, at 3:36 PM, Ralf S. Engelschall wrote:
Well, the main point of pkg-config is not querying the version of a
library, but to _transitively_ query the build-time flags required to
build against a library. For this reason even our RPM_CHECK_LIB is
able
to use pkg-config files
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 i
On Jul 21, 2009, at 11:21 AM, devzero2000 wrote:
Very thiny patch for integrating pkg-config(1) support for popt
library into popt itself.
Sorry for the delay.
I applied the pkgconfig patch with these changes:
1) I'd rather see "popt.pc", not "libpo...@version@.pc". That's
consistent with
feature parity with
getopt_long()
(but perhaps not, option groups would be very annoying to do correctly).
So last chance to voice an opinion ...
73 de Jeff
Begin forwarded message:
From: Jeff Johnson
Date: July 10, 2009 11:24:46 AM EDT
To: popt-devel@rpm5.org
Subject: Adding option bit s
I've just checked in a proof-of-concept implementation to
use Bloom filters to handle arbitrary option string values
with popt.
The problem that I am trying to solve in popt (and for RPM and
for option processing in general) is to devise
a means to handle arbitrary (as in unknown when
code is com
Attached is a toy program to illustrate the new POPT_ARG_BITSET API in
popt.
The toy program uses /usr/share/dict/words as a attribute
universe, and checks arguments to see if they are in the
attribute dictionary.
Here's some usage examples
$ wc -l /usr/share/dict/words
479827
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 d
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, --
lin
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 lar
This is largely a cosmetic issue introduced by using libtool
(i.e. "test1" != "lt-test1"in argv[0]).
But yes, could/should be fixed.
73 de Jeff
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 sys
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
nt with a really long
description. After all, we have to test
argument help wrapping somehow, right?
And if you can confirm the patch "works" in the next 24 hours,
I'll re-roll the (unannounced) popt-1.16.tar.gz.
Ot
After some thought (and some prodding), I think its
time for a major release of 2.0 with the (probability,
dunno yet) of changing both the API and ABI of POPT.
So I'm looking for feature requests -- good/bad/ugly/whatever --
in order to get a ROADMAP and a timeline together for POPT 2.0.
In gener
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 b
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 mes
On Jun 5, 2010, at 12:48 PM, Wayne Davison wrote:
> On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson 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
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
Since --help is the the topic de jure ...
... adding a popt table processor callback to
transform --help spewage opaquely into whatever
form is desired, with some simple transforms
like HTML tables or DocBook XML markup or YAML
used for configuring persistent option default
settings, or the exist
I happen to have a valgrind trace on my screen that shows the issue
==25160==
==25160== 49 bytes in 1 blocks are still reachable in loss record 2 of 2
==25160==at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25160==by 0x314D9A: poptGetNextOpt (popt.c:1203)
==25160==by 0x40697CD: rpmc
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 A
On Jun 7, 2010, at 11:50 AM, Mark Hatle wrote:
> Jeff Johnson wrote:
>> 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 p
On Jun 7, 2010, at 12:02 PM, Jeff Johnson wrote:
>
> Changing the soname or even (gasp!) using ELF symbol versioning
> is quite doable, all the necessary precursor elements have been in place
> for years.
>
I should point out the deep flaw using ELF symbol versioning ...
On Jun 7, 2010, at 12:20 PM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson wrote:
> And without some deterministic way to tell whether its a POPT 1.x <-> 2.x
> table being fed to the POPT API/ABI, well, only a deliberately
> "incompatible" POPT
On Jun 7, 2010, at 12:51 PM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson wrote:
> The added tyrrany of forcing every application that currently has
> -lpopt
> to change to
> -ljdod
> will be rate-determining to adoption (and glacially/tect
a
> popt3 =) ).
>
The project name is "POPT", the version being discussed is "2.0".
There is no "popt2" nor (imho) is there any need for the renaming,
nor setting the precedent of "popt3" -> ... -> "popt123456789" in the 30th
century.
73
On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
> My personal choice in things I write is to expect the caller to strdup().
> But I understand the reentrancy issue here. (though why you'd be using popt
> in a thread is beyond me at this time.. and it does have a poptContext handle
> anyway).
>
On Jun 7, 2010, at 2:24 PM, Danny Sung wrote:
>
>
> Actually I really like this idea. This would effectively introduce what
> could be a plugin architecture for popt. Ideally this should be done in a
> way where someone could create say an XML output and release a separate
> library calle
On Jun 7, 2010, at 2:44 PM, Jeff Johnson wrote:
>
> On Jun 7, 2010, at 2:24 PM, Danny Sung wrote:
>
>>
>>
>> Actually I really like this idea. This would effectively introduce what
>> could be a plugin architecture for popt. Ideally this should be done
I've mentioned several times, so I might as well post the URI
to the POPT code review
http://rusty.ozlabs.org/
Rusty is also strongly advocating POPT 2.0 (when I asked
privately) and believes that "incompatibility" in an ABI
isn't as important an issue as future usage cases (my
paraphrase
On Jun 7, 2010, at 3:34 PM, Jeff Johnson wrote:
>
> The bottom line was: excellent code
>
> ANd credit where it is due:
> Erik Troan wrote most of POPT, I was just his packaging "bitch" ;-)
> But I've long since re-written both POPT and RPM
On Jun 7, 2010, at 4:16 PM, Danny Sung wrote:
>
>
> On 6/7/2010 11:38 AM, Jeff Johnson wrote:
>>
>> On Jun 7, 2010, at 2:00 PM, Danny Sung wrote:
>>
>>> My personal choice in things I write is to expect the caller to strdup().
>>> But I under
1 - 100 of 140 matches
Mail list logo
