Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
Bruno Haible writes: > Richard Stallman commented on Jacob Bachmeyer's idea: >> > > Another related check that /would/ have caught this attempt would be >> > > comparing the aclocal m4 files in a release against their >> (meta)upstream >> > > sources before building a package. This is something distribution >> > > maintainers could do without cooperation from upstream. If >> > > m4/build-to-host.m4 had been recognized as coming from gnulib and >> > > compared to the copy in gnulib, the nonempty diff would have been >> > > suspicious. >> >> I have a hunch that some effort is needed to do that comparison, but >> that it is feasible to write a script to do it could make it easy. >> Is that so? > > Yes, the technical side of such a comparison is relatively easy to > implement: > - There are less than about 2000 or 5000 *.m4 files that are shared > between projects. Downloading and storing all historical versions > of these files will take ca. 0.1 to 1 GB. > - They would be stored in a content-based index, i.e. indexed by > sha256 hash code. > - A distribution could then quickly test whether a *.m4 file found > in a distrib tarball is "known". > > The recurrently time-consuming part is, whenever an "unknown" *.m4 file > appears, to > - manually review it, > - update the list of upstream git repositories (e.g. when a project > has been forked) or the list of releases to consider (e.g. snapshots > of GNU Autoconf or GNU libtool, or distribution-specific modifications). > > I agree with Jacob that a distro can put this in place, without needing > to bother upstream developers. I'm currently looking at adding support for this to https://github.com/hlein/distro-backdoor-scanner. It was brought up at https://openwall.com/lists/oss-security/2024/04/02/5. > > Bruno best, sam
bug#68274: automake 1.16j nonnumerical version confuses scripts
"Zack Weinberg" writes:
> On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
>> On 13 Jan 2024 15:58, Karl Berry wrote:
>>> Another alternative: when this came up 30-odd years ago, rms changed the
>>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>>> that would at least have the benefit of following a recommendation, and
>>> as a side effect, would also fix jami's assumption (poor practice though
>>> it is, IMHO).
>>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>>>
>>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>>> (rough guess with some grep counting) the .90 convention is by far the
>>> most common approach (a couple thousand), followed by the suffix letter
>>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>>> are both trailing the field. Other random conventions also present.
>>>
>>> It all feels like bikeshedding to me, so my inclination is to do
>>> nothing. If we do change, I think we should use .90. --best, karl.
>>
>> using .90 is certainly better than single-letters. if you're fine with
>> it, then let's switch.
>
> For what it's worth, I had planned to switch Autoconf, starting with the
> next release, to use *some* version numbering scheme for beta releases
> that sorts correctly according to things like strverscmp() and
> dpkg --compare-versions. The "append a letter to the version number
> intended for the final release" convention makes these algorithms sort
> the betas *after* the release, which is backwards.
>
> My plan *was* to append letters to the version number for the *previous*
> release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
> which I think is what Automake is doing now) but I like .9x version numbers
> better because it's more common (as you observed) and therefore more likely
> to be understood at sight. I'd actually forgotten that .9x versions were
> an official GNU recommendation.
>
I was planning on finally filing a bug for this because I couldn't really
package the latest automake pre-release given it totally breaks our
sorting (and afaik sorting in every other PM too).
We're used to .9x and it works fine for us.
thanks,
sam
bug#62069: Support xz parallel compression in dist-xz
xz supports parallel compression which obviously speeds up the time taken to run the 'dist-xz' rule, but it also speeds up *decompression* too, as the parallel compressor creates different output which can be decompressed in parallel. There's two options, I think, for automake: 1. Pass -T+1 to xz if xz is >= 5.4.0 (a runtime check would be needed, but it's cheap to do) as this uses 1 thread, but uses the parallel compressor to do it, so allows decompression in parallel by users; 2. Pass -T0 (or -Tn, n >= 1) to allow autodetection of the number of available CPU cores (or n if specified) which also then naturally uses the threaded compressor. signature.asc Description: PGP signature
[bug#61240] improve high-res file timestamp in Automake
> On 5 Feb 2023, at 00:02, Jacob Bachmeyer wrote: > > Paul Eggert wrote: >> On 2023-02-03 18:27, Jacob Bachmeyer wrote: >>> Where are you actually using a 5.10 feature? >> >> Where lib/Automake/FileUtils.pm says "use Time::HiRes qw(stat);". This does >> not work with Perl 5.6. > > Time::HiRes is (perhaps was) installable from CPAN and is definitely /not/ a > 5.10 feature. I have a Perl 5.8 with it installed, and while my memories > that far back are a bit fuzzy, I seem to remember installing Time::HiRes on a > Perl 5.6 installation some years ago. Things like "our" variables, > PerlIO-by-default, and the defined-or operator are Perl features (those in > 5.6, 5.8, and 5.10 if I remember correctly), modules are (with rare > exceptions) not Perl features. > > The correct solution if you do not want to provide for the case where > Time::HiRes is not available is to simply "use Time::HiRes qw(stat);" and > *let* *that* *fail* if Time::HiRes is not available or cannot export stat(). > Time::HiRes was on CPAN long before it was bundled with Perl, so the Perl > version does /not/ tell you if it is available. (If Automake::FileUtils is > not immediately loaded, put "use Time::HiRes;" somewhere that is. That will > be enough to ensure that Time::HiRes is available.) > >> For why we bumped the version to 5.10, please see: >> >> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=61901a1a14fd50c03cfb1529d091554376fef286 >> >>> Please do not arbitrarily bump version requirements just to bump version >>> requirements. >> >> That's not what was done here. The abovementioned URL says version >> requirements were bumped from 5.6 to 5.10 because the feature is not present >> in 5.6 (2000), is present in 5.10 (2007), and we lacked access to the museum >> pieces in the middle. If you are sure that a version number lower than 5.10 >> will do, please let us know. > > This was arbitrary because Time::HiRes is not actually dependent on the Perl > version in that way. (You should also be able to get access to the museum > pieces in the middle fairly easily using perlbrew.) I think you probably mean "a mistake" rather than "arbitrary". He didn't choose it for no reason or for fun. signature.asc Description: Message signed with OpenPGP
bug#54390: YACC rules don't check DESTDIR existence for VPATH builds
> On 13 Jan 2023, at 08:43, Mike Frysinger wrote: > > On 13 Jan 2023 07:07, Sam James wrote: >> $ /tmp/libaacs/configure YACC=bison LEX=flex > > the problem is you're forcing `YACC=bison`. Automake defaults to `bison -y` > which tells bison to operate in POSIX-yacc-compatible mode because Automake's > rules target POSIX. the end result is that you've forced a non-POSIX mode, > and bison is writing files to the cwd which is not what Automake expects. > it isn't that the src/file/ directory doesn't exist -- you can see from your > log that files have been generated in src/file/ before the failure. thanks, duh. That makes sense. signature.asc Description: Message signed with OpenPGP
bug#54390: YACC rules don't check DESTDIR existence for VPATH builds
> On 13 Jan 2023, at 07:01, Mike Frysinger wrote:
>
> On 13 Jan 2023 06:29, Sam James wrote:
>>> On 13 Jan 2023, at 06:13, Mike Frysinger wrote:
>>> On 14 Mar 2022 17:21, Sam James wrote:
>>>> It appears that YACC rules don't check for whether the destination
>>>> directory exists before executing ylwrap.
>>>>
>>>> When trying to package libaacs
>>>> (https://code.videolan.org/videolan/libaacs) with an out-of-source build,
>>>> I hit an unexpected build failure:
>>>> ```
>>>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
>>>> warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
>>>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
>>>> 206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
>>>> updating src/file/keydbcfg-parser.h
>>>> mv: cannot move 'tmp-keydbcfg-parser.h' to
>>>> '../src/file/keydbcfg-parser.h': No such file or directory
>>>> make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
>>>> ```
>>>>
>>>> I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to
>>>> ensure that the necessary directory exists within the build directory
>>>> beforehand, but
>>>> it feels like I shouldn't have to.
>>>>
>>>> Their Makefile.am can be found here:
>>>> https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am.
>>>> Snippet:
>>>> ```
>>>> libaacs_la_SOURCES=\
>>>> src/libaacs/aacs.h \
>>>> [...]
>>>> src/file/dirs.h \
>>>> src/file/file.h \
>>>> src/file/file.c \
>>>> src/file/filesystem.h \
>>>> src/file/filesystem.c \
>>>> src/file/keydbcfg.c \
>>>> src/file/keydbcfg.h \
>>>> src/file/keydb.h \
>>>> src/file/keydbcfg-parser.y \
>>>> src/file/keydbcfg-lexer.l \
>>>> src/file/mmc_device.h \
>>>> [...]
>>>> ```
>>>>
>>>> While src/libaacs exists within the build dir, src/file/ doesn't exist at
>>>> all, hence the failure.
>>>>
>>>> automake yacc rules should mkdir -p the needed directories within the
>>>> build dir for VPATH builds before running ylwrap/yacc.
>>>
>>> i think there's more to it. if you're using a release tarball for this
>>> project
>>> created by `make dist`, then you shouldn't be running yacc in the first
>>> place.
>>>
>>> https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
>>
>> Curiosity got the better of me (see previous reply) so:
>> ```
>> $ cd /tmp
>> $ git clone https://code.videolan.org/videolan/libaacs/
>> $(cd libaacs && ./bootstrap.sh)
>> $mkdir libaacs-oos && cd libaacs
>
> guessing you meant `cd libaacs-oos`
>
>> $ /tmp/libaacs/configure YACC=bison LEX=flex
>> $ make
>> $ make
>> YACC src/file/keydbcfg-parser.c
>> keydbcfg-parser.tab.c is unchanged
>> keydbcfg-parser.tab.h is unchanged
>> make[1]: Entering directory '/tmp/libaacs-oos'
>> YACC src/file/keydbcfg-parser.c
>> keydbcfg-parser.tab.c is unchanged
>> keydbcfg-parser.tab.h is unchanged
>> make[1]: Leaving directory '/tmp/libaacs-oos'
>> make all-am
>> make[1]: Entering directory '/tmp/libaacs-oos'
>> YACC src/file/keydbcfg-parser.c
>> keydbcfg-parser.tab.c is unchanged
>> keydbcfg-parser.tab.h is unchanged
>> CC src/file/keydbcfg-parser.lo
>> cc1: fatal error: src/file/keydbcfg-parser.c: No such file or directory
>> compilation terminated.
>> make[1]: *** [Makefile:1009: src/file/keydbcfg-parser.lo] Error 1
>> make[1]: Leaving directory '/tmp/libaacs-oos'
>> make: *** [Makefile:638: all] Error 2
>> ```
>>
>> so it's still looking in the source rather than the build directory for the
>> generated file?
>
> i'm not sure what you're trying to show here. that running make twice in a
> row produces weird/inconsistent results ? if that's the case, that's not
> the behavior i'm seeing over here.
>
No, that was just an error in copying stuff into email. It happens with running
make once,
so it should be:
```
$ cd /tmp
$ git clone https://code.videolan.org/videolan/libaacs/
$ (cd libaacs && ./bootstrap)
$ mkdir libaacs-oos && cd libaacs-oos
$ /tmp/libaacs/configure YACC=bison LEX=flex
$ make
Y
bug#54390: YACC rules don't check DESTDIR existence for VPATH builds
> On 13 Jan 2023, at 06:13, Mike Frysinger wrote:
>
> On 14 Mar 2022 17:21, Sam James wrote:
>> It appears that YACC rules don't check for whether the destination directory
>> exists before executing ylwrap.
>>
>> When trying to package libaacs (https://code.videolan.org/videolan/libaacs)
>> with an out-of-source build, I hit an unexpected build failure:
>> ```
>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
>> warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
>> 206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
>> updating src/file/keydbcfg-parser.h
>> mv: cannot move 'tmp-keydbcfg-parser.h' to '../src/file/keydbcfg-parser.h':
>> No such file or directory
>> make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
>> ```
>>
>> I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to ensure
>> that the necessary directory exists within the build directory beforehand,
>> but
>> it feels like I shouldn't have to.
>>
>> Their Makefile.am can be found here:
>> https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am.
>> Snippet:
>> ```
>> libaacs_la_SOURCES=\
>> src/libaacs/aacs.h \
>> [...]
>> src/file/dirs.h \
>> src/file/file.h \
>> src/file/file.c \
>> src/file/filesystem.h \
>> src/file/filesystem.c \
>> src/file/keydbcfg.c \
>> src/file/keydbcfg.h \
>> src/file/keydb.h \
>> src/file/keydbcfg-parser.y \
>> src/file/keydbcfg-lexer.l \
>> src/file/mmc_device.h \
>> [...]
>> ```
>>
>> While src/libaacs exists within the build dir, src/file/ doesn't exist at
>> all, hence the failure.
>>
>> automake yacc rules should mkdir -p the needed directories within the build
>> dir for VPATH builds before running ylwrap/yacc.
>
> i think there's more to it. if you're using a release tarball for this
> project
> created by `make dist`, then you shouldn't be running yacc in the first place.
>
> https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Curiosity got the better of me (see previous reply) so:
```
$ cd /tmp
$ git clone https://code.videolan.org/videolan/libaacs/
$(cd libaacs && ./bootstrap.sh)
$mkdir libaacs-oos && cd libaacs
$ /tmp/libaacs/configure YACC=bison LEX=flex
$ make
$ make
YACC src/file/keydbcfg-parser.c
keydbcfg-parser.tab.c is unchanged
keydbcfg-parser.tab.h is unchanged
make[1]: Entering directory '/tmp/libaacs-oos'
YACC src/file/keydbcfg-parser.c
keydbcfg-parser.tab.c is unchanged
keydbcfg-parser.tab.h is unchanged
make[1]: Leaving directory '/tmp/libaacs-oos'
make all-am
make[1]: Entering directory '/tmp/libaacs-oos'
YACC src/file/keydbcfg-parser.c
keydbcfg-parser.tab.c is unchanged
keydbcfg-parser.tab.h is unchanged
CC src/file/keydbcfg-parser.lo
cc1: fatal error: src/file/keydbcfg-parser.c: No such file or directory
compilation terminated.
make[1]: *** [Makefile:1009: src/file/keydbcfg-parser.lo] Error 1
make[1]: Leaving directory '/tmp/libaacs-oos'
make: *** [Makefile:638: all] Error 2
```
so it's still looking in the source rather than the build directory for the
generated file?
signature.asc
Description: Message signed with OpenPGP
bug#54390: YACC rules don't check DESTDIR existence for VPATH builds
> On 13 Jan 2023, at 06:13, Mike Frysinger wrote:
>
> On 14 Mar 2022 17:21, Sam James wrote:
>> It appears that YACC rules don't check for whether the destination directory
>> exists before executing ylwrap.
>>
>> When trying to package libaacs (https://code.videolan.org/videolan/libaacs)
>> with an out-of-source build, I hit an unexpected build failure:
>> ```
>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
>> warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
>> /var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
>> 206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
>> updating src/file/keydbcfg-parser.h
>> mv: cannot move 'tmp-keydbcfg-parser.h' to '../src/file/keydbcfg-parser.h':
>> No such file or directory
>> make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
>> ```
>>
>> I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to ensure
>> that the necessary directory exists within the build directory beforehand,
>> but
>> it feels like I shouldn't have to.
>>
>> Their Makefile.am can be found here:
>> https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am.
>> Snippet:
>> ```
>> libaacs_la_SOURCES=\
>> src/libaacs/aacs.h \
>> [...]
>> src/file/dirs.h \
>> src/file/file.h \
>> src/file/file.c \
>> src/file/filesystem.h \
>> src/file/filesystem.c \
>> src/file/keydbcfg.c \
>> src/file/keydbcfg.h \
>> src/file/keydb.h \
>> src/file/keydbcfg-parser.y \
>> src/file/keydbcfg-lexer.l \
>> src/file/mmc_device.h \
>> [...]
>> ```
>>
>> While src/libaacs exists within the build dir, src/file/ doesn't exist at
>> all, hence the failure.
>>
>> automake yacc rules should mkdir -p the needed directories within the build
>> dir for VPATH builds before running ylwrap/yacc.
>
> i think there's more to it. if you're using a release tarball for this
> project
> created by `make dist`, then you shouldn't be running yacc in the first place.
>
> https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
>> The intermediate files generated by yacc (or lex) will be included in any
>> distribution that is made. That way the user doesn’t need to have yacc or
>> lex.
>
> cloning that repo and running `make dist` shows the file is generated, and
> it's
> listed in am__DIST_COMMON, but it still doesn't make it into the tarball. oh,
> it looks like this is self-inflicted:
> https://code.videolan.org/videolan/libaacs/-/blob/0.11.1/Makefile.am#L88
> https://code.videolan.org/videolan/libaacs/-/commit/f60f46da1dc5e87f70b6edc965a8909d3f21c247
>
> that makes no sense. file a bug with them.
Thanks - IIRC I hit this when running from git too, which is why I filed the
bug, but that's definitely
wrong on their side anyway, and I can't say I want to bother trying to build it
again from git.
I'll report it over there.
signature.asc
Description: Message signed with OpenPGP
bug#33573: Patch to replace symlinks with files
> On 31 Dec 2022, at 19:20, Bogdan wrote: > > Karl Berry , Sat Dec 31 2022 03:30:42 GMT+0100 (Central > European Standard Time) > [snip] > >> For the same reason, it is good to explicitly cc a bug's originator and >> anyone else who has contributed to the bug, if you happen to have them. > > > I didn't want to send any notifications to the bugs in case my patches get > rejected for some reason (like they don't work on *BSD/some antique Unix, > don't match the programming style, etc., or are completely against the idea). > > Furthermore, Automake doesn't get so many releases, as I see, so even > implementing a fix doesn't mean that it will go to a release any time soon. > I appreciate the thought, but this is likely to be more confusing as we want feedback if possible, and you're trying - so it can't hurt. Don't overthink it. :) signature.asc Description: Message signed with OpenPGP
[bug#59991] [PATCH 0/2] Port tests to modern C
> On 12 Dec 2022, at 22:57, Karl Berry wrote: >Another patch dedicated to Flex related tests will follow. > > Just wondering again, is an upstream flex still actively maintained by > anyone, anywhere? Looks like https://github.com/westes/flex was touched > 6 months ago, so that's good, but there hasn't been a release for over > five years. > I've started investigating using reflex (https://invisible-island.net/reflex/reflex.html) for this reason. There's a long story with how flex broke with glibc-2.26/2.27 or so with reallocrray() and implicit function declarations and there hasn't been a release to fix that (https://github.com/westes/flex/issues/499) so all distros have to backport a bunch of patches to fix it: - https://github.com/westes/flex/commit/4b5111d9772b5c160340ca96f08d30d7f6db5cda - https://github.com/westes/flex/commit/24fd0551333e7eded87b64dd36062da3df2f6380 - https://github.com/westes/flex/commit/0db9f8903a446e7026874be519b8dc55a471f014 - https://github.com/westes/flex/commit/a17d79e9c722a6735b6d2a8f152287404f27df32 - https://github.com/westes/flex/commit/4081efa0831b15d7e4e4255401c225ad8262426d - https://github.com/westes/flex/commit/1985bb3c7abed940e91ad816504ef08a18c3b7c1 Note that some of these affect the generated programs. It's possible that some of these might actually make the automake patch obsolete, although given there's no flex release definitely on the horizon, it's probably worth at least working around it in automake. See also: - https://github.com/westes/flex/issues/436 - https://bugs.gentoo.org/705800 - https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray Best, sam signature.asc Description: Message signed with OpenPGP
Re: make check(s) pre-release problems
> On 4 Oct 2022, at 23:58, Karl Berry wrote: > > With Zack's latest Python fixes, I was hoping to move towards an > Automake release, but I find myself stymied by apparently random and > unreproducible test failures. I haven't exhausted every conceivable > avenue yet, but I thought I would write in hopes that others (Zack, past > Automake developers, anyone else ...) could give it a try, and/or have > some insights. > > For me, running a parallel make check (with or without parallelizing the > "internal" makes), or make distcheck, fails some tests, e.g., nodef, > nodef2, testsuite-summary-reference-log. The exact tests that fail > changes from run to run. Running the tests on their own succeeds. Ok, so > it's something in the parallelism. But why? And how to debug? > > Nothing has changed in the tests. Nothing has changed in the automake > infrastructure. Everything worked for me a few weeks ago. Furthermore, > Jim ran make check with much more parallelism than my machine can > muster, and everything succeeded for him. That was with: > make check TESTSUITEFLAGS=-j20 > > Any ideas, directions, fixes, greatly appreciated. --thanks, karl. > Is there a way to ask your distribution's package manager which upgrades/downgrades were done in the last N weeks? It'd also be helpful to see the actual failures, although as Paul notes, make --shuffle with latest non-released make could help debugging. signature.asc Description: Message signed with OpenPGP
Re: How to speed up 'automake'
> On 22 May 2022, at 02:32, Karl Berry wrote: > > Unrelated to Jan's depend.am change, but it turns out that a previous > change broke make distcheck (768 failures). I don't feel right about > committing anything else until that is fixed. > > Error below. Jim (or anyone), can you easily advise? I haven't delved > into this part of things before. (Not sure how many of the failures are > due to these errors, but I suspect most.) --thanks,karl. > > FAIL: contrib/t/multilib > .. > configure.ac:4: warning: _AM_PROG_RM_F is m4_require'd but not m4_defun'd > aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... > configure.ac:4: the top level > configure.ac:4: warning: _AM_PROG_XARGS_N is m4_require'd but not m4_defun'd > aclocal.m4:139: AM_INIT_AUTOMAKE is expanded from... > configure.ac:4: the top level > configure:2411: error: possibly undefined macro: _AM_PROG_RM_F > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure:2412: error: possibly undefined macro: _AM_PROG_XARGS_N Hm. master is OK for me: ``` PASS: contrib/t/multilib.sh [...] PASS: t/depcomp-lt-auto.tap 84 - [absolute VPATH, nostatic] make distclean Testsuite summary for GNU Automake 1.16i # TOTAL: 2988 # PASS: 2879 # SKIP: 70 # XFAIL: 39 # FAIL: 0 # XPASS: 0 # ERROR: 0 ``` I was going to bisect but if it doesn't fail for me in the first place... :( signature.asc Description: Message signed with OpenPGP
Re: How to speed up 'automake'
> On 3 May 2022, at 22:57, Karl Berry wrote: > >I see no reason why mv would be so crucial. > > Hmm, I guess you're right. Thanks for the analysis. > > The purpose of the stamp files is to avoid partial files being written > (and screwing up future makes), but if the file is zero bytes, it seems > that problem cannot happen. > > Jim, do you agree? I'll install the change if yes. --thanks, karl. > Fancy doing it? Jim agreed :) Best, sam signature.asc Description: Message signed with OpenPGP
bug#54390: YACC rules don't check DESTDIR existence for VPATH builds
Hi,
It appears that YACC rules don't check for whether the destination directory
exists before executing ylwrap.
When trying to package libaacs (https://code.videolan.org/videolan/libaacs)
with an out-of-source build, I hit an unexpected build failure:
```
/var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/src/file/keydbcfg-parser.y:
warning: fix-its can be applied. Rerun with option '--update'. [-Wother]
/var/tmp/portage/media-libs/libaacs-0.11.1/work/libaacs-0.11.1/build-aux/ylwrap:
206: cannot create ../src/file/keydbcfg-parser.c: Directory nonexistent
updating src/file/keydbcfg-parser.h
mv: cannot move 'tmp-keydbcfg-parser.h' to '../src/file/keydbcfg-parser.h': No
such file or directory
make: *** [Makefile:1150: src/file/keydbcfg-parser.c] Error 2
```
I can workaround this by running `mkdir -p ${BUILD_DIR}/src/file` to ensure
that the necessary directory exists within the build directory beforehand, but
it feels like I shouldn't have to.
Their Makefile.am can be found here:
https://code.videolan.org/videolan/libaacs/-/blob/master/Makefile.am. Snippet:
```
libaacs_la_SOURCES=\
src/libaacs/aacs.h \
[...]
src/file/dirs.h \
src/file/file.h \
src/file/file.c \
src/file/filesystem.h \
src/file/filesystem.c \
src/file/keydbcfg.c \
src/file/keydbcfg.h \
src/file/keydb.h \
src/file/keydbcfg-parser.y \
src/file/keydbcfg-lexer.l \
src/file/mmc_device.h \
[...]
```
While src/libaacs exists within the build dir, src/file/ doesn't exist at all,
hence the failure.
automake yacc rules should mkdir -p the needed directories within the build dir
for VPATH builds before running ylwrap/yacc.
Best,
sam
signature.asc
Description: Message signed with OpenPGP
bug#50469: [bison-3.8] bug or side effect to flex & automake
> On 10 Sep 2021, at 17:40, Akim Demaille wrote:
>
> Hi all,
>
>> Le 9 sept. 2021 à 07:10, Akim Demaille a écrit :
>>
>> Hi!
>>
>>> Le 9 sept. 2021 à 00:32, Paul Eggert a écrit :
>>>
>>> On 9/8/21 2:18 PM, Karl Berry wrote:
Just an idea that I don't expect you to adopt, but just to mention --
you could only institute the breaking change if POSIXLY_CORRECT. That's
why POSIXLY_CORRECT exists. -k
>>>
>>> I like this idea. It insulates us against POSIX decisions and/or
>>> indecisions in this area.
>>
>> Good with me. I'll implement that, thanks Karl!
>
> I will soon push the following commit, and wrap a 3.8.1. Comments most
> welcome!
>
> Cheers!
>
> (a tarball is available here:
>
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.3-84b7.tar.gz
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.3-84b7.tar.lz
> https://www.lrde.epita.fr/~akim/private/bison/bison-3.8.3-84b7.tar.xz)
>
> [snip]
Thanks your work on this! Brief comments on version changes:
> diff --git a/src/getargs.c b/src/getargs.c
> index 697ad7eb..ef559296 100644
> --- a/src/getargs.c
> +++ b/src/getargs.c
> @@ -71,6 +71,18 @@ struct bison_language const *language =
> _languages[0];
>
> typedef int* (xargmatch_fn) (const char *context, const char *arg);
>
> +void
> +set_yacc (location loc)
> +{
> + yacc_loc = loc;
> + if (getenv ("POSIXLY_CORRECT"))
> +muscle_percent_define_insert ("posix",
> + loc,
> + muscle_keyword, "",
> + MUSCLE_PERCENT_DEFINE_D);
> +}
> +
> +
> /** Decode an option's key.
> *
> * \param optoption being decoded.
> @@ -631,8 +643,7 @@ static struct option const long_options[] =
> };
>
> /* Build a location for the current command line argument. */
> -static
> -location
> +static location
> command_line_location (void)
> {
> location res;
> @@ -835,7 +846,7 @@ getargs (int argc, char *argv[])
>
> case 'y':
> warning_argmatch ("yacc", 0, 0);
> -yacc_loc = loc;
> +set_yacc (loc);
> break;
>
> case COLOR_OPTION:
> diff --git a/src/getargs.h b/src/getargs.h
> index a26aec2f..836c1290 100644
> --- a/src/getargs.h
> +++ b/src/getargs.h
> @@ -140,6 +140,7 @@ void getargs (int argc, char *argv[]);
> /* Used by parse-gram.y. */
> void language_argmatch (char const *arg, int prio, location loc);
> void skeleton_arg (const char *arg, int prio, location loc);
> +void set_yacc (location loc);
>
> /** In the string \c s, replace all characters \c from by \c to. */
> void tr (char *s, char from, char to);
> diff --git a/src/parse-gram.c b/src/parse-gram.c
> index 95fe43e0..3bc44dbd 100644
> --- a/src/parse-gram.c
> +++ b/src/parse-gram.c
> @@ -1,4 +1,4 @@
> -/* A Bison parser, made by GNU Bison 3.7.5.297-b46a. */
> +/* A Bison parser, made by GNU Bison 3.8. */
3.8 -> 3.8.1, but I guess this will be automatic :)
>
> /* Bison implementation for Yacc-like parsers in C
>
> @@ -46,10 +46,10 @@
>USER NAME SPACE" below. */
>
> /* Identify Bison output, and Bison version. */
> -#define YYBISON 30705
> +#define YYBISON 30800
Needs adjusting or not?
>
> /* Bison version string. */
> -#define YYBISON_VERSION "3.7.5.297-b46a"
> +#define YYBISON_VERSION "3.8"
>
3.8.1?
> /* Skeleton name. */
> #define YYSKELETON_NAME "yacc.c"
> @@ -3129,7 +3129,7 @@ handle_yacc (location const *loc)
> const char *directive = "%yacc";
> bison_directive (loc, directive);
> if (location_empty (yacc_loc))
> -yacc_loc = *loc;
> +set_yacc (*loc);
> else
> duplicate_directive (directive, yacc_loc, *loc);
> }
> diff --git a/src/parse-gram.h b/src/parse-gram.h
> index 10a63528..77849263 100644
> --- a/src/parse-gram.h
> +++ b/src/parse-gram.h
> @@ -1,4 +1,4 @@
> -/* A Bison parser, made by GNU Bison 3.7.5.297-b46a. */
> +/* A Bison parser, made by GNU Bison 3.8. */
>
> /* Bison interface for Yacc-like parsers in C
>
> @@ -215,6 +215,7 @@ struct GRAM_LTYPE
>
>
>
> +
> int gram_parse (void);
>
> /* "%code provides" blocks. */
> diff --git a/src/parse-gram.y b/src/parse-gram.y
> index 1de83d02..15180cb5 100644
> --- a/src/parse-gram.y
> +++ b/src/parse-gram.y
> @@ -1112,7 +1112,7 @@ handle_yacc (location const *loc)
> const char *directive = "%yacc";
> bison_directive (loc, directive);
> if (location_empty (yacc_loc))
> -yacc_loc = *loc;
> +set_yacc (*loc);
> else
> duplicate_directive (directive, yacc_loc, *loc);
> }
> diff --git a/tests/calc.at b/tests/calc.at
> index 11801543..aeac8418 100644
> --- a/tests/calc.at
> +++ b/tests/calc.at
> @@ -268,7 +268,7 @@ m4_define([AT_CALC_YYLEX(c)],
>
>
> m4_define([_AT_DATA_CALC_Y(c)],
> -[AT_DATA_GRAMMAR([calc.y],
> +[AT_DATA_GRAMMAR([calc.y.tmp],
> [[/* Infix notation calculator--calc */
> ]$4[
> %code requires
> @@ -493,6 +493,18 @@ m4_define([_AT_DATA_CALC_Y(c)],
> [AT_CALC_YYLEX
> AT_CALC_MAIN])])
>
> +# Remove the generated prototypes.
>
