2.29 freeze update: Last fortnight

2.29 freeze update: Last fortnight

[Siddhesh Poyarekar]

Hello folks,

We are into the last fortnight of the 2.29 freeze and as far as I can 
tell all blockers with the exception of the ChangeLog script and the 
strftime change have been dealt with.

How is the progress on the strftime change?  It would be nice to wrap it 
up this week so that we can declare a hard freeze for the last week.

As for the ChangeLog script, it need not adhere to the hard freeze given 
that the script is independent.  However we do need to agree on the way 
forward for it so that we can do away with the ChangeLog entries for 
2.30 development and see how it goes.

Anything else that needs attention?

Siddhesh

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

Hi Siddhesh,

15.01.2019 15:37 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> [...]
> How is the progress on the strftime change?  It would be nice to wrap it 
> up this week so that we can declare a hard freeze for the last week.

We need 2 things:

1. There are documentation changes which I hesitate to review because
   I think this should be done by a native English speaker (or anyone
   having equivalently perfect knowledge of English language).

2. I still don't understand why the newly added argument of
   __strftime_internal yr_spec is of the type "int *" rather than just
   "int".  Maybe it is correct and the reason is that I have not
   analyzed it carefully enough.  I'm sorry, I am unable to analyze
   it more carefully this week.

Also, the first patch of the series has already been pushed.

Question: do we need a separate bug report to fix the additional flags
being ignored (like "%-EY" and "%_EY") or does it fall in the same
general category "improve the width of %EY"?

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[Zack Weinberg]

On Tue, Jan 15, 2019 at 11:53 AM Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
> Hi Siddhesh,
>
> 15.01.2019 15:37 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> > [...]
> > How is the progress on the strftime change?  It would be nice to wrap it
> > up this week so that we can declare a hard freeze for the last week.
>
> We need 2 things:
>
> 1. There are documentation changes which I hesitate to review because
>    I think this should be done by a native English speaker (or anyone
>    having equivalently perfect knowledge of English language).

I can review them if you reply to this email with the archive URL(s)
of the most recent version(s) of the documentation patch(es).

> 2. I still don't understand why the newly added argument of
>    __strftime_internal yr_spec is of the type "int *" rather than just
>    "int".  Maybe it is correct and the reason is that I have not
>    analyzed it carefully enough.  I'm sorry, I am unable to analyze
>    it more carefully this week.

Unfortunately I don't know enough about the guts of strftime to help
with this part.

zw

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

15.01.2019 18:02 Zack Weinberg <zackw@panix.com> wrote:
> On Tue, Jan 15, 2019 at 11:53 AM Rafal Luzynski
> <digitalfreak@lingonborough.com> wrote:
> > [...]
> > 1. There are documentation changes which I hesitate to review because
> >    I think this should be done by a native English speaker (or anyone
> >    having equivalently perfect knowledge of English language).
> 
> I can review them if you reply to this email with the archive URL(s)
> of the most recent version(s) of the documentation patch(es).
> [...]

The most recent version is here:

https://sourceware.org/ml/libc-alpha/2019-01/msg00239.html

+ 2 followups.

See also my previous review which could have led to the current
version:

https://sourceware.org/ml/libc-alpha/2018-12/msg00999.html

> > 2. I still don't understand why the newly added argument of
> >    __strftime_internal yr_spec is of the type "int *" rather than just
> >    "int".  Maybe it is correct and the reason is that I have not
> >    analyzed it carefully enough.  I'm sorry, I am unable to analyze
> >    it more carefully this week.
> 
> Unfortunately I don't know enough about the guts of strftime to help
> with this part.

That's OK, if you review the documentation part your help will be huge
already.  I hope there are more people who are able to analyze this
part including myself (if I only have more time).

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[Paul Eggert]

On 1/15/19 9:16 AM, Rafal Luzynski wrote:
 > https://sourceware.org/ml/libc-alpha/2019-01/msg00239.html

I took a look at those. Some comments:

 >+ For %Ey conversion specifier, the default action is now
 >+ to pad the number with zero to keep minimum 2 digits, similar to %y.

Change to:

The default for %Ey is now to zero-pad to two digits, like %y.


 >+The default action is to pad the number with zero to keep minimum 2
 >+digits, similar to @code{%y}.

