GNU bug report logs - #50985
Merging gnulib for Emacs 28.1?

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Andy Moreton <andrewjmoreton <at> gmail.com>, 50985 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: bug#50985: Merging gnulib for Emacs 28.1?
Date: Wed, 06 Oct 2021 09:23:53 +0200

>>>>> On Tue, 5 Oct 2021 09:16:13 -0700, Paul Eggert <eggert <at> cs.ucla.edu> said:

    Paul> On 10/5/21 7:11 AM, Robert Pluim wrote:
    >> Probably. When it comes to gnulib I prefer to leave it to people who
    >> know what theyʼre doing :-)

    Paul> We can't wait for *that* (:-), so I charged ahead and installed the
    Paul> attached patches into the emacs-28 branch. This fixed the md5_stream
    Paul> issue for me.

Your patch just proves my point: mine was less minimal than it could
have been because I made a mistake in adding crypto/af_alg, then
removing it, and thus having an excessive addition to AVOIDED_MODULES.

    Paul> The key issue here is whether Emacs wants to use cryptography
    Paul> algorithms supported by the Linux kernel, if available. I expect that
    Paul> Emacs doesn't want to bother, because its use of md5_stream is not
    Paul> that performance- or security-relevant and because if we wanted Emacs
    Paul> to use the kernel stuff that'd drag in a lot more Gnulib modules which
    Paul> would be more trouble than it's worth. Comments welcome of course,
    Paul> since this is a judgment call.

Seems sound to me. --with-native-compilation works for me now on
GNU/Linux.

    Paul> I hadn't run into this earlier because I was doing a default
    Paul> configure+build, which on my platform didn't use native compilation.

I donʼt think any platform does native compilation by default (yet?).

Robert
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.