[NIT] error: %changelog not in descending chronological order

[Paul Bolle]

Hi Justin,

Nobody noticed, so this is just a nit, but ever since the v5.8.14 build for
fc32 there's this in the fc32 build logs:
     error: %changelog not in descending chronological order

I think what triggers this is that you've recently added extended the
datestamp on your changelog entries with timestamps. Eg:
    * Wed Oct  7 07:21:23 CDT 2020 Justin M. Forbes <jforbes(a)fedoraproject.org&gt; -
5.8.14-200

But if the preceding changelog entry doesn't have a timestamp, like:
    * Wed Oct  7 2020 Peter Robinson <pbrobinson(a)fedoraproject.org&gt;

rpmbuild spits out an "error:" but merrily continues the build! (I have no
idea how that works. Both the timestamp comparison and the build ignoring an
error.)

Do people care enough to try to fix this?

Thanks,


Paul Bolle

[Justin Forbes]

On Mon, Dec 28, 2020 at 12:10 PM Paul Bolle <pebolle(a)tiscali.nl&gt; wrote:
>  Hi Justin,
>
>  Nobody noticed, so this is just a nit, but ever since the v5.8.14 build for
>  fc32 there's this in the fc32 build logs:
>       error: %changelog not in descending chronological order
>
>  I think what triggers this is that you've recently added extended the
>  datestamp on your changelog entries with timestamps. Eg:
>      * Wed Oct  7 07:21:23 CDT 2020 Justin M. Forbes <jforbes(a)fedoraproject.org&gt; -
> 5.8.14-200 
Yes, this is what triggers it, and it is added by a change in
rpmdev-bumpspec in F33.   I was kind of hoping that rpm would also be
changed to ignore this, so I have not done anything about it.  I
suppose I could look into it, but it is just noise at the moment.

>  But if the preceding changelog entry doesn't have a timestamp, like:
>      * Wed Oct  7 2020 Peter Robinson <pbrobinson(a)fedoraproject.org&gt;
>
>  rpmbuild spits out an "error:" but merrily continues the build! (I have no
>  idea how that works. Both the timestamp comparison and the build ignoring an
>  error.)
>
>  Do people care enough to try to fix this? 
With the cause coming from a change in rpmdev-bumpspec, I am guessing
that kernel is not the only package to notice it, though we do use
scripts calling it more than most I suppose.  I may look into it, but
from a tooling standpoint, we will likely end up changing a lot of
scripts, so it is fairly low priority at the moment.

Justin

[Peter Robinson]

On Mon, Dec 28, 2020 at 6:58 PM Justin Forbes <jforbes(a)fedoraproject.org&gt; wrote:
>  On Mon, Dec 28, 2020 at 12:10 PM Paul Bolle <pebolle(a)tiscali.nl&gt; wrote:
>  >
>  > Hi Justin,
>  >
>  > Nobody noticed, so this is just a nit, but ever since the v5.8.14 build for
>  > fc32 there's this in the fc32 build logs:
>  >      error: %changelog not in descending chronological order
>  >
>  > I think what triggers this is that you've recently added extended the
>  > datestamp on your changelog entries with timestamps. Eg:
>  >     * Wed Oct  7 07:21:23 CDT 2020 Justin M. Forbes
> <jforbes(a)fedoraproject.org&gt; - 5.8.14-200
>
>  Yes, this is what triggers it, and it is added by a change in
>  rpmdev-bumpspec in F33.   I was kind of hoping that rpm would also be
>  changed to ignore this, so I have not done anything about it.  I
>  suppose I could look into it, but it is just noise at the moment.
>
>  >
>  > But if the preceding changelog entry doesn't have a timestamp, like:
>  >     * Wed Oct  7 2020 Peter Robinson <pbrobinson(a)fedoraproject.org&gt;
>  >
>  > rpmbuild spits out an "error:" but merrily continues the build! (I have
> no
>  > idea how that works. Both the timestamp comparison and the build ignoring an
>  > error.)
>  >
>  > Do people care enough to try to fix this?
>
>  With the cause coming from a change in rpmdev-bumpspec, I am guessing
>  that kernel is not the only package to notice it, though we do use
>  scripts calling it more than most I suppose.  I may look into it, but
>  from a tooling standpoint, we will likely end up changing a lot of
>  scripts, so it is fairly low priority at the moment. 
The change is due to be reverted to the old date method, details in
https://pagure.io/rpmdevtools/issue/63