Change to:

By default this is zero-padded to two digits, like @code{%y}.

 >  For %Ey conversion specifier, the default action is now
 >  to pad the number with zero to keep minimum 2 digits, similar to %y.
 >+ Also, the optional flag (either _ or -) can be used for %EY, so that
 >+ the internal %Ey is interpreted as if decorated with the appropriate
 >+ flag.

Change to:

For the %Ey conversion specifier, the default action is now to zero-pad 
the number to two digits, like %y.  Also, the optional flag (either _ or 
-) now affects the formatted year, like %EY.


 > static size_t __strftime_internal (CHAR_T *, size_t, const CHAR_T *,
 >-                   const struct tm *, bool *
 >+                   const struct tm *, int *, bool *
 >                    ut_argument_spec
 >                    LOCALE_PARAM) __THROW;

I also am puzzled as to why the new argument is int * rather than plain 
int. Why not make it plain int and simplify the rest of the code 
accordingly?

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

15.01.2019 18:49 Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 1/15/19 9:16 AM, Rafal Luzynski wrote:
>  > https://sourceware.org/ml/libc-alpha/2019-01/msg00239.html
> 
> I took a look at those. Some comments:

Thank you, Paul.

Tamuki Shoichi, please prepare a new version with these remarks
applied.

> [...]
>  >  For %Ey conversion specifier, the default action is now
>  >  to pad the number with zero to keep minimum 2 digits, similar to %y.
>  >+ Also, the optional flag (either _ or -) can be used for %EY, so that
>  >+ the internal %Ey is interpreted as if decorated with the appropriate
>  >+ flag.
> 
> Change to:
> 
> For the %Ey conversion specifier, the default action is now to zero-pad 
> the number to two digits, like %y.  Also, the optional flag (either _ or 
> -) now affects the formatted year, like %EY.

Shouldn't the flags be quoted, like "_" and "-"?  Also, it seems to me that
a line starting with a plain minus sign does not look good.

>  > static size_t __strftime_internal (CHAR_T *, size_t, const CHAR_T *,
>  >-                   const struct tm *, bool *
>  >+                   const struct tm *, int *, bool *
>  >                    ut_argument_spec
>  >                    LOCALE_PARAM) __THROW;
> 
> I also am puzzled as to why the new argument is int * rather than plain 
> int. Why not make it plain int and simplify the rest of the code 
> accordingly?

I guess this is a kind of optimization: if yr_spec is calculated in the
first pass (calculating the width of the output) then there is no need
to calculate it on the second pass.  But I am not sure we want to
sacrifice the simplicity and nice design of the code.

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[Paul Eggert]

On 1/15/19 10:16 AM, Rafal Luzynski wrote:
> Shouldn't the flags be quoted, like "_" and "-"?  Also, it seems to me that
> a line starting with a plain minus sign does not look good.

Yes, quoting sounds right.

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

15.01.2019 19:22 Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 1/15/19 10:16 AM, Rafal Luzynski wrote:
> > Shouldn't the flags be quoted, like "_" and "-"?  Also, it seems to me
> > that
> > a line starting with a plain minus sign does not look good.
> 
> Yes, quoting sounds right.

Thank you.

Paul, Zack, please take a look if I was right to say that
"alternate" is incorrect and should be "alternative" instead. [1]
Now I am not sure about it, it seems that the word "alternate" had
been used before.  See also the current patch where Tamuki Shoichi
changes all occurrences of "alternate" with "alternative". [2]

Also please look if this sentence can be improved:

+If the @code{E} modifier is specified (@code{%EC}), the locale's
+alternative representation for year (the era name) is used instead.
[3]

My point is that since "%C" is a century number (hm... actually, the
previous century number) then mentioning a year here is not correct.

Regards,

Rafal


