Build failure (master; MS-Windows)

Build failure (master; MS-Windows)

[Dani Moncayo]

gcc -std=gnu99  -mtune=pentium4      -I. -I../src -I../lib
-I/c/cygwin64/home/Dani/devel/emacs/repo/lib-src
-I/c/cygwin64/home/Dani/devel/emacs/repo/lib-src/../src
-I/c/cygwin64/home/Dani/devel/emacs/repo/lib-src/../lib
-mtune=pentium4  -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I
/c/cygwin64/home/Dani/devel/emacs/repo/nt/inc -g3 -O2 -gdwarf-2
/c/cygwin64/home/Dani/devel/emacs/repo/lib-src/emacsclient.c \
   -DVERSION="\"25.0.50\"" ntlib.o ../lib/libgnu.a   \
   -lwsock32 -lcomctl32 -o emacsclient.exe
make[1]: *** No rule to make target
`/c/cygwin64/home/Dani/devel/emacs/repo/lib-src/icons/emacs.ico',
needed by `emacsclient.res'.  Stop.
make[1]: Leaving directory `/home/Dani/devel/emacs/build-master-i686/lib-src'
Makefile:372: recipe for target `lib-src' failed
make: *** [lib-src] Error 2


-- 
Dani Moncayo

Re: Build failure (master; MS-Windows)

[Dani Moncayo]

The previous failure is fixed (thanks).

Now, I get this one:

