Created attachment 1944494 [details] am-utils-configure-c99.patch The am-utils configure script presently relies on support for implicit function declarations and implicit ints in compilers, and compiler defaults are likely to change soon. I could not find an active upstream for this package, so I'm reporting this here for tracking purposes.
(In reply to Florian Weimer from comment #0) > Created attachment 1944494 [details] > am-utils-configure-c99.patch > > The am-utils configure script presently relies on support for implicit > function declarations and implicit ints in compilers, and compiler defaults > are likely to change soon. > > I could not find an active upstream for this package, so I'm reporting this > here for tracking purposes. Hi Florien, The upstream of this package is/was barely present for some time, not that I've actually checked in a while now. We may have to retire the package if this ends up being a serious problem. However, I'm pretty sure the configure script is generated from the m4 source on every build so doesn't that mean there's a problem with the auto tools?
(In reply to Ian Kent from comment #1) > (In reply to Florian Weimer from comment #0) > > Created attachment 1944494 [details] > > am-utils-configure-c99.patch > > > > The am-utils configure script presently relies on support for implicit > > function declarations and implicit ints in compilers, and compiler defaults > > are likely to change soon. > > > > I could not find an active upstream for this package, so I'm reporting this > > here for tracking purposes. > > Hi Florien, > > The upstream of this package is/was barely present for some time, not that > I've actually checked in a while now. > > We may have to retire the package if this ends up being a serious problem. > > However, I'm pretty sure the configure script is generated from the m4 > source on every build so doesn't that mean there's a problem with the > auto tools? Oh wait the script changes the m4 macros, ;)
(In reply to Ian Kent from comment #2) > Oh wait the script changes the m4 macros, ;) Yeah, I first patched acinclude.m4 and was confused as to why my changes did not stick and were reverted during the build. I think this work is really done, and we are back to general concerns about shipping a package with no active upstream.
(In reply to Florian Weimer from comment #3) > (In reply to Ian Kent from comment #2) > > Oh wait the script changes the m4 macros, ;) > > Yeah, I first patched acinclude.m4 and was confused as to why my changes did > not stick and were reverted during the build. > > I think this work is really done, and we are back to general concerns about > shipping a package with no active upstream. Yes, but let me offer my thoughts on this. But first, should I do whatever is need to include this patch in the package? The history is that upstream (https://www.am-utils.org/) has not been very active for a long time but it has actually been possible to get changes merged occasionally which I have last done some time ago. However there are problems with with the package due to NFS changes in Fedora so maintenance has become difficult. For example removing NFS over UDP support is a problem and if NFS v3 support is removed I would need to develop an NFSv4 server for amd as I did for NFSv3 when NFSv2 support was removed (which I was able to get accepted upstream). I have no plans to develop an NFSv4 server for amd unless we get a strong Fedora user push back. All this is bringing us closer to retiring am-utils which ultimately will have to be done but for now using the amd kernel autofs automount support (instead of the internal NFS) continues to work so the package should continue to be useful for a little while longer. However, if making auto conf continue to work becomes difficult that would be another good reason to retire the package. Is that all ok with you? Ian
(In reply to Ian Kent from comment #4) > But first, should I do whatever is need to include this patch in the package? Yes please. I didn't see any indication that dist-git isn't the primary source for the Fedora package.e > However, if making auto conf continue to work becomes difficult that would > be another good reason to retire the package. I don't think these autoconf fixes are significant maintenance burden compared to the NFS worries.