[1] https://sourceware.org/ml/libc-alpha/2018-12/msg00999.html
[2] https://sourceware.org/ml/libc-alpha/2019-01/msg00240.html
[3] https://sourceware.org/ml/libc-alpha/2019-01/msg00241.html

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/15/19 11:52 AM, Rafal Luzynski wrote:
> Hi Siddhesh,
> 
> 15.01.2019 15:37 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> [...]
>> How is the progress on the strftime change?  It would be nice to wrap it 
>> up this week so that we can declare a hard freeze for the last week.
> 
> We need 2 things:
> 
> 1. There are documentation changes which I hesitate to review because
>    I think this should be done by a native English speaker (or anyone
>    having equivalently perfect knowledge of English language).
> 
> 2. I still don't understand why the newly added argument of
>    __strftime_internal yr_spec is of the type "int *" rather than just
>    "int".  Maybe it is correct and the reason is that I have not
>    analyzed it carefully enough.  I'm sorry, I am unable to analyze
>    it more carefully this week.
> 
> Also, the first patch of the series has already been pushed.
> 
> Question: do we need a separate bug report to fix the additional flags
> being ignored (like "%-EY" and "%_EY") or does it fall in the same
> general category "improve the width of %EY"?

Please file a new bug for this. This is a distinct issue.

-- 
Cheers,
Carlos.

Re: 2.29 freeze update: Last fortnight

[TAMUKI Shoichi]

Hello Carlos,

From: Carlos O'Donell <carlos@redhat.com>
To: Rafal Luzynski <digitalfreak@lingonborough.com>,
	Siddhesh Poyarekar <siddhesh@gotplt.org>,
	GLIBC Devel <libc-alpha@sourceware.org>
Cc: Joseph Myers <joseph@codesourcery.com>
Subject: Re: 2.29 freeze update: Last fortnight
Date: Tue, 15 Jan 2019 12:09:03 -0500

> > Question: do we need a separate bug report to fix the additional flags
> > being ignored (like "%-EY" and "%_EY") or does it fall in the same
> > general category "improve the width of %EY"?
> 
> Please file a new bug for this. This is a distinct issue.

I have created a new Bugzilla report for this.

https://sourceware.org/bugzilla/show_bug.cgi?id=24096

Regards,
TAMUKI Shoichi

Re: 2.29 freeze update: Last fortnight

[TAMUKI Shoichi]

Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: 2.29 freeze update: Last fortnight
Date: Tue, 15 Jan 2019 17:52:58 +0100 (CET)

> 2. I still don't understand why the newly added argument of
>    __strftime_internal yr_spec is of the type "int *" rather than just
>    "int".  Maybe it is correct and the reason is that I have not
>    analyzed it carefully enough.  I'm sorry, I am unable to analyze
>    it more carefully this week.

The yr_spec variable is initially definded in my_strftime function,
and __strftime_internal function is called there.

The __strftime_internal function is a recursive structure that calls
itself in subformat: label within the function.  The subformat: label
is used in the processing of %Ex, %D, %F, %R, %r, %EX, %T, and %EY.

The value of the yr_spec variable is updated while walking around
these functions, and it needs to be treated as if it were a global
variable.  If it is called by value, the value is not retained.
Therefore, it is called by address.

In additon, since tzset_called variable used in %Z and %z processing
also needs to be treated as if it were a global variable in the same
way as above, call by address is used.

Regards,
TAMUKI Shoichi

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

17.01.2019 07:29 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> 
> Hello Rafal,
> 
> From: Rafal Luzynski <digitalfreak@lingonborough.com>
> Subject: Re: 2.29 freeze update: Last fortnight
> Date: Tue, 15 Jan 2019 17:52:58 +0100 (CET)
> 
> > 2. I still don't understand why the newly added argument of
> >    __strftime_internal yr_spec is of the type "int *" rather than just
> >    "int".  Maybe it is correct and the reason is that I have not
> >    analyzed it carefully enough.  I'm sorry, I am unable to analyze
> >    it more carefully this week.
> 
> The yr_spec variable is initially definded in my_strftime function,
> and __strftime_internal function is called there.
> 
> The __strftime_internal function is a recursive structure that calls
> itself in subformat: label within the function.  The subformat: label
> is used in the processing of %Ex, %D, %F, %R, %r, %EX, %T, and %EY.
> 
> The value of the yr_spec variable is updated while walking around
> these functions, and it needs to be treated as if it were a global
> variable.  If it is called by value, the value is not retained.
> Therefore, it is called by address.

I understand how it works but I don't understand why you need this.

Passing a variable by the pointer suggests that it is an input/output
argument (or maybe even only output).  Do you use the value of yr_spec
as an additional result of __strftime_internal?  I can't see any
occurrence of yr_spec being read by the caller.

