Re: Patch from Fedora containing popt(3) manpage fixes
Hello Jeff, On Sun, 24 Nov 2013, Jeffrey Johnson wrote: > My brainfart, sorry. The 1st patch I applied made the changes and I got > tricked. > > Now checked in. awesome, thank you! Greetings, Robert pgpDQ8bcfzb8W.pgp Description: PGP signature
Re: Patch from Fedora containing popt(3) manpage fixes
On Nov 24, 2013, at 12:41 PM, Robert Scheck wrote: > Hello Jeff, > > On Sun, 24 Nov 2013, Jeffrey Johnson wrote: >> Hmmm ... what is checked into cvs is already fixed (so likely fixed since >> popt-1.16): >> ... >> .RB "arguments. When " --usage " or " --help " are passed to programs which >> use popt's automatic help, popt displays the appropriate message on >> stderr as soon as it finds the option, and exits the program with a >> return code of 0. If you want to use popt's automatic help generation in >> ... >> A conversion from a string to a number (int or long) failed due >> to the string containing non-numeric characters. This occurs when >> .BR poptGetNextOpt() " is processing an argument of type " > > I am a bit confused: I had a look to branch popt_1_17 (version 1.22.2.1) > and version 1.23...and both do not seem to contain these changes. That is > why I updated the patch and re-sent it. What did I overlook or where is > my mistake? > My brainfart, sorry. The 1st patch I applied made the changes and I got tricked. Now checked in. 73 de Jeff __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Patch from Fedora containing popt(3) manpage fixes
Hello Jeff, On Sun, 24 Nov 2013, Jeffrey Johnson wrote: > Hmmm ... what is checked into cvs is already fixed (so likely fixed since > popt-1.16): > ... > .RB "arguments. When " --usage " or " --help " are passed to programs which > use popt's automatic help, popt displays the appropriate message on > stderr as soon as it finds the option, and exits the program with a > return code of 0. If you want to use popt's automatic help generation in > ... > A conversion from a string to a number (int or long) failed due > to the string containing non-numeric characters. This occurs when > .BR poptGetNextOpt() " is processing an argument of type " I am a bit confused: I had a look to branch popt_1_17 (version 1.22.2.1) and version 1.23...and both do not seem to contain these changes. That is why I updated the patch and re-sent it. What did I overlook or where is my mistake? Greetings, Robert pgpkXERO2GYnF.pgp Description: PGP signature
Re: Patch from Fedora containing popt(3) manpage fixes
On Nov 24, 2013, at 11:57 AM, Robert Scheck wrote: > Hello Jeff, > > On Sun, 24 Nov 2013, Jeffrey Johnson wrote: >> AFAICT, the spell corrections here @rpm5.org >> >>- devzero2000: fix misspelling >> Fix misspelling using http://github.com/lyda/misspell-check >> >> are now being returned as a patch from Fedora. > > whoops...you are partially right. I should have checked that. Attached is a > new patch for the two changes that did not yet happen upstream. > Hmmm ... what is checked into cvs is already fixed (so likely fixed since popt-1.16): ... .RB "arguments. When " --usage " or " --help " are passed to programs which use popt's automatic help, popt displays the appropriate message on stderr as soon as it finds the option, and exits the program with a return code of 0. If you want to use popt's automatic help generation in ... A conversion from a string to a number (int or long) failed due to the string containing non-numeric characters. This occurs when .BR poptGetNextOpt() " is processing an argument of type " >> I'm glad to hear that Fedora has upgraded from popt-1.13. Or have they? > > Not yet, but I am working on that, at least for Fedora Rawhide (-> F21). > Make peace with whether argv is allocated contiguously or with separate alloc's. There's no easy answer: if compiled "traditionally", careful programming that expects argv arrays to have malloc'd strings will have double free's. And vice versa: valgrind will show "leaks" on older programs that "used to work" with popt. No matter what: RPM+POPT is now internal again, again so that I don't have to deal with what distros choose to do with popt (its a rather small library). 73 de Jeff hth 73 de Jeff > > Greetings, > Robert > __ POPT Library http://rpm5.org Developer Communication List [email protected]
Re: Patch from Fedora containing popt(3) manpage fixes
Hello Jeff, On Sun, 24 Nov 2013, Jeffrey Johnson wrote: > AFAICT, the spell corrections here @rpm5.org > > - devzero2000: fix misspelling > Fix misspelling using http://github.com/lyda/misspell-check > > are now being returned as a patch from Fedora. whoops...you are partially right. I should have checked that. Attached is a new patch for the two changes that did not yet happen upstream. > I'm glad to hear that Fedora has upgraded from popt-1.13. Or have they? Not yet, but I am working on that, at least for Fedora Rawhide (-> F21). Greetings, Robert Patch by John Bradshaw for popt <= 1.16 which fixes some spelling mistakes in popt man page. See https://bugzilla.redhat.com/show_bug.cgi?id=675567 for further details, please. This patch was proposed to upstream: http://rpm5.org/community/popt-devel/0263.html --- popt-1.16/popt.32009-07-25 20:52:36.0 +0200 +++ popt-1.16/popt.3.man-page 2013-11-24 15:59:58.0 +0100 @@ -200,7 +200,7 @@ .RB "This macro includes another option table (via " POPT_ARG_INCLUDE_TABLE ; see below) in the main one which provides the table entries for these .RB "arguments. When " --usage " or " --help " are passed to programs which -use popt's automatical help, popt displays the appropriate message on +use popt's automatic help, popt displays the appropriate message on stderr as soon as it finds the option, and exits the program with a return code of 0. If you want to use popt's automatic help generation in a different way, you need to explicitly add the option entries to your programs @@ -473,7 +473,7 @@ .TP .B POPT_ERROR_BADNUMBER A conversion from a string to a number (int or long) failed due -to the string containing nonnumeric characters. This occurs when +to the string containing non-numeric characters. This occurs when .BR poptGetNextOpt() " is processing an argument of type " .BR POPT_ARG_INT ", " POPT_ARG_SHORT ", " POPT_ARG_LONG ", " POPT_ARG_LONGLONG ", " .RB POPT_ARG_FLOAT ", or " POPT_ARG_DOUBLE "." pgpEbHcY_2iZM.pgp Description: PGP signature
Re: Patch from Fedora containing popt(3) manpage fixes
On Nov 24, 2013, at 10:07 AM, Robert Scheck wrote: > Hello all, > Hi Robert! > attached is a patch by John Bradshaw who provided a patch to Fedora > containing some popt(3) manpage fixes. Aside from some definate typos I > am not absolutely sure about the changes...as a non-native speaker. > AFAICT, the spell corrections here @rpm5.org - devzero2000: fix misspelling Fix misspelling using http://github.com/lyda/misspell-check are now being returned as a patch from Fedora. > However, please review that patch and if suitable apply it for the next > popt release. > I'm glad to hear that Fedora has upgraded from popt-1.13. Or have they? 73 de Jeff > > Greetings, > Robert > __ POPT Library http://rpm5.org Developer Communication List [email protected]