gcc -std=gnu99  -c -mtune=pentium4  -DGLYPH_DEBUG=1 -DUSE_CRT_DLL=1 -I
/c/cygwin64/home/Dani/devel/emacs/repo/nt/inc -Demacs  -I.
-I/c/cygwin64/home/Dani/devel/emacs/repo/src  -I../lib
-I/c/cygwin64/home/Dani/devel/emacs/repo/lib   -mtune=pentium4
-mms-bitfields -Ic:/mingw/include/librsvg-2.0
-Ic:/mingw/include/glib-2.0 -Ic:/mingw/lib/glib-2.0/include
-Ic:/mingw/include/gdk-pixbuf-2.0 -Ic:/mingw/include/cairo
-Ic:/mingw/include/libpng16 -Ic:/mingw/include/pixman-1
-Ic:/mingw/include/libxml2               -MMD -MF deps/gnutls.d -MP
-Ic:/mingw/include -Ic:/mingw/include/p11-kit-1       -g3 -O2
-gdwarf-2  /c/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:130:1: warning:
'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c: In function
'gnutls_certificate_details':
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:871:26: warning:
initialization makes pointer from integer without a cast [enabled by
default]
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: error:
incompatible type for argument 1 of
'fn_gnutls_x509_crt_get_fingerprint'
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: note:
expected 'gnutls_digest_algorithm_t' but argument is of type
'gnutls_x509_crt_t'
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: warning:
passing argument 2 of 'fn_gnutls_x509_crt_get_fingerprint' makes
pointer from integer without a cast [enabled by default]
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: note:
expected 'const struct gnutls_datum_t *' but argument is of type 'int'
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:958:7: error:
incompatible type for argument 1 of
'fn_gnutls_x509_crt_get_fingerprint'
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:958:7: note:
expected 'gnutls_digest_algorithm_t' but argument is of type
'gnutls_x509_crt_t'
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:958:7: warning:
passing argument 2 of 'fn_gnutls_x509_crt_get_fingerprint' makes
pointer from integer without a cast [enabled by default]
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:958:7: note:
expected 'const struct gnutls_datum_t *' but argument is of type 'int'
Makefile:356: recipe for target `gnutls.o' failed
make[1]: *** [gnutls.o] Error 1
make[1]: Leaving directory
`/home/Dani/devel/emacs/build-master-i686-pc-mingw32/src'
Makefile:384: recipe for target `src' failed
make: *** [src] Error 2



-- 
Dani Moncayo

Re: Build failure (master; MS-Windows)

[Lars Magne Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: error:
> incompatible type for argument 1 of
> 'fn_gnutls_x509_crt_get_fingerprint'

Hm.  Looks like a cut'n'paste error in the Windows function definition
for that function.  Could you check whether the fix I just pushed helps?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Build failure (master; MS-Windows)

[Dani Moncayo]

>> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:954:12: error:
>> incompatible type for argument 1 of
>> 'fn_gnutls_x509_crt_get_fingerprint'
>
> Hm.  Looks like a cut'n'paste error in the Windows function definition
> for that function.  Could you check whether the fix I just pushed helps?

Now I the bootstrap ends without errors, but I still see these warnings:

c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:130:1: warning:
'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c: In function
'gnutls_certificate_details':
c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:871:26: warning:
initialization makes pointer from integer without a cast [enabled by
default]

which were not present in a similar build from 2014-11-08 (for which I
keep the full output of "make").

-- 
Dani Moncayo

Re: Build failure (master; MS-Windows)

[Lars Magne Ingebrigtsen]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Now I the bootstrap ends without errors, but I still see these warnings:
>
> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:130:1: warning:
> 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]

That line has been unchanged there for quite a while, I think.  The
definition here is the same as it is in gnutls 2.12.

> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c: In function
> 'gnutls_certificate_details':
> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:871:26: warning:
> initialization makes pointer from integer without a cast [enabled by
> default]

Fixed now on trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Build failure (master; MS-Windows)

[Dani Moncayo]

>> Now I the bootstrap ends without errors, but I still see these warnings:
>>
>> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:130:1: warning:
>> 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]
>
> That line has been unchanged there for quite a while, I think.  The
> definition here is the same as it is in gnutls 2.12.

Ok, I've now realized that I updated my GnuTLS library on 2014-11-10,
from version 3.0.9 to 3.3.9:

  ftp://ftp.gnutls.org/gcrypt/gnutls/w32/gnutls-3.3.9-w32.zip

I guess that explains the warning.

Thanks.

-- 
Dani Moncayo

proposal: require GnuTLS 3.1.x (previous stable) (was: Build failure (master; MS-Windows))

[Ted Zlatanov]

On Mon, 24 Nov 2014 00:09:40 +0100 Dani Moncayo <dmoncayo@gmail.com> wrote: 

>>> Now I the bootstrap ends without errors, but I still see these warnings:
>>> 
>>> c:/cygwin64/home/Dani/devel/emacs/repo/src/gnutls.c:130:1: warning:
>>> 'gnutls_connection_end_t' is deprecated [-Wdeprecated-declarations]
>> 
>> That line has been unchanged there for quite a while, I think.  The
>> definition here is the same as it is in gnutls 2.12.

DM> Ok, I've now realized that I updated my GnuTLS library on 2014-11-10,
DM> from version 3.0.9 to 3.3.9:

DM>   ftp://ftp.gnutls.org/gcrypt/gnutls/w32/gnutls-3.3.9-w32.zip

DM> I guess that explains the warning.

Maintainers: we're now targeting Emacs 25 in the master branch and 3.3.x
is the "next stable" version of GnuTLS. I think we should require GnuTLS
3.1.x ("previous stable") instead of 2.6.6 as we do now. In the C
source, that would make HAVE_GNUTLS3 always true, and we'll also may add
HAVE_GNUTLS3_2 and HAVE_GNUTLS3_3 (or special macros for each feature we
need).

Conditionally supporting GnuTLS 2.6.6 is a pain because many functions
were added since then. It complicates the code significantly today and
for the future, possibly hiding bugs in the compatibility layers. We're
already starting to see these compilation issues in the bug tracker and
on emacs-devel and it would be nice to cut the cord now.

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Conditionally supporting GnuTLS 2.6.6 is a pain because many functions
> were added since then. It complicates the code significantly today and
> for the future, possibly hiding bugs in the compatibility layers. We're
> already starting to see these compilation issues in the bug tracker and
> on emacs-devel and it would be nice to cut the cord now.

I think it'll be many years before there is a non-significant number of
gnutls 2.x users out there.  The current Debian Stable uses 2.12, and
the various LTS versions of the different GNU/Linux distributions will
remain on 2.x for a Long Time, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Tue, 25 Nov 2014 16:57:06 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Conditionally supporting GnuTLS 2.6.6 is a pain because many functions
>> were added since then. It complicates the code significantly today and
>> for the future, possibly hiding bugs in the compatibility layers. We're
>> already starting to see these compilation issues in the bug tracker and
>> on emacs-devel and it would be nice to cut the cord now.

LMI> I think it'll be many years before there is a non-significant number of
LMI> gnutls 2.x users out there.  The current Debian Stable uses 2.12, and
LMI> the various LTS versions of the different GNU/Linux distributions will
LMI> remain on 2.x for a Long Time, I think.

Bah. Users. OK. Is there a Hydra build job with GnuTLS for those
platforms? It would be nice to get build job failures.

Ted

Buildbot for Emacs? (was: proposal: require GnuTLS 3.1.x (previous stable))

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Bah. Users. OK. Is there a Hydra build job with GnuTLS for those
> platforms? It would be nice to get build job failures.

Yes, that would be really really helpful when fiddling with this stuff.
A range of GNU/Linux distributions, new and old, as well as Windows and
OS X.

Err...  didn't somebody do that already?  Or was there just discussion
about this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Buildbot for Emacs?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> A range of GNU/Linux distributions, new and old, as well as Windows and
> OS X.

> Err...  didn't somebody do that already? 

GNU/Linux and OS X:

http://hydra.nixos.org/jobset/gnu/emacs-trunk

If you want to add MS Windows, and older GNU/Linux distributions, you'll
have to do that yourself somewhere else (because the machinery can't do
that). But you can never test every combination.

Re: Buildbot for Emacs?

[Ted Zlatanov]

On Tue, 25 Nov 2014 11:50:59 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Lars Magne Ingebrigtsen wrote:
>> A range of GNU/Linux distributions, new and old, as well as Windows and
>> OS X.

>> Err...  didn't somebody do that already? 

GM> GNU/Linux and OS X:

GM> http://hydra.nixos.org/jobset/gnu/emacs-trunk

GM> If you want to add MS Windows, and older GNU/Linux distributions, you'll
GM> have to do that yourself somewhere else (because the machinery can't do
GM> that). But you can never test every combination.

Can we specify a different version of GnuTLS?  It could even be a Git
checkout.

Ted

Re: Buildbot for Emacs?

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> GNU/Linux and OS X:
>
> http://hydra.nixos.org/jobset/gnu/emacs-trunk

Nice.

> If you want to add MS Windows, and older GNU/Linux distributions, you'll
> have to do that yourself somewhere else (because the machinery can't do
> that). But you can never test every combination.

I poked around on the site, and I couldn't seem to find the gnutls.c
breakage you reported, so I guess that means that the distribution it's
running on is newer?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Stefan Monnier]

> It would be nice to get build job failures.

Oh, that one is easy, just add some random garbage to your
favorite file.


        Stefan

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ivan Shmakov]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:

 >> Conditionally supporting GnuTLS 2.6.6 is a pain because many
 >> functions were added since then.  It complicates the code
 >> significantly today and for the future, possibly hiding bugs in the
 >> compatibility layers.  We're already starting to see these
 >> compilation issues in the bug tracker and on emacs-devel and it
 >> would be nice to cut the cord now.

 > I think it'll be many years before there is a non-significant number
 > of gnutls 2.x users out there.  The current Debian Stable uses 2.12,

	Yet Jessie is already frozen, so I guess we may see Debian 8
	released in the first half (if not quarter) of 2015.

	Personally, I’d suggest retaining GnuTLS 2 support until a month
	or two after that at the least.

 > and the various LTS versions of the different GNU/Linux distributions
 > will remain on 2.x for a Long Time, I think.

	Yes, although I’d rather question the necessity of building
	Emacs ‘master’ on an LTS GNU/Linux system.  If the intent is to
	use the last decade’s versions of Libc and Coreutils, – why
	Emacs has to be newer than that?

	Especially given that the older versions of the system, when
	necessary to support legacy software, could be just as well be
	run in chroot(2) environments.  (Or even be entirely “virtual.”)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: Buildbot for Emacs?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> I poked around on the site, and I couldn't seem to find the gnutls.c
> breakage you reported, so I guess that means that the distribution it's
> running on is newer?

If you look at eg

http://hydra.nixos.org/build/17567066#tabs-build-deps

(or the raw build log)

you'll see it used gnutls 3.2.17.

Re: Buildbot for Emacs?

[Glenn Morris]

Ted Zlatanov wrote:

> Can we specify a different version of GnuTLS?  It could even be a Git
> checkout.

I imagine it is technically possible, but the system is already
overloaded and not updating as often as it should, so this would have to
be instead of the current version rather than in addition to. I don't
see much point in simply trading one version of one of the many
libraries that Emacs can use for another version.

If you think about all the different ways Emacs can be compiled: without
X, with gtk2, with gtk3, with motif, with athena; and then about all the
different libraries it can use or not use; and then start adding
different versions of those libraries into the mix; and then about all
the platforms it can be built on...

Maybe someone has the resources to deal with all of that, and rebuild
all those versions multiple times a day - good luck to them! :)

Re: Buildbot for Emacs?

[Ted Zlatanov]

On Tue, 25 Nov 2014 17:15:05 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Maybe someone has the resources to deal with all of that, and rebuild
GM> all those versions multiple times a day - good luck to them! :)

I hope hydra gets the resources it needs.  Is it a donated or rented
resource?

I considered running my own Buildbot for Emacs but the time and cost
were indeed too much for me personally.

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Peder O. Klingenberg]

On Tue, Nov 25 2014 at 18:55, Ivan Shmakov wrote:

> 	Yes, although I’d rather question the necessity of building
> 	Emacs ‘master’ on an LTS GNU/Linux system.  If the intent is to
> 	use the last decade’s versions of Libc and Coreutils, – why
> 	Emacs has to be newer than that?

Because features.  My desktop machine runs Kubuntu 10.04 still, because
it mostly does what I need without needing my attention all the time, it
is a stable platform I can use to get work done.

There is no conscious desire to run old software for nostalgias sake,
more a lack of desire to upgrade willy-nilly with the associated
breakage-fixing and retraining of muscle memory because some dimwits
decided to reinvent everything badly.

I do most of my work in Emacs.  That means I care about it more than I
care about this months desktop fad, the latest and greatest in init
systems, or whatever fancy gui+daemon should be used to dynamically
configure the network on my perfectly stationary, hardwired desktop
machine.

I started building emacs from trunk because the repository version had
features I wanted.  Mostly --daemon, which is a killer feature and a
real productivity boost for me, and which was not available in the
distro-packaged emacs.  I was willing to invest the time and effort
involved to get a better emacs, but I was, and am, reluctant to upgrade
the bits of the machine that work just fine.

> 	Especially given that the older versions of the system, when
> 	necessary to support legacy software, could be just as well be
> 	run in chroot(2) environments.  (Or even be entirely “virtual.”)

It's not about legacy software.  It's about how I choose to spend my
limited time.  Playing sysadmin was really exciting back when I
installed slackware from a stack of floppies.  These days, time spent
maintaining the OS is time not spent doing what they pay me to do, and
what I enjoy doing - develop software.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: Buildbot for Emacs?

[Tom]

Glenn Morris <rgm <at> gnu.org> writes:


> Maybe someone has the resources to deal with all of that, and rebuild
> all those versions multiple times a day - good luck to them! :)
> 

Never used it, but can't Travis CI be used for this?

AFAIK it's free for open source projects: https://travis-ci.org/

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ivan Shmakov]

>>>>> Peder O Klingenberg <peder@news.klingenberg.no> writes:
>>>>> On Tue, Nov 25 2014 at 18:55, Ivan Shmakov wrote:

 >> Yes, although I’d rather question the necessity of building Emacs
 >> ‘master’ on an LTS GNU/Linux system.  If the intent is to use the
 >> last decade’s versions of Libc and Coreutils, – why Emacs has to be
 >> newer than that?

 > Because features.  My desktop machine runs Kubuntu 10.04 still,
 > because it mostly does what I need without needing my attention all
 > the time, it is a stable platform I can use to get work done.

 > There is no conscious desire to run old software for nostalgias sake,
 > more a lack of desire to upgrade willy-nilly with the associated
 > breakage-fixing and retraining of muscle memory because some dimwits
 > decided to reinvent everything badly.

 > I do most of my work in Emacs.  That means I care about it more than
 > I care about this months desktop fad, the latest and greatest in init
 > systems, or whatever fancy gui+daemon should be used to dynamically
 > configure the network on my perfectly stationary, hardwired desktop
 > machine.

	I understand the sentiment.  However, my own (free) advice for
	this case would be to switch to (non-LTS) Debian and Openbox.

	The Debian’s commitment to non-Linux variants of the GNU system
	(including GNU proper), combined with the Systemd maintainers’
	well-known decision not to care about such systems at all,
	effectively means that Debian is bound to continue its support
	for our good old SysV init in the foreseeable future.  (And why,
	I’ve just got a fresh install of SysVinit-based Jessie running
	in a QEMU/KVM environment.  No issues observed so far.)

	At the same time, Openbox appears to offer unparalleled
	stability when it comes to the UI.  The only major UI change I
	can readily recall to happen since I’ve switched to it ca. 2008
	is that the list shown when switching windows was changed to be
	strictly vertical (previously it was columns-and-rows.)

	Formerly, I’ve experimented with FVWM, TWM, WindowMaker; and
	even (ca. 2000) the then-nascent KDE and GNOME – both of which
	I’ve found rather boring and lacking any substance, so to say.

 > I started building emacs from trunk because the repository version
 > had features I wanted.  Mostly --daemon, which is a killer feature
 > and a real productivity boost for me, and which was not available in
 > the distro-packaged emacs.  I was willing to invest the time and
 > effort involved to get a better emacs, but I was, and am, reluctant
 > to upgrade the bits of the machine that work just fine.

	I mainly use Emacs under Screen, which means that I’m having at
	least some benefits of --daemon since the Emacs 20 days.

	To me, running the latest development version of Emacs means
	that I can try its new features one at a time (more or less),
	instead of having them being forced upon me a pile at once.

 >> Especially given that the older versions of the system, when
 >> necessary to support legacy software, could be just as well be run
 >> in chroot(2) environments.  (Or even be entirely “virtual.”)

 > It's not about legacy software.  It's about how I choose to spend my
 > limited time.

	There’re valid cases where upgrading the system breaks the
	software one relies upon, and the cost of fixing these issues
	properly (be it time or money) is just too high.  This is what
	forced me to gain some experience with chroots and the like.

 > Playing sysadmin was really exciting back when I installed slackware
 > from a stack of floppies.  These days, time spent maintaining the OS
 > is time not spent doing what they pay me to do, and what I enjoy
 > doing - develop software.

	Alas, some of the things I do require the use of software other
	than Emacs, which warrants keeping my systems reasonably up to
	date.  (Although it sure got easier ever since Emacs got EWW,
	and I’ve got the VC MediaWiki backend working, too.  What’s even
	better is that there are still a few unexplored packages,
	including ELPA ones, which look rather promising…)

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Wed, 26 Nov 2014 10:14:12 +0100 peder@news.klingenberg.no (Peder O. Klingenberg) wrote: 

POK> On Tue, Nov 25 2014 at 18:55, Ivan Shmakov wrote:
>> Yes, although I’d rather question the necessity of building
>> Emacs ‘master’ on an LTS GNU/Linux system.  If the intent is to
>> use the last decade’s versions of Libc and Coreutils, – why
>> Emacs has to be newer than that?

POK> Because features.  My desktop machine runs Kubuntu 10.04 still, because
POK> it mostly does what I need without needing my attention all the time, it
POK> is a stable platform I can use to get work done.

Peder, your whole argument could have applied to supporting GnuTLS 1.x
back when we added support for 2.x the first time, because people still
used it and didn't want to upgrade their system.  Inertia is not a bad
thing, but we're talking about the master branch of The Most Advanced
Editor Ever Invented(TM).  Sacrifices must be made :)

Supporting older versions of GnuTLS is not like supporting older PNG or
XML parsers and such. I want to point out that supporting older GnuTLS
libraries carries actual risk for all users, like this scenario:

1) support for 2.x requires a specific contortion in the code
2) inadvertently the developers apply this contortion to 3.x as well
3) 3.x users get bug/security hole surprise

or this one:

1) both 2.x and 3.x are installed (yes, it happens)
2) the user inadvertently compiles with 2.x
3) the user gets bug/security hole surprise

I'm sure we can argue about this for a while, but I personally would
just like to set a cutover date where GnuTLS 2.x is not supported, not
debate convenience and featuritis. How about Emacs 26?

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Michael Welsh Duggan]

peder@news.klingenberg.no (Peder O. Klingenberg) writes:

> On Tue, Nov 25 2014 at 18:55, Ivan Shmakov wrote:
>
>> 	Yes, although I’d rather question the necessity of building
>> 	Emacs ‘master’ on an LTS GNU/Linux system.  If the intent is to
>> 	use the last decade’s versions of Libc and Coreutils, – why
>> 	Emacs has to be newer than that?
>
> Because features.  My desktop machine runs Kubuntu 10.04 still, because
> it mostly does what I need without needing my attention all the time, it
> is a stable platform I can use to get work done.
>
> There is no conscious desire to run old software for nostalgias sake,
> more a lack of desire to upgrade willy-nilly with the associated
> breakage-fixing and retraining of muscle memory because some dimwits
> decided to reinvent everything badly.

Moreover, not everyone has complete control over their desktop.  At work
we have RHEL6.  I build Emacs for my own use.  I could build gnutls as
well, but my (recent) experience of that is hellish.  gnutls requires
nettle and gmp.  I build nettle, and then find out that gnutls doesn't
support the latest nettle.  So I grab an older nettle and build that.
Then it complains about HOGWEED.  Oh, libgmp needs to be installed
_before_ nettle is built to get HOGWEED.  I wish that had been
mentioned.  At this point, I give up for the day because I have to get
real work done.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Peder O. Klingenberg]

On Wed, Nov 26 2014 at 12:57, Ivan Shmakov wrote:

> 	I understand the sentiment.  However, my own (free) advice for
> 	this case would be to switch to (non-LTS) Debian and Openbox.

Perhaps when I switch hardware and am forced to mess with the OS anyway.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Peder O. Klingenberg]

On Wed, Nov 26 2014 at 08:08, Ted Zlatanov wrote:

> Peder, your whole argument could have applied to supporting GnuTLS 1.x
> back when we added support for 2.x the first time, because people still
> used it and didn't want to upgrade their system.  Inertia is not a bad
> thing, but we're talking about the master branch of The Most Advanced
> Editor Ever Invented(TM).  Sacrifices must be made :)

I'm not arguing against requiring a newer GnuTLS.  Far from it.  I have
no deep opinions on the subject.  Please don't read any such resistance
into anything I wrote.

Ivan asked why anyone would build master on an old system.  I merely
offered my rationalisations for doing so.

> I'm sure we can argue about this for a while, but I personally would
> just like to set a cutover date where GnuTLS 2.x is not supported, not
> debate convenience and featuritis. How about Emacs 26?

No need to argue with me, at least.  The maintenance burden for
supporting older libraries is obvious.  A cutover date of "tomorrow"
would be fine by me.

For my part, I'm fairly confident that I'll be able to aquire the
required version of GnuTLS, should my distribution not supply it.  That
is a burden I accept by running my system as I do.  If it turns out I'm
wrong, and compiling GnuTLS causes problems, then that will be a reason
to upgrade my distribution.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Stefan Monnier]

> 1) support for 2.x requires a specific contortion in the code

AFAICT, there's no such contortions yet.  The needed ifdefs are fairly
simple and clean.

> 1) both 2.x and 3.x are installed (yes, it happens)
> 2) the user inadvertently compiles with 2.x
> 3) the user gets bug/security hole surprise

That doesn't sound very likely either, so I'm not worried about that risk.

> I'm sure we can argue about this for a while, but I personally would
> just like to set a cutover date where GnuTLS 2.x is not supported, not
> debate convenience and featuritis. How about Emacs 26?

We usually consider it OK to drop support for things that are "older
than Debian stable" or thereabout.  But usually it depends a lot on the
cost of maintaining this backward compatibility.  In this case, the cost
seems to be very reasonable, so I see no reason to drop support for
GnuTLS2 at this stage.  Those tradeoffs change over time, so by Emacs-26
it's quite likely that we'll get rid of GnuTLS2 support, indeed.


        Stefan

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Wed, 26 Nov 2014 10:42:37 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

SM> We usually consider it OK to drop support for things that are "older
SM> than Debian stable" or thereabout.  But usually it depends a lot on the
SM> cost of maintaining this backward compatibility.  In this case, the cost
SM> seems to be very reasonable, so I see no reason to drop support for
SM> GnuTLS2 at this stage.  Those tradeoffs change over time, so by Emacs-26
SM> it's quite likely that we'll get rid of GnuTLS2 support, indeed.

OK, so let's reevaluate then.  For now we'll continue supporting the 2.x
versions we do now.  It would be extremely helpful to have an easy way
to test Emacs compilation and functionality with ERT, perhaps in a
Vagrantfile or in Hydra or Travis or whatever.

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Wed, 26 Nov 2014 11:52:32 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 26 Nov 2014 10:42:37 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 
SM> We usually consider it OK to drop support for things that are "older
SM> than Debian stable" or thereabout.  But usually it depends a lot on the
SM> cost of maintaining this backward compatibility.  In this case, the cost
SM> seems to be very reasonable, so I see no reason to drop support for
SM> GnuTLS2 at this stage.  Those tradeoffs change over time, so by Emacs-26
SM> it's quite likely that we'll get rid of GnuTLS2 support, indeed.

TZ> OK, so let's reevaluate then.  For now we'll continue supporting the 2.x
TZ> versions we do now.  It would be extremely helpful to have an easy way
TZ> to test Emacs compilation and functionality with ERT, perhaps in a
TZ> Vagrantfile or in Hydra or Travis or whatever.

FWIW, I just got a note about this on gnutls-devel that strongly
suggests supporting GnuTLS 3.x only:

http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7811

I don't know if it changes anyone's mind :)

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> FWIW, I just got a note about this on gnutls-devel that strongly
> suggests supporting GnuTLS 3.x only:
>
> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7811
>
> I don't know if it changes anyone's mind :)

It depends on what the recommendation is based on.  :-)  Since gnutls 2.x
is in all the LTS systems, and is in Debian Stable, you'd think they
would be getting security patches.

But you know security peeps...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Stefan Monnier]

> FWIW, I just got a note about this on gnutls-devel that strongly
> suggests supporting GnuTLS 3.x only:

> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7811

Either you posted the wrong link or we disagree about what it says.
My reading of it doesn't say that we should only support GnuTLS-3.x, but
that we should start supporting GnuTLS-3.x ASAP.


        Stefan

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Wed, 26 Nov 2014 21:13:58 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> FWIW, I just got a note about this on gnutls-devel that strongly
>> suggests supporting GnuTLS 3.x only:

>> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7811

SM> Either you posted the wrong link or we disagree about what it says.
SM> My reading of it doesn't say that we should only support GnuTLS-3.x, but
SM> that we should start supporting GnuTLS-3.x ASAP.

I guess we disagree on what it says.

Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Ted Zlatanov]

On Wed, 26 Nov 2014 21:13:58 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> FWIW, I just got a note about this on gnutls-devel that strongly
>> suggests supporting GnuTLS 3.x only:

>> http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7811

SM> Either you posted the wrong link or we disagree about what it says.
SM> My reading of it doesn't say that we should only support GnuTLS-3.x, but
SM> that we should start supporting GnuTLS-3.x ASAP.

I asked for clarification; please see the followup from Nikos (and his
previous message):

http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7814

"Whether you need to support gnutls 2.12.x is up to you. However, I note
that this version is totally unsupported, if it is broken or has a
critical bug you are on your own."

I hope that helps clarify things and perhaps convince you and others
that we should stop supporting GnuTLS 2.6.6 (the current minimum) or any
other 2.x GnuTLS release with Emacs 25.

Thanks
Ted

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Stefan Monnier]

> "Whether you need to support gnutls 2.12.x is up to you.  However, I note
> that this version is totally unsupported, if it is broken or has a
> critical bug you are on your own."

Emacs doesn't use GnuTLS, the end-user does.  I don't think it's Emacs's
role to coerce the user into upgrading her libgnutls.

> I hope that helps clarify things and perhaps convince you and others
> that we should stop supporting GnuTLS 2.6.6 (the current minimum) or any
> other 2.x GnuTLS release with Emacs 25.

No, I still think the burden of supporting 2.6.6 is currently smaller
than the cost of not supporting it.


        Stefan

Re: proposal: require GnuTLS 3.1.x (previous stable)

[Glenn Morris]

Ted Zlatanov wrote:

> "Whether you need to support gnutls 2.12.x is up to you. However, I note
> that this version is totally unsupported, if it is broken or has a
> critical bug you are on your own."

Unsupported by _upstream_ gnutls.

However, it is part of the function of LTS distributions to backport
security patches to the versions that they include (or if that is
impossible to update to newer versions). Eg I can assure you that this
is what Red Hat will do for RHEL6 (it was in the context of RHEL6 that
this issue first came up). Debian security, Ubuntu LTS, they all do the
same kind of thing.

It's not Emacs's problem, and not your problem, to worry about these things.
Emacs should just (generally speaking) support whatever library versions
the commonly used distributions support, and let the distributions worry
about security issues in those libraries.