In other words: what would happen if yr_spec was just int?

> In additon, since tzset_called variable used in %Z and %z processing
> also needs to be treated as if it were a global variable in the same
> way as above, call by address is used.

I can see that tzset_called ensures that tzset() is called only once:
if it was called by the first recursive call of __strftime_internal
then it is not called by the second call.  I can't see any other
similar one-time operation ensured by yr_spec.

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[TAMUKI Shoichi]

Hello Rafal,

From: Rafal Luzynski <digitalfreak@lingonborough.com>
Subject: Re: 2.29 freeze update: Last fortnight
Date: Thu, 17 Jan 2019 21:32:23 +0100 (CET)

> Passing a variable by the pointer suggests that it is an input/output
> argument (or maybe even only output).  Do you use the value of yr_spec
> as an additional result of __strftime_internal?  I can't see any
> occurrence of yr_spec being read by the caller.

I checked carefully and confirmed that using yr_spec as a simple int
is no problem.  In addition, I also found that "yr_spec = 0" after
__strftime_internal function call is unnecessary.  Based on this, I
will fix the next patch.

Regards,
TAMUKI Shoichi

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

18.01.2019 14:58 TAMUKI Shoichi <tamuki@linet.gr.jp> wrote:
> [...]
> I checked carefully and confirmed that using yr_spec as a simple int
> is no problem.  In addition, I also found that "yr_spec = 0" after
> __strftime_internal function call is unnecessary.  Based on this, I
> will fix the next patch.

Yes, please prepare the next patch with that change.  It will be less
confusing, easier to understand and maintain, and less error prone.
Thank you.

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[Jochen Hein]

Siddhesh Poyarekar <siddhesh@gotplt.org> writes:

> Anything else that needs attention?

Can you prepare the updated pot-file for us translators? That would
leave us enough time for the updates. If there are more changes to
strings we can just update these in a second round.

Jochen

-- 
This space is intentionally left blank.

Re: 2.29 freeze update: Last fortnight

[Siddhesh Poyarekar]

On 16/01/19 1:39 AM, Jochen Hein wrote:
> Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
> 
>> Anything else that needs attention?
> 
> Can you prepare the updated pot-file for us translators? That would
> leave us enough time for the updates. If there are more changes to
> strings we can just update these in a second round.

Sorry for the delay, I've been telling myself every evening for the last 
week that I'll send the pot-file the next day and never got to doing it :/

I'm definitely doing this today.

Siddhesh

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/15/19 9:37 AM, Siddhesh Poyarekar wrote:
> Hello folks,
> 
> We are into the last fortnight of the 2.29 freeze and as far as I can
> tell all blockers with the exception of the ChangeLog script and the
> strftime change have been dealt with.
> 
> How is the progress on the strftime change?  It would be nice to wrap
> it up this week so that we can declare a hard freeze for the last
> week.
> 
> As for the ChangeLog script, it need not adhere to the hard freeze
> given that the script is independent.  However we do need to agree on
> the way forward for it so that we can do away with the ChangeLog
> entries for 2.30 development and see how it goes.
> 
> Anything else that needs attention?

I'm working at trying to fix the rwlock bug. I'd like to see the bug
fix included in the release. I think I need the rest of the week to
fix this. However, we can push out to 2.30 if we want.

-- 
Cheers,
Carlos.

Re: 2.29 freeze update: Last fortnight

[Siddhesh Poyarekar]

On 16/01/19 1:47 AM, Carlos O'Donell wrote:
> I'm working at trying to fix the rwlock bug. I'd like to see the bug
> fix included in the release. I think I need the rest of the week to
> fix this. However, we can push out to 2.30 if we want.

We can hold off till 23rd for the hard freeze; would that be enough time 
for you?  That gives me enough time to run tests over the weekend and do 
the release the following week.

That should also give HJ enough time to fix the x32 bug he just found.

Siddhesh

Re: 2.29 freeze update: Last fortnight

[Siddhesh Poyarekar]

