* CI scallywag setup/cygport/autoconf missing autoconf-archive pkg @ 2021-09-30 4:15 Brian Inglis 2021-10-01 21:37 ` Yaakov Selkowitz 2021-10-02 4:15 ` Achim Gratz 0 siblings, 2 replies; 8+ messages in thread From: Brian Inglis @ 2021-09-30 4:15 UTC (permalink / raw) To: Cygwin Applications Hi folks, Autotools needs m4 macros in autoreconf-archive to config for gcov and other dependencies or build fails with e.g. "configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation." CI scallywag setup does not install nor does cygport nor autoconf require autoconf-archive so packages have to include in BUILD_REQUIRES. As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that would be the more appropriate place for an autoconf-archive requirement, otherwise cygport would have to require it, which is not so obvious. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-09-30 4:15 CI scallywag setup/cygport/autoconf missing autoconf-archive pkg Brian Inglis @ 2021-10-01 21:37 ` Yaakov Selkowitz 2021-10-02 0:06 ` Brian Inglis 2021-10-02 4:15 ` Achim Gratz 1 sibling, 1 reply; 8+ messages in thread From: Yaakov Selkowitz @ 2021-10-01 21:37 UTC (permalink / raw) To: Cygwin Applications On Wed, 2021-09-29 at 22:15 -0600, Brian Inglis wrote: > Hi folks, > > Autotools needs m4 macros in autoreconf-archive to config for gcov and > other dependencies or build fails with e.g. > > "configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation." > > CI scallywag setup does not install nor does cygport nor autoconf > require autoconf-archive so packages have to include in BUILD_REQUIRES. > > As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that > would be the more appropriate place for an autoconf-archive requirement, > otherwise cygport would have to require it, which is not so obvious. autoconf-archive would be a build requirement of the package whose configure.ac references the AX_* macro, not of the autotools themselves. -- Yaakov -- Yaakov ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-10-01 21:37 ` Yaakov Selkowitz @ 2021-10-02 0:06 ` Brian Inglis 0 siblings, 0 replies; 8+ messages in thread From: Brian Inglis @ 2021-10-02 0:06 UTC (permalink / raw) To: cygwin-apps On 2021-10-01 15:37, Yaakov Selkowitz via Cygwin-apps wrote: > On Wed, 2021-09-29 at 22:15 -0600, Brian Inglis wrote: >> Autotools needs m4 macros in autoreconf-archive to config for gcov and >> other dependencies or build fails with e.g. >> "configure.ac:33: error: possibly undefined macro: AX_CODE_COVERAGE >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation." >> CI scallywag setup does not install nor does cygport nor autoconf >> require autoconf-archive so packages have to include in BUILD_REQUIRES. >> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >> would be the more appropriate place for an autoconf-archive requirement, >> otherwise cygport would have to require it, which is not so obvious. > autoconf-archive would be a build requirement of the package whose > configure.ac references the AX_* macro, not of the autotools themselves. It appears to be just installed as part of build or development packages on upstreams systems, perhaps the GNU Build System, such that they don't even mention it as a requirement. It appears that the newer AX_... macros are defined in autoconf-archive, and they are now being used in packages. I would prefer it be required by autoconf or cygport, as I expect more if its macros will be used in the future, especially as more packages will require it to build with autotools, but it is not obvious that part of the autoconf infrastructure is not automatically installed, nor where one should look to find AX_... whatever in a package that is not installed. I only figured it out because I was looking for issues with autotools macros because of issues with gnulib in GNU packages, which I have been dealing with recently in three packages, and expect more unless they pull in the newer release with the patch applied. I have posted a general message to the list to watch out for that issue, which crashes all programs configured with it. As the lack of autoconf-archive installed by scallywag CI kills jobs run when commits are pushed, I expect this to cause some frustration to maintainers, which given lag in package updates with the current shortage of people and time, I would like to mitigate likely future common issues as much as possible. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-09-30 4:15 CI scallywag setup/cygport/autoconf missing autoconf-archive pkg Brian Inglis 2021-10-01 21:37 ` Yaakov Selkowitz @ 2021-10-02 4:15 ` Achim Gratz 2021-10-02 5:48 ` Brian Inglis 1 sibling, 1 reply; 8+ messages in thread From: Achim Gratz @ 2021-10-02 4:15 UTC (permalink / raw) To: cygwin-apps Brian Inglis writes: > As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that > would be the more appropriate place for an autoconf-archive > requirement, otherwise cygport would have to require it, which is not > so obvious. No. If a build needs autoconf-archive then require it there. The whole point of having things in separate packages is that you do not have to install things you don't need. Neither autottols nor cygport require this package in any way. Off-tangent: cygport has entirely too many dependencies already which we can't help with our current package system. I'd love to have a way for these dependencies not to creep into each build. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-10-02 4:15 ` Achim Gratz @ 2021-10-02 5:48 ` Brian Inglis 2021-10-02 14:13 ` Ken Brown 0 siblings, 1 reply; 8+ messages in thread From: Brian Inglis @ 2021-10-02 5:48 UTC (permalink / raw) To: cygwin-apps On 2021-10-01 22:15, Achim Gratz wrote: > Brian Inglis writes: >> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >> would be the more appropriate place for an autoconf-archive >> requirement, otherwise cygport would have to require it, which is not >> so obvious. > > No. If a build needs autoconf-archive then require it there. The whole > point of having things in separate packages is that you do not have to > install things you don't need. Neither autottols nor cygport require > this package in any way. See response to Yaakov: the problem is it's just a given in the build systems of the packages that use it, just as is gnulib implicitly, so neither are ever mentioned as requirements or components. You have to trip over the problems, try to find occurences online (which is difficult with packages preinstalled with every Linux or GNU development setup), dig down to find the problem, dig around to find the solution; possibly bounce it off upstream, and reference, pull, or adapt their patch which is to their current master; or if it's a Cygwin environment issue, fix it in cygport; and request that upstream at least mention it in their requirements (for which they may think you, or the Cygwin build setup, may have some deficiencies); or mention that they include a release of something which is really an ongoing creeping unreleased blob: gnulib as of when they last picked it up; or some other pet project of theirs which they just embed in their package, as it worked on their system, and saves them writing a few new lines of code. > Off-tangent: cygport has entirely too many dependencies already which we > can't help with our current package system. I'd love to have a way for > these dependencies not to creep into each build. I'd love to have a way for maintainers not to have to figure out what is missing from the Cygwin build system that upstream package developers just assume everyone has on their GNU, Linux, Debian, Fedora, OpenSuSE or etc. build system! ;^> I admit I am clueless about autotools, open source development, and build systems. I have worked mainly in commercial, corporate environments, with teams of a few dozen to a couple of hundred, sometimes dozens but usually hundreds of support staff, where they want some product fixed or enhanced the next day, provide minimal tools, and don't really care how the job gets done, as long as it is cheap and soon, or at least within their planned timeframe and budget. (But necessarily according to this month's list of approved or required architectures, languages, tools, techniques, methodologies, and project approaches!) ;^> And this month has had me spending most of my free time for Cygwin tripping over issues of only three packages with mysterious issues never encountered or imagined by the upstreams because of their build environments; and that makes me pause from contemplating adopting others, if each could take up a week of my free time to handle each new update. Maintainers can spent their time chasing issues with Cygwin "deficiencies" and digging into the issues, working with upstream developers to track down problems, and asking upstream developers to document things (shock!) which no other downstream has ever requested; or they can release upgraded packages with minimal friction! But I've always felt putting obstacles that can be easily mitigated in the way of getting the good work done with minimal friction is possibly not the best approach that any group should take. [I got an impression that bits of gnulib blobs may be making their way into the more formal packaging of autoconf-archive to avoid GNU autotools maintainers having to blast in random gnulib replacement blobs once in a while and hope that nothing breaks (on their development platform at least).] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-10-02 5:48 ` Brian Inglis @ 2021-10-02 14:13 ` Ken Brown 2021-10-02 16:35 ` Brian Inglis 0 siblings, 1 reply; 8+ messages in thread From: Ken Brown @ 2021-10-02 14:13 UTC (permalink / raw) To: cygwin-apps On 10/2/2021 1:48 AM, Brian Inglis wrote: > On 2021-10-01 22:15, Achim Gratz wrote: >> Brian Inglis writes: >>> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >>> would be the more appropriate place for an autoconf-archive >>> requirement, otherwise cygport would have to require it, which is not >>> so obvious. >> >> No. If a build needs autoconf-archive then require it there. The whole >> point of having things in separate packages is that you do not have to >> install things you don't need. Neither autottols nor cygport require >> this package in any way. > > See response to Yaakov: the problem is it's just a given in the build systems of > the packages that use it, I acknowledge that it's easy to give advice with hindsight, but here are two ways you might have discovered that you needed autoconf-archive as a build requirement for your package. 1. You could have checked the Fedora .spec file for the package. In my experience, Fedora maintainers are generally very good at listing build requirements. I don't think you've said what package you're talking about, so I can't check whether that would have helped in this case. 2. An internet search for AX_CODE_COVERAGE would have immediately told you that it's in autoconf-archive. You also mentioned the gnulib bug you ran into while packaging bison. It's unfortunate that you lost so much time on this, but you handled it exactly right. You reported it upstream, they passed it on to gnulib, and it got fixed. We all appreciate the effort you've been making to adopt orphaned packages. I think you've just run into a string of bad luck that has caused this to be very time consuming. Ken ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-10-02 14:13 ` Ken Brown @ 2021-10-02 16:35 ` Brian Inglis 2021-10-03 19:14 ` Brian Inglis 0 siblings, 1 reply; 8+ messages in thread From: Brian Inglis @ 2021-10-02 16:35 UTC (permalink / raw) To: cygwin-apps On 2021-10-02 08:13, Ken Brown via Cygwin-apps wrote: > On 10/2/2021 1:48 AM, Brian Inglis wrote: >> On 2021-10-01 22:15, Achim Gratz wrote: >>> Brian Inglis writes: >>>> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >>>> would be the more appropriate place for an autoconf-archive >>>> requirement, otherwise cygport would have to require it, which is not >>>> so obvious. >>> >>> No. If a build needs autoconf-archive then require it there. The whole >>> point of having things in separate packages is that you do not have to >>> install things you don't need. Neither autottols nor cygport require >>> this package in any way. >> >> See response to Yaakov: the problem is it's just a given in the build >> systems of the packages that use it, > > I acknowledge that it's easy to give advice with hindsight, but here are > two ways you might have discovered that you needed autoconf-archive as a > build requirement for your package. > > 1. You could have checked the Fedora .spec file for the package. In my > experience, Fedora maintainers are generally very good at listing build > requirements. I don't think you've said what package you're talking > about, so I can't check whether that would have helped in this case. I have clued in over time and grab package .spec and Debian .dsc, debian/rules and any other distro files with useful content, while I am looking at a package. As I said, it appears to be assumed it's in the infrastructure, I can't find any other spec linkages to autoconf-archive, and get similar results in Debian and OpenSuSE Build System: wget/wget.spec:BuildRequires: gnutls-devel, pkgconfig, texinfo, gettext, autoconf, libidn2-devel, libuuid-devel, perl-podlators, libpsl-devel, libmetalink-devel, gpgme-devel, gcc, zlib-devel If anyone can suggest how I can trace the Fedora web to find those, or other distros, I would be grateful. > 2. An internet search for AX_CODE_COVERAGE would have immediately told > you that it's in autoconf-archive. It wasn't that apparent as I use DDG and no longer use Google! ;^> > You also mentioned the gnulib bug you ran into while packaging bison. > It's unfortunate that you lost so much time on this, but you handled it > exactly right. You reported it upstream, they passed it on to gnulib, > and it got fixed. > > We all appreciate the effort you've been making to adopt orphaned > packages. I think you've just run into a string of bad luck that has > caused this to be very time consuming. I'm not so worried about my time as the implications for other maintainers who may not, and getting more on board, if there is a large impedance between our and other build system infrastructure. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CI scallywag setup/cygport/autoconf missing autoconf-archive pkg 2021-10-02 16:35 ` Brian Inglis @ 2021-10-03 19:14 ` Brian Inglis 0 siblings, 0 replies; 8+ messages in thread From: Brian Inglis @ 2021-10-03 19:14 UTC (permalink / raw) To: cygwin-apps On 2021-10-02 10:35, Brian Inglis wrote: > On 2021-10-02 08:13, Ken Brown via Cygwin-apps wrote: >> On 10/2/2021 1:48 AM, Brian Inglis wrote: >>> On 2021-10-01 22:15, Achim Gratz wrote: >>>> Brian Inglis writes: >>>>> As autoconf requires: autoconf2.1 autoconf2.5 bash sed, I believe that >>>>> would be the more appropriate place for an autoconf-archive >>>>> requirement, otherwise cygport would have to require it, which is not >>>>> so obvious. >>>> >>>> No. If a build needs autoconf-archive then require it there. The whole >>>> point of having things in separate packages is that you do not have to >>>> install things you don't need. Neither autottols nor cygport require >>>> this package in any way. >>> >>> See response to Yaakov: the problem is it's just a given in the build >>> systems of the packages that use it, >> >> I acknowledge that it's easy to give advice with hindsight, but here >> are two ways you might have discovered that you needed >> autoconf-archive as a build requirement for your package. >> >> 1. You could have checked the Fedora .spec file for the package. In >> my experience, Fedora maintainers are generally very good at listing >> build requirements. I don't think you've said what package you're >> talking about, so I can't check whether that would have helped in this >> case. > > I have clued in over time and grab package .spec and Debian .dsc, > debian/rules and any other distro files with useful content, while I am > looking at a package. > As I said, it appears to be assumed it's in the infrastructure, I can't > find any other spec linkages to autoconf-archive, and get similar > results in Debian and OpenSuSE Build System: > > wget/wget.spec:BuildRequires: gnutls-devel, pkgconfig, texinfo, gettext, > autoconf, libidn2-devel, libuuid-devel, perl-podlators, libpsl-devel, > libmetalink-devel, gpgme-devel, gcc, zlib-devel > > If anyone can suggest how I can trace the Fedora web to find those, or > other distros, I would be grateful. > >> 2. An internet search for AX_CODE_COVERAGE would have immediately told >> you that it's in autoconf-archive. > > It wasn't that apparent as I use DDG and no longer use Google! ;^> > >> You also mentioned the gnulib bug you ran into while packaging bison. >> It's unfortunate that you lost so much time on this, but you handled >> it exactly right. You reported it upstream, they passed it on to >> gnulib, and it got fixed. >> >> We all appreciate the effort you've been making to adopt orphaned >> packages. I think you've just run into a string of bad luck that has >> caused this to be very time consuming. > > I'm not so worried about my time as the implications for other > maintainers who may not, and getting more on board, if there is a large > impedance between our and other build system infrastructure. I've found that gnome-common requires autoconf-archive as it builds on it (from f21+, as does mate-common on recent Debian and Fedora main/rawhide but not epel7 nor Cygwin) so that may be why Linux build environments always have it available. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-10-03 19:14 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-30 4:15 CI scallywag setup/cygport/autoconf missing autoconf-archive pkg Brian Inglis 2021-10-01 21:37 ` Yaakov Selkowitz 2021-10-02 0:06 ` Brian Inglis 2021-10-02 4:15 ` Achim Gratz 2021-10-02 5:48 ` Brian Inglis 2021-10-02 14:13 ` Ken Brown 2021-10-02 16:35 ` Brian Inglis 2021-10-03 19:14 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).