Bug 2085882 - config.sub is too old
Summary: config.sub is too old
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: automake
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Frédéric Bérat
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-13 18:19 UTC by fedora
Modified: 2022-06-16 01:20 UTC (History)
9 users (show)

Fixed In Version: automake-1.16.5-7.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-16 01:20:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description fedora 2022-05-13 18:19:16 UTC
Description of problem:
The config.sub packaged with automake is too old.


Version-Release number of selected component (if applicable):

I have a recent automake:
$ sudo LC_ALL=C dnf info automake
Version      : 1.16.5
Release      : 4.fc36
Architecture : noarch
Size         : 1.7 M
Source       : automake-1.16.5-4.fc36.src.rpm



Steps to Reproduce:
$ grep timestamp /usr/share/automake-1.16/config.sub
timestamp='2016-09-05'


Actual results:
 On Fedora 36 I get:
 timestamp='2016-09-05'


Expected results:
 The config.sub packaged with upstream automake-1.16.5 is much newer:
$ grep timestamp ./automake-1.16.5/lib/config.sub 
timestamp='2021-08-14'

Comment 1 Frédéric Bérat 2022-05-16 16:54:43 UTC
Investigation shows that the problem doesn't come directly from the automake package itself.

Although the spec file pulls a newer version (yet still outdated) of the config.guess and config.sub files, they are overwritten by the one provided by redhat-rpm-config during the build.

I'll therefore investigate to remove the change done in the spec file to pull an outdated version of these files (which seems to be useless nowadays), and check to upgrade the one in redhat-rpm-config.