On 16/01/19 9:17 AM, Siddhesh Poyarekar wrote:
> On 16/01/19 1:47 AM, Carlos O'Donell wrote:
>> I'm working at trying to fix the rwlock bug. I'd like to see the bug
>> fix included in the release. I think I need the rest of the week to
>> fix this. However, we can push out to 2.30 if we want.
> 
> We can hold off till 23rd for the hard freeze; would that be enough time
> for you?  That gives me enough time to run tests over the weekend and do
> the release the following week.
> 
> That should also give HJ enough time to fix the x32 bug he just found.

Carlos, HJ, are we doing OK for time?  Would you be OK for a hard freeze
by the end of this week, i.e. Sunday?  That will give me all of next
week to run final tests for the release.

How's the strftime change doing?  It looks like y'all are on the last
couple of patches now.

As for the ChangeLog script, I've worked on incorporating it into gnulib
and am targeting end of my day tomorrow to post a patch for review on
the gnulib ML.  I believe we are on target for dropping the ChangeLog
requirement for 2.30 development, so I'll be requesting review of wiki
changes next week indicating the change in workflow.

Siddhesh

Re: 2.29 freeze update: Last fortnight

[H.J. Lu]

On Mon, Jan 21, 2019 at 7:28 PM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> On 16/01/19 9:17 AM, Siddhesh Poyarekar wrote:
> > On 16/01/19 1:47 AM, Carlos O'Donell wrote:
> >> I'm working at trying to fix the rwlock bug. I'd like to see the bug
> >> fix included in the release. I think I need the rest of the week to
> >> fix this. However, we can push out to 2.30 if we want.
> >
> > We can hold off till 23rd for the hard freeze; would that be enough time
> > for you?  That gives me enough time to run tests over the weekend and do
> > the release the following week.
> >
> > That should also give HJ enough time to fix the x32 bug he just found.
>
> Carlos, HJ, are we doing OK for time?  Would you be OK for a hard freeze
> by the end of this week, i.e. Sunday?  That will give me all of next
> week to run final tests for the release.

I have checked in my fixes now.   For some reason,

https://sourceware.org/bugzilla/show_bug.cgi?id=24097

isn't updated with my commits.

Thanks.


-- 
H.J.

Re: 2.29 freeze update: Last fortnight

[Joseph Myers]

On Mon, 21 Jan 2019, H.J. Lu wrote:

> I have checked in my fixes now.   For some reason,
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=24097
> 
> isn't updated with my commits.

There has to be a space after "BZ" (or "PR" or "bug") for a reference to a 
bug to result in Bugzilla being updated.  Since those commits had "BZ# " 
instead of "BZ #", it wasn't detected as a bug reference.  (See 
/sourceware/infra/bin/email-to-bugzilla.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/21/19 10:28 PM, Siddhesh Poyarekar wrote:
> On 16/01/19 9:17 AM, Siddhesh Poyarekar wrote:
>> On 16/01/19 1:47 AM, Carlos O'Donell wrote:
>>> I'm working at trying to fix the rwlock bug. I'd like to see the bug
>>> fix included in the release. I think I need the rest of the week to
>>> fix this. However, we can push out to 2.30 if we want.
>>
>> We can hold off till 23rd for the hard freeze; would that be enough time
>> for you?  That gives me enough time to run tests over the weekend and do
>> the release the following week.
>>
>> That should also give HJ enough time to fix the x32 bug he just found.
> 
> Carlos, HJ, are we doing OK for time?  Would you be OK for a hard freeze
> by the end of this week, i.e. Sunday?  That will give me all of next
> week to run final tests for the release.
> 
> How's the strftime change doing?  It looks like y'all are on the last
> couple of patches now.
> 
> As for the ChangeLog script, I've worked on incorporating it into gnulib
> and am targeting end of my day tomorrow to post a patch for review on
> the gnulib ML.  I believe we are on target for dropping the ChangeLog
> requirement for 2.30 development, so I'll be requesting review of wiki
> changes next week indicating the change in workflow.

I just posed the complete rwlock fix with regression tests:
https://www.sourceware.org/ml/libc-alpha/2019-01/msg00557.html

Analysis with execution ordering showing failures:
https://sourceware.org/bugzilla/show_bug.cgi?id=23844#c14

