Re: nproc -> LGPL
Glen Lenker wrote: > > Glen, do you also agree with Ludo's request? > > It is fine with me; nproc is quite libraryish. OK, I've pushed the license change. Bruno
update doc regarding Solaris 11
About a month ago, Solaris 11 Express was released. It's something like a beta
of Solaris 11 that is scheduled to be released in 2011. It's the successor
(from the Oracle side) of the OpenSolaris project; maybe we'll also have
to consider Illumos / OpenIndiana in the future.
I'm updating the documentation, replacing many mentions of "Solaris 10"
by "Solaris 11 2010-11".
2010-12-04 Bruno Haible
Update for Solaris 11 2010-11.
* doc/{glibc,posix}-{functions,headers}: Add info about Solaris 11
Express, released in November 2010.
More important than the changes are the places that have not changed, that
is, the bugs which have been fixed and the functions which have been added,
compared to Solaris 10.
New POSIX functions:
dirfd
faccessat
fchmodat
futimens
getdelim
getline
linkat
mkdirat
mkdtemp
mkfifoat
mknodat
posix_fadvise
posix_fallocate
posix_madvise
posix_memalign
pthread_mutexattr_getrobust
pthread_mutexattr_setrobust
pthread_mutex_consistent
readlinkat
stpcpy
stpncpy
strndup
strnlen
symlinkat
utimensat
wcpcpy
wcpncpy
wcscasecmp
wcsdup
wcsncasecmp
wcsnlen
New glibc compatible functions and variables:
advance
asprintf
backtrace_symbols_fd
backtrace_symbols
backtrace
canonicalize_file_name
cbc_crypt
clearenv
dl_iterate_phdr
ecb_crypt
err
errx
fcloseall
ffsll
ffsl
freeifaddrs
getifaddrs
getipv4sourcefilter
get_nprocs_conf
get_nprocs
getsourcefilter
inet_neta
loc1
loc2
locs
memmem
mkstemps
setipv4sourcefilter
setsourcefilter
step
strcasestr
strchrnul
strsep
vasprintf
verr
verrx
vwarn
vwarnx
warn
warnx
New features:
now supports also the 2002 revision of GNU .mo files.
Bug fixes:
now defines ssize_t.
now defines NAN and HUGE_VAL to usable values.
getopt_long and getopt_long_only support the '+' flag.
The *printf functions support precisions larger than 512.
iconv() now reports failures.
realpath() actually works now.
strcoll() in UTF-8 locales is fixed.
Bruno
Re: return values of test programs in *.m4 macros
John Darrington wrote: > I'd like to extend this style to all AC_RUN_IFELSE invocations in gnulib, > ... > Autoconf and some other projects use the return code 77 to indicate that a > test > neither passed nor failed, but could not be conducted. I'm talking about programs run through AC_RUN_IFELSE, not about the contents of TESTS in Automake. > Similarly aegis and > projects using it regard 0 as "pass", 1 as "fail" and anything else as > "indeterminate". This is not a problem: aegis cannot look at the return values of programs that come from gnulib *.m4 files, and vice versa. Bruno
Re: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions
Paul Eggert wrote: > On 12/03/10 02:03, Jim Meyering wrote: > >> Would you mind adding a "Bug fixes" entry for this >> in coreutils' NEWS file? It'd be nice to commit that >> along with an update of the gnulib submodule to the latest. > > Sure, done, with this notice: > > cp -u no longer does unnecessary copying merely because the source > has finer-grained time stamps than the destination. Thanks! >> As for a test, it shouldn't be too hard to create a root-only test >> on linux/gnu systems, since _PC_TIMESTAMP_RESOLUTION is not defined. >> Create two loop-mounted file systems of types that have the desired >> difference in time stamp resolution, and run commands like Dan did. > > Hmm, well, I can see a lot going wrong with that, such as garbage in the > mount table if the test is interrupted. (Also, there's the little problem > that I lack root access on the hosts that I do builds on these days: does > that get me off the hook? :-) I didn't mean to make it sound like a requirement. I was merely thinking aloud about how I might do it.
Re: return values of test programs in *.m4 macros
On 12/04/2010 11:44 AM, Bruno Haible wrote: > Eric, Paul, Jim, > >> That sort of thing (possibly with bit masks, as you mention) >> sounds like a win to me. > > Thanks for your support. > > Eric Blake wrote: >> A bit-mask approach gives more information, >> but may be a bit harder to code, and you are still limited to only 6 >> failures before you run afoul of $? limitations. > > It's a bit harder, yes. One needs to think about whether it's useful > to execute the second line of code after the first line fails. > > And one is limited to 7 possible bits that can be set. A return > value of 126 or 127 as a bit combination is extremely unlikely, > because it would mean that 6 out of 7 independent bugs are all > present on that particular machine. One other thing to be careful of with bit masks. If the particular combination of failures matches 63, 77, or 99 (as commonly used by automake and autoconf to mean version mismatch, skip, or hard fail), then the configure script might misbehave. Enumerated failures, while only providing the first failure rather than a combination of failures, are less likely to get that high. > > Here's the proposed patch. To exclude typos and normal mistakes, > I tested it on 11 different platforms, to verify that all cache > variables and the entire config.status come out the same, with > and without the patch. Thanks for tackling this. I haven't looked closely at it yet, but given your testing, it's probably won't need much further tweaking. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: No justification for --no-justification (man)
On Sat, Dec 04, 2010 at 12:09:22PM +, Reuben Thomas wrote:
> On 4 December 2010 11:07, Colin Watson wrote:
> > On Fri, Dec 03, 2010 at 08:15:23PM +, Reuben Thomas wrote:
> >> Is the spacing of the --help for --no-justification a joke? It
> >> backfires rather on terminals narrower than your implied column width
> >> (80?).
> >
> > Not particularly; can you show me an example of what you mean?
>
> I would expect these two lines:
>
> --no-hyphenation, --nh turn off hyphenation
> --no-justification, --nj turn off
> justification
>
> to look like this:
>
> --no-hyphenation, --nh turn off hyphenation
> --no-justification, --nj turn off justification
>
> --nj is the only option documented in that way: you'll notice that the
> line on which it is documented is justified by inserting extra spaces
> not only after the long option, but between "--nj" and "turn off
> justification".
Oh yes, I see what you mean now. I think this must be an argp bug. The
struct argp_option entries just look like this:
{ "no-hyphenation",
OPT_NO_HYPHENATION,0, 0,
N_("turn off hyphenation") },
{ "nh", 0, 0, OPTION_ALIAS },
{ "no-justification",
OPT_NO_JUSTIFICATION,0, 0,
N_("turn off justification") },
{ "nj", 0, 0, OPTION_ALIAS },
So I think argp-help's wrapping is buggy. I could look into that, but
it's a couple of thousand lines of code I don't know at all right now -
perhaps somebody on bug-gnulib can help?
> That it may not be a joke is suggested by some similar oddness in the
> documentation of -p, where there is an apparently unintended line
> break just before "g - grap" (from the formatting of the rest of the
> test, one would expect it afterwards, and then for "r - refer" to be
> indented up to the same column as the preceding line, which starts "e
> - [n]eqn".
That's a different issue. I deliberately inserted a \n there because I
didn't want to deal with line-wrapping in the middle of something that's
supposed to look like this:
-p, --preprocessor=STRING STRING indicates which preprocessors to run:
e - [n]eqn, p - pic, t - tbl,
g - grap, r - refer, v - vgrind
However, instead it comes out looking like this:
-p, --preprocessor=STRING STRING indicates which preprocessors to run:
e - [n]eqn, p - pic, t - tbl,
g - grap, r - refer, v - vgrind
Shouldn't argp put a sensible left margin after each newline?
Thanks,
--
Colin Watson [cjwat...@debian.org]
Re: return values of test programs in *.m4 macros
Hi Eric, > If the particular > combination of failures matches 63, 77, or 99 (as commonly used by > automake and autoconf to mean version mismatch, skip, or hard fail), > then the configure script might misbehave. In the generated configure scripts, AC_RUN_IFELSE tests for an exit code equal to 0 and nothing else. And this cannot change, because it's documented behaviour of AC_RUN_IFELSE: -- Macro: AC_RUN_IFELSE (INPUT, [ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-CROSS-COMPILING]) If PROGRAM compiles and links successfully and returns an exit status of 0 when executed, run shell commands ACTION-IF-TRUE. Otherwise, run shell commands ACTION-IF-FALSE. So, there is no problem now, and there cannot be a problem in the future. Bruno