Comment 2 Pavel Raiskup 2022-05-17 06:39:16 UTC
(In reply to Frédéric Bérat from comment #1)
> Investigation shows that the problem doesn't come directly from the automake
> package itself.
> 
> Although the spec file pulls a newer version (yet still outdated) of the
> config.guess and config.sub files, they are overwritten by the one provided
> by redhat-rpm-config during the build.

This is correct behavior.  The redhat-rpm-config maintainers take care
of those files, and take the responsibility for providing new enough files
for _build RPMs_.

> I'll therefore investigate to remove the change done in the spec file to
> pull an outdated version of these files (which seems to be useless
> nowadays), and check to upgrade the one in redhat-rpm-config.

The automake package should contain the latest-greatest upstream versions
of the config.sub/config.guess files.  This is because those files are
automatically re-distributed in tarballs generated by upstreams (the
normal way of 'make dist' releasing).  For upgrading, there's the
`./sync_gnuconfig.sh` script:
https://src.fedoraproject.org/rpms/automake/blob/3e8430b36dc15567e3de43a8781c39d87744884e/f/sync_gnuconfig.sh

Comment 3 Frédéric Bérat 2022-05-17 07:33:16 UTC
(In reply to Pavel Raiskup from comment #2)
> (In reply to Frédéric Bérat from comment #1)
> > Investigation shows that the problem doesn't come directly from the automake
> > package itself.
> > 
> > Although the spec file pulls a newer version (yet still outdated) of the
> > config.guess and config.sub files, they are overwritten by the one provided
> > by redhat-rpm-config during the build.
> 
> This is correct behavior.  The redhat-rpm-config maintainers take care
> of those files, and take the responsibility for providing new enough files
> for _build RPMs_.
> 

It likely is the correct behavior, but the file that is provided by redhat-rpm-config is from 2016.

> > I'll therefore investigate to remove the change done in the spec file to
> > pull an outdated version of these files (which seems to be useless
> > nowadays), and check to upgrade the one in redhat-rpm-config.
> 
> The automake package should contain the latest-greatest upstream versions
> of the config.sub/config.guess files.  This is because those files are
> automatically re-distributed in tarballs generated by upstreams (the
> normal way of 'make dist' releasing).  For upgrading, there's the
> `./sync_gnuconfig.sh` script:
> https://src.fedoraproject.org/rpms/automake/blob/
> 3e8430b36dc15567e3de43a8781c39d87744884e/f/sync_gnuconfig.sh

That is currently useless, because the redhat-rpm-config replaces the file early in the build. In the current state, whatever is done in the spec file is overwritten.

Specifically, this:

 96 for file in %SOURCE2 %SOURCE3; do
 97     for dest in $(find -name "$(basename "$file")"); do
 98         cp "$file" "$dest"
 99     done
100 done

Is made useless by that:

104 %configure

I'll therefore probably remove the SOURCE2 and SOURCE3 here, upgrade the redhat-rpm-config package files, and add a note in the automake spec file regarding these above the %configure call.

Comment 4 Frédéric Bérat 2022-05-17 08:08:58 UTC
One side note, the hack for config.sub and config.guess got broken by commit c3fe43baf69725b274687b615a7159ccd777a3b0 "Rebase to version 1.16.3" which removed the lines:

-# disable replacing config.guess and config.sub from redhat-rpm-config
-%global _configure_gnuconfig_hack 0

Still, I'd prefer to centralize the maintenance of the config.guess and config.sub files, and will discuss it with redhat-rpm-config maintainers.

Comment 5 Pavel Raiskup 2022-05-17 10:09:21 UTC
(In reply to Frédéric Bérat from comment #3)
> (In reply to Pavel Raiskup from comment #2)
> > This is correct behavior.  The redhat-rpm-config maintainers take care of
> > those files, and take the responsibility for providing new enough files
> > for _build RPMs_.
> 
> It likely is the correct behavior, but the file that is provided by
> redhat-rpm-config is from 2016.

Then this should be probably cloned against redhat-rpm-config component.

> > > I'll therefore investigate to remove the change done in the spec file to
> > > pull an outdated version of these files (which seems to be useless
> > > nowadays), and check to upgrade the one in redhat-rpm-config.
> > 
> > The automake package should contain the latest-greatest upstream versions
> > of the config.sub/config.guess files.  This is because those files are
> > automatically re-distributed in tarballs generated by upstreams (the
> > normal way of 'make dist' releasing).  For upgrading, there's the
> > `./sync_gnuconfig.sh` script:
> > https://src.fedoraproject.org/rpms/automake/blob/
> > 3e8430b36dc15567e3de43a8781c39d87744884e/f/sync_gnuconfig.sh
> 
> That is currently useless, because the redhat-rpm-config replaces the file
> early in the build. In the current state, whatever is done in the spec file
> is overwritten.

Ah.  That is broken :-(

> Specifically, this:
> 
>  96 for file in %SOURCE2 %SOURCE3; do
>  97     for dest in $(find -name "$(basename "$file")"); do
>  98         cp "$file" "$dest"
>  99     done
> 100 done

Yeah: https://bugzilla.redhat.com/show_bug.cgi?id=991613

> Is made useless by that:
> 
> 104 %configure

Nah.

> I'll therefore probably remove the SOURCE2 and SOURCE3 here, upgrade the
> redhat-rpm-config package files, and add a note in the automake spec file
> regarding these above the %configure call.

Yeah, but redhat-rpm-config has a direct effect on all the Fedora package that
use %configure macro, and thus updating `redhat-rpm-config` too frequently may
be considered an unnecessary risk — and useless, as long as everything in
Fedora builds just fine (RPM build failures caused by outdated config.* files
are typically observed by folks from hardware-enable initiatives).  Well, at
least I didn't want to blindly update those files periodically within my
provenpackager rights.

Shipping an updated config.sub/config.guess files in Automake is though 100%
valid.

Files in Automake are for upstreams, redhat-rpm-config files were meant
for the Fedora downstream.

(In reply to Frédéric Bérat from comment #4)
> One side note, the hack for config.sub and config.guess got broken by commit
> c3fe43baf69725b274687b615a7159ccd777a3b0 "Rebase to version 1.16.3" which
> removed the lines:
> 
> -# disable replacing config.guess and config.sub from redhat-rpm-config
> -%global _configure_gnuconfig_hack 0

Good catch!

> Still, I'd prefer to centralize the maintenance of the config.guess and
> config.sub files, and will discuss it with redhat-rpm-config maintainers.

I still think that the status quo is quite valid and settled down. 

OTOH, if you and the hw-enablement teams are OK with maintaining it that way,
I have no objections :-)  if nothing, revamping this topic and getting
everyone synced is a perfect idea.

Comment 6 Frédéric Bérat 2022-05-31 13:21:20 UTC
As discussed with redhat-rpm-config maintainers, we updated the config.{sub,guess} files, and they will keep them in sync on a 6 month basis. I'd say that's a good compromise.

I'll therefore trigger a rebuild of automake soon, the package will then get the (currently) newest version of config.{sub,guess}.

I'll also follow-up with redhat-rpm-config maintainers if necessary in 6 month.

Comment 8 Pavel Raiskup 2022-06-01 05:18:24 UTC
I would say this deserves a non-compromise solution.  How exactly the new workflow is better
from what we had before c3fe43baf69725b274687b615a7159ccd777a3b0?

Comment 9 Frédéric Bérat 2022-06-01 08:28:50 UTC
(In reply to Pavel Raiskup from comment #8)
> I would say this deserves a non-compromise solution.  How exactly the new
> workflow is better
> from what we had before c3fe43baf69725b274687b615a7159ccd777a3b0?

Automake isn't updated as often as redhat-rpm-config is. Last update of the config.{sub,guess} files was 4 years ago in automake, and before that they were updated less than twice a year in average. On top of that, the use of "%global _configure_gnuconfig_hack 0" looks to be error prone, as it was removed by mistake, leading to the current bug.

As being part of the redhat-rpm-config, the update of the config.{sub,guess} can be made part of the system wide change proposal process that the tools team has in place, resulting in an update every 6 month before rawhide freeze, and there is no need for a specific change in automake to get the change in as there are regular rebuilds. Plus, this update may rely on multiple maintainers instead of one, since there are multiple people in charge of redhat-rpm-config plus the automake maintainer.

I'm assuming that I won't maintain this package ad vitam eternam. Even if I now know I need to check on these files, I may miss to pass this information, and I hope that making this update part of a more regular process will improve the situation.

Comment 10 Pavel Raiskup 2022-06-01 09:26:22 UTC
The updates of redhat-rpm-config are more frequent, but not the config* files
included.  These were updated in 2016 (6 years ago).  With a trivial fix, we can
get an automatic notification about outdated files upon upstream releases:
https://src.fedoraproject.org/rpms/automake/pull-request/6

Of course, we shouldn't remove documented statements from spec files without
a reason - bugs happen, that's why we are here.  I fail to see the progress
in the proposed approach (as nobody will just step up with 6 months cadence
and update those files, and do redhat-rpm-config => automake chain build).

Comment 11 Pavel Raiskup 2022-06-01 09:46:50 UTC
Reading better, ad. "system wide change proposal process".  Do you have a link
to documentation for this process?  Updating config.* (no matter where
those files are) there sounds like a good idea.

Comment 12 Frédéric Bérat 2022-06-01 11:02:36 UTC
(In reply to Pavel Raiskup from comment #10)
> The updates of redhat-rpm-config are more frequent, but not the config* files
> included.  These were updated in 2016 (6 years ago).

Not yet, that's why I discussed it with the team.

> With a trivial fix, we can
> get an automatic notification about outdated files upon upstream releases:
> https://src.fedoraproject.org/rpms/automake/pull-request/6

That assumes automake package gets a new release regularly.
If the package doesn't get at least a minor update for a while, then this check won't be enough.

(In reply to Pavel Raiskup from comment #11)
> Reading better, ad. "system wide change proposal process".  Do you have a
> link
> to documentation for this process?  Updating config.* (no matter where
> those files are) there sounds like a good idea.

Specifically for F37: https://fedoraproject.org/wiki/Changes/GNUToolchainF37#Current_status

Comment 13 Pavel Raiskup 2022-06-01 11:56:31 UTC
> Not yet, that's why I discussed it with the team

Is there some link to the discussion?  I'd like to see that the there are
no objections against periodically touching redhat-rpm-config (because
typically there's zero motivation to do so).

> That assumes automake package gets a new release regularly.

Not only, we still can update the files anytime we want.  E.g. during changes
like GNUToolchainF37 (when documented so) or upon request (like this bug).

> Specifically for F37: https://fedoraproject.org/wiki/Changes/GNUToolchainF37#Current_status

Is this an ad-hoc document, or do you have some template so it is guaranteed
that we will not forget about gnuconfig update during some future change?

Comment 14 Frédéric Bérat 2022-06-01 12:48:07 UTC
There is no recording on the discussion, as it happened during our weekly bug tracking call.
Touching the configs regularly on rawhide is fine. Changes on stable releases would anyway be on a need basis.

We agreed on the fact that these config needs to be updated more regularly in redhat-rpm-config, and that there is no point in duplicating the effort.
We also agreed that doing it during the GNU Toolchain system wide change would be the perfect candidate as it happens every 6 month, prior to new releases.

We can still make an update on stable branches on demand, as proposed for f36: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/202.

If this process doesn't work, it's never too late to change it again.

Comment 15 Fedora Update System 2022-06-07 09:16:42 UTC
FEDORA-2022-90af358d69 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-90af358d69

Comment 16 Carlos O'Donell 2022-06-07 19:55:03 UTC
(In reply to Frédéric Bérat from comment #14)
> There is no recording on the discussion, as it happened during our weekly
> bug tracking call.
> Touching the configs regularly on rawhide is fine. Changes on stable
> releases would anyway be on a need basis.
> 
> We agreed on the fact that these config needs to be updated more regularly
> in redhat-rpm-config, and that there is no point in duplicating the effort.
> We also agreed that doing it during the GNU Toolchain system wide change
> would be the perfect candidate as it happens every 6 month, prior to new
> releases.
> 
> We can still make an update on stable branches on demand, as proposed for
> f36: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/202.
> 
> If this process doesn't work, it's never too late to change it again.

Agreed. I have a GNUToolchainF37 system-wide update in progress here:
https://fedoraproject.org/wiki/Changes/GNUToolchainF37
and I added a checklist there to review config.guess and config.sub at 
least every 6 months as part of the update.

Comment 17 Fedora Update System 2022-06-08 01:14:08 UTC
FEDORA-2022-90af358d69 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-90af358d69`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-90af358d69

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2022-06-16 01:20:13 UTC
FEDORA-2022-90af358d69 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.