I don't expect anyone to give substantive review. Torvald was the
expert, and he mostly wrote the patch with input from Rik Prohaska.
I basically did the review, and created the test cases from my own
review, and carried out testing on x86_64 to determine how fast the
stall can be triggered (to set test timeouts and sleeps). Reviewing
this requires a complete understanding of the new rwlock algorithm.
However, at this point it is much better than the stalls we have and
so it should go in ASAP.

I expect to commit the fix as soon as Torvald and Rik let me use
their Signed-off-by.

-- 
Cheers,
Carlos.

Re: 2.29 freeze update: Last fortnight

[Florian Weimer]

* Carlos O'Donell:

> I expect to commit the fix as soon as Torvald and Rik let me use
> their Signed-off-by.

“Signed-off-by” probably isn't the right term to use in this context.
What exactly do you mean?

Thanks,
Florian

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/22/19 7:00 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> I expect to commit the fix as soon as Torvald and Rik let me use
>> their Signed-off-by.
> 
> “Signed-off-by” probably isn't the right term to use in this context.
> What exactly do you mean?

Both Torvald nad Rik worked on the patch with me.

I can't use their 'Signed-off-by' without them authorizing
it based on the final version.

So I am asking them for it so I can record their work on the patch
with me.

What else would I use?

-- 
Cheers,
Carlos.

Re: 2.29 freeze update: Last fortnight

[Szabolcs Nagy]

On 22/01/2019 13:06, Carlos O'Donell wrote:
> On 1/22/19 7:00 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>> I expect to commit the fix as soon as Torvald and Rik let me use
>>> their Signed-off-by.
>>
>> “Signed-off-by” probably isn't the right term to use in this context.
>> What exactly do you mean?
> 
> Both Torvald nad Rik worked on the patch with me.
> 
> I can't use their 'Signed-off-by' without them authorizing
> it based on the final version.
> 
> So I am asking them for it so I can record their work on the patch
> with me.
> 
> What else would I use?

this was mentioned earlier in the ChangeLog discussion:

https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gitlog-to-changelog

(see SPECIAL SYNTAX part: it uses Co-authored-by:)

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/22/19 8:11 AM, Szabolcs Nagy wrote:
> On 22/01/2019 13:06, Carlos O'Donell wrote:
>> On 1/22/19 7:00 AM, Florian Weimer wrote:
>>> * Carlos O'Donell:
>>>
>>>> I expect to commit the fix as soon as Torvald and Rik let me use
>>>> their Signed-off-by.
>>>
>>> “Signed-off-by” probably isn't the right term to use in this context.
>>> What exactly do you mean?
>>
>> Both Torvald nad Rik worked on the patch with me.
>>
>> I can't use their 'Signed-off-by' without them authorizing
>> it based on the final version.
>>
>> So I am asking them for it so I can record their work on the patch
>> with me.
>>
>> What else would I use?
> 
> this was mentioned earlier in the ChangeLog discussion:
> 
> https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gitlog-to-changelog
> 
> (see SPECIAL SYNTAX part: it uses Co-authored-by:)
 
That is *in addition* to Signed-off-by: which is just ignored?

I can still request the authors provide their same kernel-like
sign-off, like I provide my Reviewed-by: to track how many things
I've reviewed (which I think is also important for the community
to acknowledge).

I agree that in the fully-automated future I will need Co-authored-by:
syntax.

-- 
Cheers,
Carlos.

Re: 2.29 freeze update: Last fortnight

[Siddhesh Poyarekar]

We're digressing, but y'all started it so... ;)

On 22/01/19 6:53 PM, Carlos O'Donell wrote:
>> this was mentioned earlier in the ChangeLog discussion:
>>
>> https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gitlog-to-changelog
>>
>> (see SPECIAL SYNTAX part: it uses Co-authored-by:)
>  
> That is *in addition* to Signed-off-by: which is just ignored?
> 
> I can still request the authors provide their same kernel-like
> sign-off, like I provide my Reviewed-by: to track how many things
> I've reviewed (which I think is also important for the community
> to acknowledge).
> 
> I agree that in the fully-automated future I will need Co-authored-by:
> syntax.

The context of that comment is that Signed-off-by has a specific
meaning, i.e. a DCO.  Using it in the glibc context may be confusing
because we have copyright assigment in place.

