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-1.16-man-page.patch> ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
