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'
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.
(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
(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.
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.
(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.
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.
I would say this deserves a non-compromise solution. How exactly the new workflow is better from what we had before c3fe43baf69725b274687b615a7159ccd777a3b0?
(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.
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).
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.
(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
> 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?
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.
FEDORA-2022-90af358d69 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-90af358d69
(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.
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.
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.