I had also thought that using DCO in the glibc context would be
overloading its meaning but after thinking about it for a while, it
shouldn't and both ought to be able to coexist.  Of course, IANAL, etc.

Siddhesh

Re: 2.29 freeze update: Last fortnight

[Carlos O'Donell]

On 1/22/19 10:17 AM, Siddhesh Poyarekar wrote:
> We're digressing, but y'all started it so... ;)
> 
> On 22/01/19 6:53 PM, Carlos O'Donell wrote:
>>> this was mentioned earlier in the ChangeLog discussion:
>>>
>>> https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gitlog-to-changelog
>>>
>>> (see SPECIAL SYNTAX part: it uses Co-authored-by:)
>>  
>> That is *in addition* to Signed-off-by: which is just ignored?
>>
>> I can still request the authors provide their same kernel-like
>> sign-off, like I provide my Reviewed-by: to track how many things
>> I've reviewed (which I think is also important for the community
>> to acknowledge).
>>
>> I agree that in the fully-automated future I will need Co-authored-by:
>> syntax.
> 
> The context of that comment is that Signed-off-by has a specific
> meaning, i.e. a DCO.  Using it in the glibc context may be confusing
> because we have copyright assigment in place.
> 
> I had also thought that using DCO in the glibc context would be
> overloading its meaning but after thinking about it for a while, it
> shouldn't and both ought to be able to coexist.  Of course, IANAL, etc.

In glibc I expect that unofficially all of our process is equivalent to
a DCO *plus* copyright assignment, but we don't verbalize our DCO that way.

The reason I prefer DCO is that it's easier to explain:

* DCO + copyright assignment.

Than to explain something entirely new. A lot of other communities are simply
adopting the kernel DCO because it's well known, and there is a lot of value
in that.

My opinion is that a Co-authored-by: should be equivalent to multiple
Signed-off-by: lines e.g. treat Co-authored-by: as an alias to Signed-off-by:,
but those projects not wishing to use the implied DCO can use Co-authroed-by.

We should probably move this off this thread.

-- 
Cheers,
Carlos.

DCO or Copyright Assignment? Why not both...

[Siddhesh Poyarekar]

On 22/01/19 9:18 PM, Carlos O'Donell wrote:
> In glibc I expect that unofficially all of our process is equivalent to
> a DCO *plus* copyright assignment, but we don't verbalize our DCO that way.
>   
> The reason I prefer DCO is that it's easier to explain:
>   
> * DCO + copyright assignment.
>   
> Than to explain something entirely new. A lot of other communities are simply
> adopting the kernel DCO because it's well known, and there is a lot of value
> in that.

Yeah that's basically what I meant to suggest but I'm not a 100% sure it
is unambiguous.

> My opinion is that a Co-authored-by: should be equivalent to multiple
> Signed-off-by: lines e.g. treat Co-authored-by: as an alias to Signed-off-by:,
> but those projects not wishing to use the implied DCO can use Co-authroed-by.
>   
> We should probably move this off this thread.

Done, subject line changed.

Siddhesh

Re: DCO or Copyright Assignment? Why not both...

[Florian Weimer]

* Siddhesh Poyarekar:

>> My opinion is that a Co-authored-by: should be equivalent to multiple
>> Signed-off-by: lines e.g. treat Co-authored-by: as an alias to
>> Signed-off-by:, but those projects not wishing to use the implied DCO
>> can use Co-authroed-by.
>>   
>> We should probably move this off this thread.
>
> Done, subject line changed.

The FSF needs to be involved.  Typical contributor agreements (with our
without copyright assignment) offer some guidance what contributes a
contribution.  For example, it's common to say that everything that the
contributor submits to the project using project resources is a
contribution unless marked with “NOT A CONTRIBUTION”.  We cannot know
what FSF assignment contracts say on this matter, which is why we need
input from the FSF.

In the past, there was considerable confusion among GNU maintainers what
constitutes a contribution.  For example, some maintainers assumed that
they could talk a patch which was posted by some person with the same
name and assume that copyright had been assigned for it if the file on
fencepost lists a person of that name.  I do not know if this has been
improved, by teaching GNU maintainers about the complexities of software
copyright and authorship.

Thanks,
Florian

Re: 2.29 freeze update: Last fortnight

[Rafal Luzynski]

