Hi/2.
Bruno Haible wrote:
> Hi,
>
> KO Myung-Hun wrote:
>> Check the functionality of a macro version wcwidth () as well as a
>> real function.
>>
>> This is better than undefining wcwidth on OS/2 kLIBC without functional
>> check.
>
> With your patch, does the following command sequence pass it
Paul Eggert wrote:
> Thanks, looks good to me.
OK, I've pushed it.
Zack Weinberg wrote:
> Sorry about that. glibc's default copyright headers refer to the
> library as a whole as being under the LGPL and it didn't occur to me
> to check whether the gnulib policy is different.
Sure, the handling
Sorry about that. glibc's default copyright headers refer to the
library as a whole as being under the LGPL and it didn't occur to me
to check whether the gnulib policy is different.
On Fri, Oct 6, 2017 at 2:30 PM, Paul Eggert wrote:
> Thanks, looks good to me.
Thanks, looks good to me.
The copyright headers of getopt*.h make it sound as if all of gnulib
were under LGPLv2+. But much of gnulib is under GPL. Here's a proposed
wording change.
2017-10-06 Bruno Haible
getopt-posix: Clarify copyright header.
* lib/getopt.in.h: Don't state that gnulib is under LGPL.
Daniel P. Berrange wrote:
> From my own F28 rawhide install with glibc-2.26.90-16.fc28.x86_64
>
> >
> > 1) The output of
> > $ nm test-getopt-posix | grep getopt
>
> $ nm test-getopt-posix | grep getopt
> U getopt@@GLIBC_2.2.5
> 00400ab0 t getopt_loop.constprop.0
On 10/06/2017 12:07 PM, Jim Meyering wrote:
> On Fri, Oct 6, 2017 at 7:47 AM, Eric Blake wrote:
>> On 10/05/2017 06:07 AM, Pino Toscano wrote:
>>> The majority of the syntax check is taylored for C sources, so some of
>>> the checks already cause false positives for non-C sources (and thus
>>> the
Hi,
KO Myung-Hun wrote:
> Check the functionality of a macro version wcwidth () as well as a
> real function.
>
> This is better than undefining wcwidth on OS/2 kLIBC without functional
> check.
With your patch, does the following command sequence pass its tests?
$ ./gnulib-tool --create-test
On Fri, Oct 6, 2017 at 1:35 AM, Reuben Thomas wrote:
> Currently, HACKING contains:
>
> * Push the NEWS-updating changes and the new tag:
>
> v=$(cat .prev-version)
> git push origin master tag v$v
>
> Is there some reason this can't or shouldn't be done at one of the release
> stages? Eit
On Fri, Oct 6, 2017 at 7:47 AM, Eric Blake wrote:
> On 10/05/2017 06:07 AM, Pino Toscano wrote:
>> The majority of the syntax check is taylored for C sources, so some of
>> the checks already cause false positives for non-C sources (and thus
>> there are exclusion regexps in place).
>>
>> Instead,
Check the functionality of a macro version wcwidth () as well as a
real function.
This is better than undefining wcwidth on OS/2 kLIBC without functional
check.
* lib/wchar.in.h: Revert commit caee51.
* m4/wcwidth.m4 (gl_cv_func_wcwidth_macro): Check if wcwidth () is a
macro.
---
lib/wchar.in.h
On 10/05/2017 06:07 AM, Pino Toscano wrote:
> The majority of the syntax check is taylored for C sources, so some of
> the checks already cause false positives for non-C sources (and thus
> there are exclusion regexps in place).
>
> Instead, just exclude more non-C files from all the checks:
> - p
Currently, HACKING contains:
* Push the NEWS-updating changes and the new tag:
v=$(cat .prev-version)
git push origin master tag v$v
Is there some reason this can't or shouldn't be done at one of the release
stages? Either in the release or the release-commit target?
(I noticed that thi
13 matches
Mail list logo