22.01.2019 04:28 Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
> [...]
> How's the strftime change doing?  It looks like y'all are on the last
> couple of patches now.

That's true.  Also, I will appreciate some feedback from other
more experienced maintainers.  I am a maintainer for locale data
only while the change is for time formatting subsystem therefore
I would not like to act as the only maintainer here.

Today's series of patches from Tamuki Shoichi is probably 100%
correct but I did not yet have time to review it thoroughly.

Regards,

Rafal

Re: 2.29 freeze update: Last fortnight

[H.J. Lu]

On Tue, Jan 15, 2019 at 6:37 AM Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>
> Hello folks,
>
> We are into the last fortnight of the 2.29 freeze and as far as I can
> tell all blockers with the exception of the ChangeLog script and the
> strftime change have been dealt with.
>
> How is the progress on the strftime change?  It would be nice to wrap it
> up this week so that we can declare a hard freeze for the last week.
>
> As for the ChangeLog script, it need not adhere to the hard freeze given
> that the script is independent.  However we do need to agree on the way
> forward for it so that we can do away with the ChangeLog entries for
> 2.30 development and see how it goes.
>
> Anything else that needs attention?
>

I found an x32 bug.  But I couldn't open glibc bug.   I just reported
it here for
record:

On x32, size_t is 32 bit.  We must not use 64-bit register for size_t in
assembly codes for x32:

[hjl@gnu-cfl-1 size-1]$ cat tst-size_t-1.c
#include <string.h>
#include <stdlib.h>
#include <sys/mman.h>

struct foo
{
  size_t len;
  void *p;
};

static void
__attribute__ ((noinline, noclone))
func (struct foo a, struct foo b)
{
  memcpy (a.p, b.p, a.len);
}

int
main (void)
{
  char bufb[20] = "foo";
  struct foo b = { sizeof (bufb), bufb };
  char *bufa = (char*)mmap(NULL, 0x1000,
   PROT_WRITE|PROT_READ,
   MAP_PRIVATE | MAP_ANONYMOUS,
   -1, 0);
  struct foo a = { 0x1000, bufa };
  func (a, b);
  if (memcmp (bufa, bufb, sizeof (bufa)))
    abort ();
  return 0;
}
[hjl@gnu-cfl-1 size-1]$ make tst-size_t-1-dynamic
gcc -mx32 -g -O2   -c -o tst-size_t-1.o tst-size_t-1.c
gcc -mx32 -L. -nostdlib -nostartfiles -o tst-size_t-1-dynamic \
-Wl,-dynamic-linker=/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/elf/ld-linux-x32.so.2
\
-Wl,-z,nocombreloc \
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/csu/crt1.o
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/csu/crti.o
\
`gcc -mx32 --print-file-name=crtbegin.o` \
tst-size_t-1.o \
-Wl,-rpath=/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux:/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/nptl:/usr/lib/gcc/x86_64-redhat-linux/8/../../../../libx32:.
\
  \
 \
 \
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/libc.so.6 \
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/elf/ld-linux-x32.so.2
\
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/libc_nonshared.a \
-Wl,-as-needed /usr/lib/gcc/x86_64-redhat-linux/8/x32/libgcc_s.so
-Wl,--no-as-needed `gcc -mx32 --print-file-name=crtend.o` \
/export/build/gnu/tools-build/glibc-x32/build-x86_64-linux/csu/crtn.o
[hjl@gnu-cfl-1 size-1]$ gdb tst-size_t-1-dynamic
GNU gdb (GDB) Fedora 8.2-6.fc29
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tst-size_t-1-dynamic...done.
(gdb) b func
Breakpoint 1 at 0x4011c0: file tst-size_t-1.c, line 15.
(gdb) r
Breakpoint 1, func (a=..., b=b@entry=...) at tst-size_t-1.c:15
15   memcpy (a.p, b.p, a.len);
(gdb) step
__memmove_avx_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:222
222 movq %rdi, %rax
(gdb) p/x $rdx
$1 = 0xf7e1f00000001000
(gdb) f 1
#1  0x004010cb in main () at tst-size_t-1.c:28
28   func (a, b);
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:376
376 VMOVU -VEC_SIZE(%rsi, %rdx), %VEC(5)
(gdb)

-- 
H.J.