GNU bug report logs - #24857
emacs24/25 FTBFS since a long time on GNU/Hurd

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24857 in the body.
You can then email your comments to 24857 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bug reports and feature requests <bug-gnu-emacs <at> gnu.org>
Cc: Svante Signell <svante.signell <at> gmail.com>
Subject: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 2 Nov 2016 08:20:59 -0700

[forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]

From: Svante Signell <svante.signell <at> gmail.com>
To: emacs-devel <at> gnu.org
Date: Wed, 02 Nov 2016 15:16:54 +0100

Since a long time emacs FTBFS due to unknown reasons. The latest version
building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
were by pure luck. One suspicious issue is that emacs use sbrk() for memory
allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which are
all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
no.patch did not improve the situation.

First time I compiled emacs 25.1 from upstream it passed, second time not.
Compiling Debian versions almost always fail. Moslty the build fails with temacs
failing to execute: Killed. In my opionion it's a real loss not to gave a modern
version of emacs25 available for use in GNU/Hurd (not everybody use vi).

Do anybody of you have an idea on how to solve this problem? Are there patches
available already to try with?

Thanks in advance :)

Message #12 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 24857 <at> debbugs.gnu.org
Subject: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 2 Nov 2016 09:43:41 -0700

-------- Forwarded Message --------
Subject: 	Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: 	Wed, 02 Nov 2016 17:39:51 +0200
From: 	Eli Zaretskii <eliz <at> gnu.org>
Reply-To: 	Eli Zaretskii <eliz <at> gnu.org>
To: 	svante.signell <at> gmail.com
CC: 	emacs-devel <at> gnu.org



> From: Svante Signell <svante.signell <at> gmail.com>
> Date: Wed, 02 Nov 2016 15:16:54 +0100
>
> First time I compiled emacs 25.1 from upstream it passed, second time not.
> Compiling Debian versions almost always fail. Moslty the build fails with temacs
> failing to execute: Killed. In my opionion it's a real loss not to gave a modern
> version of emacs25 available for use in GNU/Hurd (not everybody use vi).
>
> Do anybody of you have an idea on how to solve this problem?

My suggestion is to run the failing temacs command line under GDB and
see where it crashes.

The best way to communicate this information is to file a bug report,
using "M-x report-emacs-bug RET" (in some version of Emacs you have
that is operable; if not, just email the details to
bug-gnu-emacs <at> gnu.org).

Message #15 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 24857 <at> debbugs.gnu.org
Subject: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 2 Nov 2016 09:44:14 -0700

[Message part 1 (text/plain, inline)]

-------- Forwarded Message --------
Subject: 	Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: 	Wed, 02 Nov 2016 16:51:44 +0100
From: 	Svante Signell <svante.signell <at> gmail.com>
Reply-To: 	svante.signell <at> gmail.com
Organization: 	Home
To: 	Eli Zaretskii <eliz <at> gnu.org>
CC: 	emacs-devel <at> gnu.org



On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> >
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Date: Wed, 02 Nov 2016 15:16:54 +0100
> >
> > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > Compiling Debian versions almost always fail. Moslty the build fails with
> > temacs
> > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > modern
> > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> >
> > Do anybody of you have an idea on how to solve this problem?
> My suggestion is to run the failing temacs command line under GDB and
> see where it crashes.

Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
indicated in that file.

> The best way to communicate this information is to file a bug report,
> using "M-x report-emacs-bug RET" (in some version of Emacs you have
> that is operable; if not, just email the details to
> bug-gnu-emacs <at> gnu.org).

A bug was already filed by Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cg
i?bug=24857

Thanks anyway.

[gdb_edited.txt (text/plain, attachment)]

Message #18 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: svante.signell <at> gmail.com, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 02 Nov 2016 18:46:06 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 2 Nov 2016 08:20:59 -0700
> Cc: Svante Signell <svante.signell <at> gmail.com>
> 
> [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]
> 
> From: Svante Signell <svante.signell <at> gmail.com>
> To: emacs-devel <at> gnu.org
> Date: Wed, 02 Nov 2016 15:16:54 +0100
> 
> Since a long time emacs FTBFS due to unknown reasons. The latest version
> building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
> were by pure luck. One suspicious issue is that emacs use sbrk() for memory
> allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
> glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which are
> all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
> no.patch did not improve the situation.

The posted backtrace indicates the problem is with inability to
allocate memory:

  #374452 0x0521d7bf in __assert_perror_fail (errnum=1073741836, file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert-perr.c:35
	  errbuf = "\001\000\000\000\300r\375\001@\311\002\001'\336\000\000\360\333\000\000Ð\225\000\000\240\061\035\005\240\061\035\005\001\000\000\000\024\312\002\001\000 \000\000\000\000\000\000\001\000\000\000v\032i\t\000\000\000\000\000\000\000\000\251\224\000\000\000\260\002\000\f\001\034\005\330\310\350\004\236\002\000\000Ë\235\000\000\005\000\000\000\001\000\000\000$I\034\005\020\225\000\000\310/\374\a;\316\034\005$\312\002\001 \312\002\001\000 \000\000\310\f\004\b}\000\000\000;\316\034\005\223\365\034\005j\315yy\251\224\000\000\000\260\002\000<\020\374\ax\204\336\a\375\000\000\000Ë\235\000\000\005\000\000\000\001\000\000\000d!\374\aÐ\225\000\000\255\062\035\005\255\062\035\005t\312\002\001p\312\002\001\240\061\035\005"...
	  e = 0x53646db "Cannot allocate memory"
  #374453 0x0516bb99 in _init_routine (stack=0x0) at ../libpthread/sysdeps/mach/hurd/pt-sysdep.c:67
	  thread = 0x0
	  err = <optimized out>
	  attr = {__schedparam = {__sched_priority = 0}, __stackaddr = 0x7, __stacksize = 1, __guardsize = 85910395, __detachstate = (unknown: 87916512), __inheritsched = (unknown: 3084914), __contentionscope = (unknown: 1866732), __schedpolicy = 85375740}
	  attrp = 0x0
  #374454 0x05210a33 in init (data=0x102cdf0) at ../sysdeps/mach/hurd/i386/init-first.c:213

Btw, what happened between frame #0 and frame #374454?  Was that some
infinite loop trying to print an error message, which caused an
attempt to allocate memory, which tried to print an error message, and
so on and so forth?

Message #21 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 02 Nov 2016 18:38:45 +0100

On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
> > 
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Wed, 2 Nov 2016 08:20:59 -0700
> > Cc: Svante Signell <svante.signell <at> gmail.com>
> > 
> > [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg000
> > 55.html]
> > 
> > From: Svante Signell <svante.signell <at> gmail.com>
> > To: emacs-devel <at> gnu.org
> > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > 
> The posted backtrace indicates the problem is with inability to
> allocate memory:

Yes!

> Btw, what happened between frame #0 and frame #374454?  Was that some
> infinite loop trying to print an error message, which caused an
> attempt to allocate memory, which tried to print an error message, and
> so on and so forth?

#16 0x0521d6f4 in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c
", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at 
assert.c:92
        str = 0x0
        total = 86103528
#17 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:
101
No locals.
#18 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#19 0x05224e8e in raise (signo=6) at
../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#20 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction =
0x519369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32

#16+17+18+19+20 loops from here:...

That was a bug in raise looping indefinitely due to a failed assertion, now
fixed.

Message #24 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: 24857 <at> debbugs.gnu.org
Subject: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Fri, 04 Nov 2016 21:17:24 +0100

Hello,

In order for you to try out the FTBFS problems of emacs24/25 on
GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
do that would be to read:
https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
or using a pre-installed image: (3GiB)
tinyurl.com/6dyly5d
containing debian-hurd.img.tar.gz

Message #27 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Thu, 10 Nov 2016 12:57:56 +0100

On Wed, 2016-11-02 at 18:38 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
...
> > The posted backtrace indicates the problem is with inability to
> > allocate memory:
> Yes!

More info: Forcing the use of SYSTEM_MALLOC instead of GNU_MALLOC and commenting
out sbrk usage in alloc.c and unexelf.c as in https://debbugs.gnu.org/cgi/bugrep
ort.cgi?bug=24892#15 temacs does no longer freak out (Killed). Looking at the
build log vm-limit.c and gmalloc.c are no longer compiled.

Now there is a SEGFAULT in dumped-emacs:

/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[4]: Entering directory '/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-
x/lisp'
  ELC      emacs-lisp/macroexp.elc
/bin/bash: line 1: 27157 Segmentation fault      EMACSLOADPATH=
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval "(setq max-
lisp-eval-depth 2200)" --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el

I've traced it down to the make_float() function in alloc.c:
if (float_free_list = 0x0) <FALSE>
if (float_block_index=27 == FLOAT_BLOCK_SIZE=124): <FALSE>
Next statement: XSETFLOAT (val, &float_block->floats[float_block_index]);
is called with an invalid address:
(gdb) p float_block
$2 = (struct float_block *) 0xad8c00
(gdb) p *float_block
Cannot access memory at address 0xad8c00
causing the segfault later on.

Is the static struct float_block *float_block allocated on the heap?
0xad8c00 = 10.847 MiB is much smaller that available memory.

Message #30 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Thu, 10 Nov 2016 18:00:56 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: 24857 <at> debbugs.gnu.org
> Date: Thu, 10 Nov 2016 12:57:56 +0100
> 
> More info: Forcing the use of SYSTEM_MALLOC instead of GNU_MALLOC and commenting
> out sbrk usage in alloc.c and unexelf.c as in https://debbugs.gnu.org/cgi/bugrep
> ort.cgi?bug=24892#15 temacs does no longer freak out (Killed). Looking at the
> build log vm-limit.c and gmalloc.c are no longer compiled.
> 
> Now there is a SEGFAULT in dumped-emacs:
> 
> /usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
> make[4]: Entering directory '/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-
> x/lisp'
>   ELC      emacs-lisp/macroexp.elc
> /bin/bash: line 1: 27157 Segmentation fault      EMACSLOADPATH=
> '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval "(setq max-
> lisp-eval-depth 2200)" --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
> emacs-lisp/macroexp.el
> 
> I've traced it down to the make_float() function in alloc.c:
> if (float_free_list = 0x0) <FALSE>
> if (float_block_index=27 == FLOAT_BLOCK_SIZE=124): <FALSE>
> Next statement: XSETFLOAT (val, &float_block->floats[float_block_index]);
> is called with an invalid address:
> (gdb) p float_block
> $2 = (struct float_block *) 0xad8c00
> (gdb) p *float_block
> Cannot access memory at address 0xad8c00
> causing the segfault later on.
> 
> Is the static struct float_block *float_block allocated on the heap?
> 0xad8c00 = 10.847 MiB is much smaller that available memory.

Sounds like the memory-related problems are not over yet.

Did you try to invoke temacs, and work in that?  IOW, try this:

  ./src/temacs -Q

It will load a bunch pf Lisp files, and should then present a normal
frame, where you should be able to work as usual.  If that does work
on Hurd, I'm pretty sure the problem is with unexec and dumping Emacs.

Message #33 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Thu, 10 Nov 2016 21:35:53 +0100

On Thu, 2016-11-10 at 18:00 +0200, Eli Zaretskii wrote:
> > 
> Did you try to invoke temacs, and work in that?  IOW, try this:
> 
>   ./src/temacs -Q
> 
> It will load a bunch pf Lisp files, and should then present a normal
> frame, where you should be able to work as usual.  If that does work
> on Hurd, I'm pretty sure the problem is with unexec and dumping Emacs.

I get with ./temacs -Q -nw a frame and on the bottom line:
emacs-x is built first in the Debian build 25.1-2:

logging in to the kvm box with ssh ... gives

Symbol’s function definition is void: internal-echo-keystrokes-prefix
and then a freeze

logging in with ssh -Y ... gives
Loading loadup.el (source)...
Using load-path (/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/lisp)-------
----------
Loading emacs-lisp/byte-run (source)...nternal-echo-keystrokes-prefix
Loading emacs-lisp/byte-run (source)...done
Loading emacs-lisp/backquote (source)...
Loading emacs-lisp/backquote (source)...done
Loading subr (source)...
Loading subr (source)...done
Loading version (source)...
Symbol’s function definition is void: pcase

Message #36 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 09:48:34 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Thu, 10 Nov 2016 21:35:53 +0100
> 
> I get with ./temacs -Q -nw a frame and on the bottom line:
> emacs-x is built first in the Debian build 25.1-2:

Why did you use -nw?  I meant for you to try the usual GUI session.

> logging in to the kvm box with ssh ... gives
> 
> Symbol’s function definition is void: internal-echo-keystrokes-prefix
> and then a freeze
> 
> logging in with ssh -Y ... gives
> Loading loadup.el (source)...
> Using load-path (/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/lisp)-------
> ----------
> Loading emacs-lisp/byte-run (source)...nternal-echo-keystrokes-prefix
> Loading emacs-lisp/byte-run (source)...done
> Loading emacs-lisp/backquote (source)...
> Loading emacs-lisp/backquote (source)...done
> Loading subr (source)...
> Loading subr (source)...done
> Loading version (source)...
> Symbol’s function definition is void: pcase

Are you building from the Git repository?  If so, don't: doing that
requires byte-compiling all the Lisp files, which would be difficult
given your problems.

Instead, try building an official 25.1 release tarball, then invoke
temacs built there, and see if it works.

Message #39 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 10:50:16 +0100

On Fri, 2016-11-11 at 09:48 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> > Date: Thu, 10 Nov 2016 21:35:53 +0100
> > 
> > 
> Are you building from the Git repository?  If so, don't: doing that
> requires byte-compiling all the Lisp files, which would be difficult
> given your problems.

I did build from today's git. After setting libsystemd to off
OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
the build was successful: all three built executables: temacs, bootstrap-emacs,
emacs works fine.

Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
Dumping under the name emacs
45802 pure bytes used
mv -f emacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[2]: Entering directory '/home/srs/DEBs/emacs/GIT/emacs/lisp'
  ELC      emacs-lisp/macroexp.elc
*** Error in `../src/bootstrap-emacs': corrupted double-linked list: 0x08ecb960
***
Fatal error 6: Aborted
Backtrace:
../src/bootstrap-emacs[0x8137efc]
../src/bootstrap-emacs[0x811ff9a]
../src/bootstrap-emacs[0x8136ace]
../src/bootstrap-emacs[0x8136c1b]
../src/bootstrap-emacs[0x8136cac]
/lib/i386-gnu/libc.so.0.3(+0x3f9d2)[0x2cf99d2]
/bin/bash: line 1: 10176 Aborted                 EMACSLOADPATH=
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq
load-prefer-newer t)' -f batch-byte-compile emacs-lisp/macroexp.el

> Instead, try building an official 25.1 release tarball, then invoke
> temacs built there, and see if it works.

Will try the release 25.1 tarball next: Last time I built from an upstream
tarball it did succeed the first time and failed the second.

Message #42 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 12:06:59 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 10:50:16 +0100
> 
> I did build from today's git. After setting libsystemd to off
> OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> the build was successful: all three built executables: temacs, bootstrap-emacs,
> emacs works fine.
> 
> Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:

So you are saying that turning off libsystemd and NOT forcing
SYSTEM_MALLOC allows you to build Emacs successfully?

Also, do you understand how does libsystemd affect this?

> > Instead, try building an official 25.1 release tarball, then invoke
> > temacs built there, and see if it works.
> 
> Will try the release 25.1 tarball next: Last time I built from an upstream
> tarball it did succeed the first time and failed the second.

"The second time" here meaning what? that you modified some file and
ran "make" again?  Or does it mean something else?

Thanks.

Message #45 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 11:32:30 +0100

On Fri, 2016-11-11 at 12:06 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 10:50:16 +0100
> > 
> > I did build from today's git. After setting libsystemd to off
> > OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> > the build was successful: all three built executables: temacs, bootstrap-
> > emacs,
> > emacs works fine.
> > 
> > Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
> So you are saying that turning off libsystemd and NOT forcing
> SYSTEM_MALLOC allows you to build Emacs successfully?
> 
> Also, do you understand how does libsystemd affect this?

No, I don't. But I know that GNU/Hurd has no support for anything systemd-
related at all. And the build with it enabled failed miserably.

> > > Instead, try building an official 25.1 release tarball, then invoke
> > > temacs built there, and see if it works.
> > Will try the release 25.1 tarball next: Last time I built from an upstream
> > tarball it did succeed the first time and failed the second.
> "The second time" here meaning what? that you modified some file and
> ran "make" again?  Or does it mean something else?

I've now built the tarball and that went OK. Also after make distclean;
configure; make all was fine. 

However rebuilding the git from today crashed the box hard: Console output:
/hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
task. <and four more similar entries>. This might be a Hud bug or memory
exhaustion.

Message #48 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 12:59:14 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 11:32:30 +0100
> 
> On Fri, 2016-11-11 at 12:06 +0200, Eli Zaretskii wrote:
> > > 
> > > From: Svante Signell <svante.signell <at> gmail.com>
> > > Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> > > Date: Fri, 11 Nov 2016 10:50:16 +0100
> > > 
> > > I did build from today's git. After setting libsystemd to off
> > > OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> > > the build was successful: all three built executables: temacs, bootstrap-
> > > emacs,
> > > emacs works fine.
> > > 
> > > Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
> > So you are saying that turning off libsystemd and NOT forcing
> > SYSTEM_MALLOC allows you to build Emacs successfully?
> > 
> > Also, do you understand how does libsystemd affect this?
> 
> No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> related at all. And the build with it enabled failed miserably.
> 
> > > > Instead, try building an official 25.1 release tarball, then invoke
> > > > temacs built there, and see if it works.
> > > Will try the release 25.1 tarball next: Last time I built from an upstream
> > > tarball it did succeed the first time and failed the second.
> > "The second time" here meaning what? that you modified some file and
> > ran "make" again?  Or does it mean something else?
> 
> I've now built the tarball and that went OK. Also after make distclean;
> configure; make all was fine. 
> 
> However rebuilding the git from today crashed the box hard: Console output:
> /hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
> exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
> task. <and four more similar entries>. This might be a Hud bug or memory
> exhaustion.

Thanks, so what remains to be addressed in this bug report, before we
declare it done?

Message #51 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 13:03:22 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 11:32:30 +0100
> 
> > Also, do you understand how does libsystemd affect this?
> 
> No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> related at all. And the build with it enabled failed miserably.

Evidently, you do have libsystemd on your machine, because the
configure script detects its presence (by calling pkg-config), and
also the link step of the build succeeds to link against libsystemd.
What is the story here?

Message #54 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 12:18:33 +0100

On Fri, 2016-11-11 at 12:59 +0200, Eli Zaretskii wrote:

> > However rebuilding the git from today crashed the box hard: Console output:
> > /hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
> > exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
> > task. <and four more similar entries>. This might be a Hurd bug or memory
> > exhaustion.
> Thanks, so what remains to be addressed in this bug report, before we
> declare it done?

Well, rebooting, checking disks and building again freeze the box hard, no
successful build this time :(
Dumping under the name emacs
5883168 of 16777216 static heap bytes used
<box freeze>

This is the behaviour for every build since 24.5. So I don't think this bug can
be closed. There must be ways to build emacs without crashing the gnumach
kernel/ext2 filesystem!

Are you going to remove the obscure unxec stuff anytime soon? And use system
malloc functions from glibc instead of home-brewn versions?

Message #57 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 12:33:25 +0100

On Fri, 2016-11-11 at 13:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 11:32:30 +0100
> > 
> > > 
> > > Also, do you understand how does libsystemd affect this?
> > No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> > related at all. And the build with it enabled failed miserably.
> Evidently, you do have libsystemd on your machine, because the
> configure script detects its presence (by calling pkg-config), and
> also the link step of the build succeeds to link against libsystemd.
> What is the story here?

There is a dummy systemd development library installed, to enable build of some
packages:
ii  libsystemd-dev    222-1         hurd-i386     Dummy systemd utility library

This is a Debian construct.

#> dpkg -s libsystemd-dev
Package: libsystemd-dev
Status: install ok installed
Priority: extra
Section: oldlibs
Installed-Size: 27
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers <at> lists.alioth.deb
ian.org>
Architecture: hurd-i386
Source: libsystemd-dummy
Version: 222-1
Description: Dummy systemd utility library
 This package provides a dummy version of the libsystemd-dev
 package for the architectures which lack an implementation of the library.

#> dpkg -L libsystemd-dev
/.
/usr
/usr/include
/usr/include/systemd
/usr/include/systemd/sd-daemon.h
/usr/lib
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libsystemd.pc
/usr/share
/usr/share/doc
/usr/share/doc/libsystemd-dev
/usr/share/doc/libsystemd-dev/copyright
/usr/share/doc/libsystemd-dev/changelog.Debian.gz
/usr/lib/pkgconfig/libsystemd-daemon.pc

Maybe you should have some better way of detecting libsystemd presence?
man pkg-config:
pkg-config retrieves information about packages from special metadata files.
These files are named after the package, and has a .pc extension.

On the GNU/Hurd system no libsystemd* library exist!

See above:
/usr/lib/pkgconfig/libsystemd.pc
/usr/lib/pkgconfig/libsystemd-daemon.pc

I don't really understand why a GNU project adds support for the systemd
disaster. Take a look at Guix, they chose another way out. Additionally we have
Devuan and their downstream releases.

Message #60 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 16:03:29 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 12:18:33 +0100
> 
> Well, rebooting, checking disks and building again freeze the box hard, no
> successful build this time :(
> Dumping under the name emacs
> 5883168 of 16777216 static heap bytes used
> <box freeze>

Does /var/log/messages (or wherever that is on Hurd) have anything
interesting at that point?

> Are you going to remove the obscure unxec stuff anytime soon? And use system
> malloc functions from glibc instead of home-brewn versions?

We are not yet sure this is due to unexec.  That's why I asked you to
try to run temacs.  If temacs runs well and has no issues, then yes,
unexec is the most likely culprit.

I do wonder what happened in 24.5 that Emacs became unbuildable on
Hurd.  Can you still build 24.4 on your current system?  If so,
perhaps look at the diffs between unexelf.c in 24.4 and the current
version, and try to figure out what changes there cause the failure on
Hurd.

Thanks.

Message #63 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 16:06:25 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 12:33:25 +0100
> 
> > Evidently, you do have libsystemd on your machine, because the
> > configure script detects its presence (by calling pkg-config), and
> > also the link step of the build succeeds to link against libsystemd.
> > What is the story here?
> 
> There is a dummy systemd development library installed, to enable build of some
> packages:
> ii  libsystemd-dev    222-1         hurd-i386     Dummy systemd utility library
> 
> This is a Debian construct.
> 
> #> dpkg -s libsystemd-dev
> Package: libsystemd-dev
> Status: install ok installed
> Priority: extra
> Section: oldlibs
> Installed-Size: 27
> Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers <at> lists.alioth.deb
> ian.org>
> Architecture: hurd-i386
> Source: libsystemd-dummy
> Version: 222-1
> Description: Dummy systemd utility library
>  This package provides a dummy version of the libsystemd-dev
>  package for the architectures which lack an implementation of the library.
> 
> #> dpkg -L libsystemd-dev
> /.
> /usr
> /usr/include
> /usr/include/systemd
> /usr/include/systemd/sd-daemon.h
> /usr/lib
> /usr/lib/pkgconfig
> /usr/lib/pkgconfig/libsystemd.pc
> /usr/share
> /usr/share/doc
> /usr/share/doc/libsystemd-dev
> /usr/share/doc/libsystemd-dev/copyright
> /usr/share/doc/libsystemd-dev/changelog.Debian.gz
> /usr/lib/pkgconfig/libsystemd-daemon.pc
> 
> Maybe you should have some better way of detecting libsystemd presence?

If you can suggest a way to detect this dummy version, we can
incorporate it in the configure script.

> I don't really understand why a GNU project adds support for the systemd
> disaster.

One man's disaster is another man's most wanted feature.  The world is
divided wrt systemd, and Emacs as a project doesn't have a firm stand
about that.

Thanks.

Message #66 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 16:04:45 +0100

On Fri, 2016-11-11 at 16:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 12:18:33 +0100
> > 
> > Well, rebooting, checking disks and building again freeze the box hard, no
> > successful build this time :(
> > Dumping under the name emacs
> > 5883168 of 16777216 static heap bytes used
> > <box freeze>
> Does /var/log/messages (or wherever that is on Hurd) have anything
> interesting at that point?

Dunno, I'll take a look next time it happens. Probably not since nothing is even
written on the console.

> > Are you going to remove the obscure unxec stuff anytime soon? And use system
> > malloc functions from glibc instead of home-brewn versions?
> We are not yet sure this is due to unexec.  That's why I asked you to
> try to run temacs.  If temacs runs well and has no issues, then yes,
> unexec is the most likely culprit.
> 
> I do wonder what happened in 24.5 that Emacs became unbuildable on
> Hurd.  Can you still build 24.4 on your current system?  If so,
> perhaps look at the diffs between unexelf.c in 24.4 and the current
> version, and try to figure out what changes there cause the failure on
> Hurd.

Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
have to do with libc versions:
emacs 2.24-5 was successfully built with glibc 2.19
emacs 2.24-6 was FTBFS with glibc 2.22
Now we are at glibc 2.24.

All older versions I've tried gets Killed when dumping temacs.
e.g. emacs24.5-5:
/bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
bootstrap

Message #69 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 11 Nov 2016 17:33:20 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Fri, 11 Nov 2016 16:04:45 +0100
> 
> > I do wonder what happened in 24.5 that Emacs became unbuildable on
> > Hurd.  Can you still build 24.4 on your current system?  If so,
> > perhaps look at the diffs between unexelf.c in 24.4 and the current
> > version, and try to figure out what changes there cause the failure on
> > Hurd.
> 
> Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
> have to do with libc versions:
> emacs 2.24-5 was successfully built with glibc 2.19
> emacs 2.24-6 was FTBFS with glibc 2.22
> Now we are at glibc 2.24.
> 
> All older versions I've tried gets Killed when dumping temacs.
> e.g. emacs24.5-5:
> /bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
> bootstrap

That's what I thought.

Can you compare src/config.h from the old builds and the current ones?

Any idea what change(s) in glibc caused this?

Message #72 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: svante.signell <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 12 Nov 2016 10:12:53 -0800

Svante Signell wrote:
> Maybe you should have some better way of detecting libsystemd presence?

The Emacs way of using systemd should work with the dummy. libsystemd-dummy 
should define a dummy function sd_listen_fds that always returns 0, and this 
should cause Emacs to avoid using systemd. Evidently this is not working for 
you; can you investigate why? E.g., can you run Emacs under a debugger and 
verify that sd_listen_fds is the only libsystemd function it calls?

As far as the memory problems go, it appears that sometimes they happen and 
sometimes they don't, and we don't really know why. Although it could well be 
unexec, it could well be something else too. It's frustrating.

Message #75 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Mon, 21 Nov 2016 18:57:08 +0200

> Date: Fri, 11 Nov 2016 17:33:20 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> 
> > Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
> > have to do with libc versions:
> > emacs 2.24-5 was successfully built with glibc 2.19
> > emacs 2.24-6 was FTBFS with glibc 2.22
> > Now we are at glibc 2.24.
> > 
> > All older versions I've tried gets Killed when dumping temacs.
> > e.g. emacs24.5-5:
> > /bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
> > bootstrap
> 
> That's what I thought.
> 
> Can you compare src/config.h from the old builds and the current ones?
> 
> Any idea what change(s) in glibc caused this?

Ping!  Any news on this?

Emacs 25.2 will begin pretest soon, and it would be nice to at least
know the situation on Hurd with it, if not have a solution.

TIA

Message #78 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Tue, 29 Nov 2016 16:14:03 -0500

[Message part 1 (text/plain, inline)]

Maybe I misunderstood this post?  I…

* …downloaded the GNU Hurd image at https://people.debian.org/~sthibault/hurd-i386/README

* …connected to the qemu VM through SSH:

  kvm -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic -drive file=debian-hurd-20160824.img,cache=writeback -m 1G

* …installed emacs' dependencies:

  $ apt install libmagickwand-dev libgtk-3-dev libxpm-dev libjpeg-dev libgif-dev libtiff-dev libgconf2-dev librsvg2-dev libxml2-dev libfreetype6-dev libm17n-dev libotf-dev libsystemd-dev libncurses-dev

* …downloaded emacs' pretest (this was cool)

  cp /ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-25.1.90.tar.xz ./
  tar xf emacs-25.1.90.tar.xz

* …configured

  cd emacs-25.1.90
  ./configure --without-makeinfo

* …compiled

  make -j4

* …started Emacs and ran eww; browsed to gnu.org.

It all worked.  Did I miss something?

Clément.

On 2016-11-04 16:17, Svante Signell wrote:
> Hello,
> 
> In order for you to try out the FTBFS problems of emacs24/25 on
> GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
> do that would be to read:
> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
> or using a pre-installed image: (3GiB)
> tinyurl.com/6dyly5d
> containing debian-hurd.img.tar.gz

[signature.asc (application/pgp-signature, attachment)]

Message #81 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: 24857 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org,
 Clément Pit--Claudel <clement.pit <at> gmail.com>
Subject: Re: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 01 Dec 2016 15:52:54 +0100

Hi Clement (and the ML),

I just saw your mail to this bug. Unfortunately I did not get that mail. Do I
have to subscribe to get them?

Anyway, you were just lucky. Try to build it a second time, or even better build
the debian package. Latest version now is 2.25.1+1-3. You'll see the same
problems as me (and the hurd build daemons).

Thanks for trying Hurd out.

On Fri, 2016-11-04 at 21:17 +0100, Svante Signell wrote:
> Hello,
> 
> In order for you to try out the FTBFS problems of emacs24/25 on
> GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
> do that would be to read:
> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
> or using a pre-installed image: (3GiB)
> tinyurl.com/6dyly5d
> containing debian-hurd.img.tar.gz

Message #86 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: svante.signell <at> gmail.com, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 1 Dec 2016 11:48:21 -0500

[Message part 1 (text/plain, inline)]

Hi Svante,

Sorry; I wrote back to the bug list, and forgot to CC you (debbugs only forwards responses to the original author).

I seem to be lucky: re-running the series of steps that I posted in a clean Hurd VM seems to work reliably; I wasn't sure what you meant by "try to build it a second time", so I ran "make clean; make -j4", 5 times in a row, and it still worked fine on all attempts:

    In GNU Emacs 25.1.90.1 (i686-unknown-gnu0.8, GTK+ Version 3.22.3)
     of 2016-12-01 built on debian
    System Description:     Debian GNU buildd-unstable (sid)

    Configured using:
     'configure --without-makeinfo'

    Configured features:
    XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GCONF GSETTINGS NOTIFY
    LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

I'm happy to try out Debian packages, but I'm not entirely sure how; should I just download the archives from https://packages.debian.org/unstable/emacs25 ? Do I need to build emacs25-bin-common separately?

Thanks,
Clément.

On 2016-12-01 09:52, Svante Signell wrote:
> Hi Clement (and the ML),
> 
> I just saw your mail to this bug. Unfortunately I did not get that mail. Do I
> have to subscribe to get them?
> 
> Anyway, you were just lucky. Try to build it a second time, or even better build
> the debian package. Latest version now is 2.25.1+1-3. You'll see the same
> problems as me (and the hurd build daemons).
> 
> Thanks for trying Hurd out.
> 
> On Fri, 2016-11-04 at 21:17 +0100, Svante Signell wrote:
>> Hello,
>>
>> In order for you to try out the FTBFS problems of emacs24/25 on
>> GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
>> do that would be to read:
>> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
>> or using a pre-installed image: (3GiB)
>> tinyurl.com/6dyly5d
>> containing debian-hurd.img.tar.gz
> 
> 
> 
> 

[signature.asc (application/pgp-signature, attachment)]

Message #89 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>, 
 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 01 Dec 2016 18:29:22 +0100

On Thu, 2016-12-01 at 11:48 -0500, Clément Pit--Claudel wrote:
> Hi Svante,
> 
> Sorry; I wrote back to the bug list, and forgot to CC you (debbugs only
> forwards responses to the original author).
> 
> I seem to be lucky: re-running the series of steps that I posted in a clean
> Hurd VM seems to work reliably; I wasn't sure what you meant by "try to build
> it a second time", so I ran "make clean; make -j4", 5 times in a row, and it
> still worked fine on all attempts:
> 
>     In GNU Emacs 25.1.90.1 (i686-unknown-gnu0.8, GTK+ Version 3.22.3)
>      of 2016-12-01 built on debian
>     System Description:     Debian GNU buildd-unstable (sid)
> 
>     Configured using:
>      'configure --without-makeinfo'
> 
>     Configured features:
>     XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GCONF GSETTINGS NOTIFY
>     LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Nice, I never succeeded to do that. Are you building with the latest
glibc/hurd/gnumach packages? Seem like the successful old package builds are not
successful any more. :(

<as root>
apt-get update
apt-get upgrade or
apt-get dist-upgrade

> I'm happy to try out Debian packages, but I'm not entirely sure how; should I
> just download the archives from https://packages.debian.org/unstable/emacs25 ?
> Do I need to build emacs25-bin-common separately?

You just do:
<as root>
apt-get build-dep emacs25
<as user>
apt-get source emacs25
cd emacs25-25.1+1
dpkg-buildpackage -b 2>&1 | tee ../build.log

Message #92 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 01 Dec 2016 14:25:34 -0500

I believe the Debian packages do the equivalent of a bootstrap build,
is that right? Ie, delete and rebuild all the elc files (and more)?
At least, that is what I see in eg

https://buildd.debian.org/status/fetch.php?pkg=emacs25&arch=i386&ver=25.1%2B1-3&stamp=1480558507

This has always bugged me somewhat, since it means they aren't
really building the release tarfiles that Emacs ships, but something
more akin to a git snapshot. Should in theory be the same, but it
means the Debian builds are doing extra work and more likely to
encounter build problems than some other distros.

Message #95 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Clément Pit--Claudel <clement.pit <at> gmail.com>,
 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 01 Dec 2016 23:09:39 +0100

On Thu, 2016-12-01 at 14:25 -0500, Glenn Morris wrote:
> I believe the Debian packages do the equivalent of a bootstrap build,
> is that right? Ie, delete and rebuild all the elc files (and more)?

Yes, that's what they do. Previously rebuilding all the .elc files made the Hurd
build to FTBFS, but now it is mainly the temacs executable causing problems.

> At least, that is what I see in eg
> 
> https://buildd.debian.org/status/fetch.php?pkg=emacs25&arch=i386&ver=25.1%2B1-
> 3&stamp=1480558507
> 
> This has always bugged me somewhat, since it means they aren't
> really building the release tarfiles that Emacs ships, but something
> more akin to a git snapshot. Should in theory be the same, but it
> means the Debian builds are doing extra work and more likely to
> encounter build problems than some other distros.

Yes, see above. And the builds are made for three targets: nox, x and lucid, the
whole tree is copied tree times for build.

Message #98 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: emacs-devel <at> gnu.org
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 02 Dec 2016 11:35:49 +0100

On Wed, 2016-11-02 at 16:51 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> > > 
> > > From: Svante Signell <svante.signell <at> gmail.com>
> > > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > > 
> > > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > > Compiling Debian versions almost always fail. Moslty the build fails with
> > > temacs
> > > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > > modern
> > > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> > > 
> > > Do anybody of you have an idea on how to solve this problem?
> > My suggestion is to run the failing temacs command line under GDB and
> > see where it crashes.
> 
> Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
> indicated in that file.

<follow ups to the bug #24857 showed an inability to allocate memory>

> > The best way to communicate this information is to file a bug report,
> > using "M-x report-emacs-bug RET" (in some version of Emacs you have
> > that is operable; if not, just email the details to
> > bug-gnu-emacs <at> gnu.org).
> 
> A bug was already filed by
> Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24857

Hi, again. Irrespective of the discussion ongoing of a C or Lisp implementation
of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

Message #101 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: svante.signell <at> gmail.com, emacs-devel <at> gnu.org
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 2 Dec 2016 16:02:26 -0800

On 12/02/2016 02:35 AM, Svante Signell wrote:
> Irrespective of the discussion ongoing of a C or Lisp implementation
> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

I doubt it. However, Daniel indicated here:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html

that he would create a branch for that patch this weekend, and I suggest 
trying that branch. As a Savannah upgrade is in progress, you may have 
to wait before it's available; see:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

Message #104 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, emacs-devel <at> gnu.org, dancol <at> dancol.org
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 07 Dec 2016 23:40:22 +0100

On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
> On 12/02/2016 02:35 AM, Svante Signell wrote:
> > Irrespective of the discussion ongoing of a C or Lisp implementation
> > of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
> > still
> > apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
> 
> I doubt it. However, Daniel indicated here:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
> 
> that he would create a branch for that patch this weekend, and I suggest 
> trying that branch. As a Savannah upgrade is in progress, you may have 
> to wait before it's available; see:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

Daniel,

What is the status of your branch containing the portable dumper? Nothing so far
in http://git.savannah.gnu.org/cgit/emacs.git
Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
28 2015, more than a year ago :(

Message #107 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: svante.signell <at> gmail.com, Paul Eggert <eggert <at> cs.ucla.edu>,
 emacs-devel <at> gnu.org
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Wed, 7 Dec 2016 17:15:29 -0800

On 12/07/2016 02:40 PM, Svante Signell wrote:
> On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
>> On 12/02/2016 02:35 AM, Svante Signell wrote:
>>> Irrespective of the discussion ongoing of a C or Lisp implementation
>>> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
>>> still
>>> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
>>
>> I doubt it. However, Daniel indicated here:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
>>
>> that he would create a branch for that patch this weekend, and I suggest
>> trying that branch. As a Savannah upgrade is in progress, you may have
>> to wait before it's available; see:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html
>
> Daniel,
>
> What is the status of your branch containing the portable dumper? Nothing so far
> in http://git.savannah.gnu.org/cgit/emacs.git
> Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
> as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
> 28 2015, more than a year ago :(
>

Sorry for the delay --- I've been a bit held up in some personal 
business. I recently fixed some bugs in the unexec-mode-in-pdumper-build 
case, and I want to get end-to-end installation (loading the dump after 
'make install') working before I push the branch. Shouldn't be too long.

Message #110 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Clément
 Pit--Claudel <clement.pit <at> gmail.com>
Cc: 24857 <at> debbugs.gnu.org, 25081 <at> debbugs.gnu.org
Subject: Re: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 08 Dec 2016 10:12:03 +0100

(Adding #24857 and Clement to the recipients list.)

On Wed, 2016-12-07 at 16:45 -0800, Paul Eggert wrote:
> On 12/07/2016 03:00 PM, Svante Signell wrote:
> > Hi, adding emacs-devel to the recipients
> 
> I'm not sure emacs-devel is worth bothering over all the details here, 
> so I'll drop it from the CC: list for now. We can send emacs-devel a 
> summary later as needed.

OK!

> > 
> > I normally use:
> > qemu-system-x86_64 -enable-kvm -m 2048 -net nic,model=rtl8139 -net
> > user,hostfwd=tcp::<port>-:22 -drive
> > cache=writeback,index=0,media=disk,file=<whatever>.img
> 
> Thanks, that wasn't obvious, I used that. Perhaps make it part of the 
> brief HOWTO?

I'll propose that to people who can make these changes.

> > This is expected, since qemu does not know exactly in what format the file
> > is
> > in. Maybe just ignore that warning for now? I (and others) do.
> > 
> 
> I'm a fan of fixing warnings; otherwise I find that I stop paying 
> attention to them. Surely there's some option I can give to qemu to 
> suppress the warning, and that could be part of the HOWTO?

I still haven't bothered to find out which option to pass to qemu. Maybe its
useful to find out and add it to the HOWTO too.

> > It might be easier to use the debian tools: 
> 
> I assume these commands need to be run as root on the guest.
> 
> > apt-get update
> > apt-get dist-upgrade
> 
> These work, thanks. The latter takes a looong time. Perhaps this should 
> be written down too.

Noted!

> > apt-get build-dep emacs24/emacs25

I was too brief here:
apt-get build-dep emacs24
apt-get build-dep emacs25

> This fails with 'Reading package lists... Done
> E: Unable to find a source package for emacs24/emacs25'. I forged ahead 
> by running just "apt-get build-dep emacs25" but that failed with:
> 
> E: Failed to fetch 
> http://httpredir.debian.org/debian/pool/main/libx/libxdmcp/libxdmcp-dev_1.1.2-
> 1.1_hurd-i386.deb 
> Error reading from server. Remote end closed connection [IP: 
> 5.153.231.35 80]
> E: Unable to fetch some archives, maybe run apt-get update or try with 
> --fix-missing?
> E: Failed to process build dependencies
> 
> I tried running "apt-get build-dep emacs25" again. This time it finished.

Probably just a network glitch.

> > apt-get source emacs24/emacs25

As above:
apt-get source emacs24
apt-get source emacs25

> I don't want to do this, as I want to build from the master branch. I 
> did that, with plain 'configure; make'.

So you built from the tarball, right?

> Emacs built and eventually attempted to dump itself, and while it was 
> doing so, the operating system crashed. When I attempted to reboot, fsck 
> failed. I ran fsck -y by hand (took a while) and rebooted. When the OS 
> came back up, temacs was size-0, so I removed it and ran 'make' again. 
> This time it worked, in the sense that I can now run Emacs in a tty window.

I've also successfully built different emacs tarballs and git repos. The problem
is building again, or worse: to build a Debian package, which copies the whole
emacs tree into three different build directories: build-x, build-nox, build-
lucid, as well as rebuilding all *.elc files. See bug #24857, especially
comments #86,89,92,95 of that bug, for more info where Clément Pit--Claudel did
the same as you.

> So, it sounds like we can declare victory against this bug, at least for 
> the master branch. At least, it worked for me, if you ignore the OS 
> crashing during the build. Possibly the crash was because I didn't 
> reboot after the 'apt-get dist-upgrade' (you didn't say to reboot, so I 
> didn't....).

Sorry, I should have added <reboot> after dist-upgrade especially when
gnumach/hurd/glibc are updated.

Message #115 received at 24857-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: svante.signell <at> gmail.com, Clément Pit--Claudel
 <clement.pit <at> gmail.com>
Cc: 25081-done <at> debbugs.gnu.org, 24857-done <at> debbugs.gnu.org
Subject: Re: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 8 Dec 2016 07:50:16 -0800

On 12/08/2016 01:12 AM, Svante Signell wrote:
> I've also successfully built different emacs tarballs and git repos. 
> The problem is building again, or worse: to build a Debian package, 
> which copies the whole emacs tree into three different build 
> directories: build-x, build-nox, build-lucid, as well as rebuilding 
> all *.elc files. See bug #24857, especially comments #86,89,92,95 of 
> that bug, for more info where Clément Pit--Claudel did the same as you.

OK, but that appears to be a problem with the Debian build procedure, 
not with Emacs per se.

>> So, it sounds like we can declare victory against this bug, at least for
>> the master branch. At least, it worked for me, if you ignore the OS
>> crashing during the build. Possibly the crash was because I didn't
>> reboot after the 'apt-get dist-upgrade' (you didn't say to reboot, so I
>> didn't....).
> Sorry, I should have added <reboot> after dist-upgrade especially when
> gnumach/hurd/glibc are updated.
>
>

OK. Closing the Emacs bug report.

Message #123 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: control <at> debbugs.gnu.org
Cc: 24857 <at> debbugs.gnu.org
Subject: Sorry, reopening this bug
Date: Thu, 08 Dec 2016 18:01:31 +0100

reopen 24857
Thanks

This is what I get when configuring emacs 25.1 from the tarball:
./configure --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --wit\
h-xwidgets 2>&1	| tee ../configure-25.1.build-x1.log
make 2>&1 | tee ../make-25.1.build-x1.log
...
make[2]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/lisp'
./temacs --batch --load loadup bootstrap
Makefile:736: recipe for target 'bootstrap-emacs' failed
make[1]: *** [bootstrap-emacs] Killed
make[1]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/src'
Makefile:398: recipe for target 'src' failed
make: *** [src] Error 2

So it is not a Debian configuration problem. Maybe even the configure options
can be reduced further.

Message #128 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: control <at> debbugs.gnu.org, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Sorry, reopening this bug
Date: Thu, 08 Dec 2016 19:25:17 +0200

> From: Svante Signell <svante.signell <at> gmail.com>
> Date: Thu, 08 Dec 2016 18:01:31 +0100
> Cc: 24857 <at> debbugs.gnu.org
> 
> This is what I get when configuring emacs 25.1 from the tarball:
> ./configure --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --wit\
> h-xwidgets 2>&1	| tee ../configure-25.1.build-x1.log
> make 2>&1 | tee ../make-25.1.build-x1.log
> ...
> make[2]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/lisp'
> ./temacs --batch --load loadup bootstrap
> Makefile:736: recipe for target 'bootstrap-emacs' failed
> make[1]: *** [bootstrap-emacs] Killed
> make[1]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/src'
> Makefile:398: recipe for target 'src' failed
> make: *** [src] Error 2

Could be a ralloc.c issue?  Did you try configuring with REL_ALLOC=no?

Message #131 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: control <at> debbugs.gnu.org, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Sorry, reopening this bug
Date: Thu, 08 Dec 2016 18:34:46 +0100

On Thu, 2016-12-08 at 19:25 +0200, Eli Zaretskii wrote:
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Date: Thu, 08 Dec 2016 18:01:31 +0100
> > Cc: 24857 <at> debbugs.gnu.org
> > 
> > This is what I get when configuring emacs 25.1 from the tarball:
> > ./configure --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars --
> > wit\
> > h-xwidgets 2>&1	| tee ../configure-25.1.build-x1.log
> > make 2>&1 | tee ../make-25.1.build-x1.log
> > ...
> > make[2]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/lisp'
> > ./temacs --batch --load loadup bootstrap
> > Makefile:736: recipe for target 'bootstrap-emacs' failed
> > make[1]: *** [bootstrap-emacs] Killed
> > make[1]: Leaving directory '/home/srs/DEBs/emacs/emacs-25.1/src'
> > Makefile:398: recipe for target 'src' failed
> > make: *** [src] Error 2
> 
> Could be a ralloc.c issue?  Did you try configuring with REL_ALLOC=no?

No, I'll try and report back.

Message #138 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Svante Signell <svante.signell <at> gmail.com>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Fri, 14 Jul 2017 05:21:44 -0700

The last message I see from you on this bug report <http://bugs.gnu.org/24857> 
is that you'd try something and report back. Did that ever happen? Also, could 
you try the latest Emacs master instead? That would be more helpful than trying 
to build old versions.

Message #143 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: svante.signell <at> gmail.com, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 02 Sep 2017 16:45:35 +0300

unblock 24655 by 24857
thanks

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 14 Jul 2017 05:21:44 -0700
> Cc: 24857 <at> debbugs.gnu.org
> 
> The last message I see from you on this bug report <http://bugs.gnu.org/24857> 
> is that you'd try something and report back. Did that ever happen? Also, could 
> you try the latest Emacs master instead? That would be more helpful than trying 
> to build old versions.

And another 1.5 month later with no responses, I conclude that we
shouldn't block our releases due to this issue.

Thanks.

Message #146 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 02 Sep 2017 16:10:18 +0200

On Sat, 2017-09-02 at 16:45 +0300, Eli Zaretskii wrote:
> unblock 24655 by 24857
> thanks
> 
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Fri, 14 Jul 2017 05:21:44 -0700
> > Cc: 24857 <at> debbugs.gnu.org
> > 
> > The last message I see from you on this bug report
> > <http://bugs.gnu.org/24857> is that you'd try something and report
> > back. Did that ever happen? Also, could you try the latest Emacs
> > master instead? That would be more helpful than trying 
> > to build old versions.
> 
> And another 1.5 month later with no responses, I conclude that we
> shouldn't block our releases due to this issue.

Sorry for not responding so far. I tried the rebuild and it failed
then. After that emacs25 sometimes succeeds and sometimes fails to
build on Hurd buildds. Mostly fails unfortunately.
Examples:
 25.1+1-1: fails
 25.1+1-2: fails
 25.1+1-3: succeeds
 25.2+1-2: succeeds
 25.2+1-5: buildd hangs

So the problem persists, even if the Debian package build is now
different. I don't expect that a build from Emacs master would succeed,
if built the Debian way with three targets: build-nox, build-x and
build-lucid. When I tried with the master sources the largest problem
was when enabling X. Still the same problems with Emacs
internal/external malloc-related code exist.

Message #149 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 02 Sep 2017 17:27:24 +0300

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: 24857 <at> debbugs.gnu.org
> Date: Sat, 02 Sep 2017 16:10:18 +0200
> 
> Sorry for not responding so far. I tried the rebuild and it failed
> then. After that emacs25 sometimes succeeds and sometimes fails to
> build on Hurd buildds. Mostly fails unfortunately.
> Examples:
>  25.1+1-1: fails
>  25.1+1-2: fails
>  25.1+1-3: succeeds
>  25.2+1-2: succeeds
>  25.2+1-5: buildd hangs
> 
> So the problem persists, even if the Debian package build is now
> different. I don't expect that a build from Emacs master would succeed,
> if built the Debian way with three targets: build-nox, build-x and
> build-lucid. When I tried with the master sources the largest problem
> was when enabling X. Still the same problems with Emacs
> internal/external malloc-related code exist.

Please do try the master branch, as the memory allocation code has
changed considerably there.

Thanks.

Message #152 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Svante Signell <svante.signell <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 02 Sep 2017 16:43:20 +0200

On Sat, 2017-09-02 at 17:27 +0300, Eli Zaretskii wrote:
> > From: Svante Signell <svante.signell <at> gmail.com>
> > Cc: 24857 <at> debbugs.gnu.org
> > Date: Sat, 02 Sep 2017 16:10:18 +0200
> > 
> > Sorry for not responding so far. I tried the rebuild and it failed
> > then. After that emacs25 sometimes succeeds and sometimes fails to
> > build on Hurd buildds. Mostly fails unfortunately.
> > Examples:
> >  25.1+1-1: fails
> >  25.1+1-2: fails
> >  25.1+1-3: succeeds
> >  25.2+1-2: succeeds
> >  25.2+1-5: buildd hangs
> > 
> > So the problem persists, even if the Debian package build is now
> > different. I don't expect that a build from Emacs master would
> > succeed,
> > if built the Debian way with three targets: build-nox, build-x and
> > build-lucid. When I tried with the master sources the largest
> > problem
> > was when enabling X. Still the same problems with Emacs
> > internal/external malloc-related code exist.
> 
> Please do try the master branch, as the memory allocation code has
> changed considerably there.

Do I issue git clone etc?

Message #155 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: svante.signell <at> gmail.com
Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 02 Sep 2017 18:04:35 +0300

> From: Svante Signell <svante.signell <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu, 24857 <at> debbugs.gnu.org
> Date: Sat, 02 Sep 2017 16:43:20 +0200
> 
> > Please do try the master branch, as the memory allocation code has
> > changed considerably there.
> 
> Do I issue git clone etc?

Yes.  The instructions are here:

  https://savannah.gnu.org/git/?group=emacs

Thanks.

Message #158 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: svante.signell <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: Sat, 2 Sep 2017 11:11:23 -0700

Svante Signell wrote:
> Do I issue git clone etc?

Yes, I suggest following the instructions in CONTRIBUTE.

http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE

Message #161 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Svante Signell <svante.signell <at> gmail.com>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Wed, 01 Nov 2017 21:10:58 -0400

Svante Signell <svante.signell <at> gmail.com> writes:

> In order for you to try out the FTBFS problems of emacs24/25 on
> GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
> do that would be to read:
> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/

Hmm, was there supposed to be a README here?  There isn't any at the
moment, just a huge mess of various install (?) files.

Message #164 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Svante Signell <svante.signell <at> gmail.com>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Thu, 2 Nov 2017 13:49:11 -0400

On Fri, Nov 4, 2016 at 4:17 PM, Svante Signell <svante.signell <at> gmail.com> wrote:
> Hello,
>
> In order for you to try out the FTBFS problems of emacs24/25 on
> GNU/Hurd, maybe somebody wants to set up a VM image. The easiest way to
> do that would be to read:
> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/
> or using a pre-installed image: (3GiB)
> tinyurl.com/6dyly5d
> containing debian-hurd.img.tar.gz

I managed to install from the DVD image, and doing 'apt-get -b source
emacs25' succeeds in building all three lucid, nox, and x versions.
The process doesn't finish completely because 'make check' fails (file
notify tests didn't pass), but all three executables are functional
(although I was only able to test with -nw, because 'startx' fails
with "Unable to determine if running on a console").

Also 'apt-get install emacs25' works, so it seems the package is
building fine now, not just for me:

In GNU Emacs 25.2.2 (i686-pc-gnu, GTK+ Version 3.22.3)
 of 2017-07-11, modified by Debian built on ironforge

Message #167 received at 24857 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Svante Signell <svante.signell <at> gmail.com>
Cc: 24857 <at> debbugs.gnu.org
Subject: Re: bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?
Date: Sat, 06 Jan 2018 18:20:52 -0500

close 24857 25.2
quit

Noam Postavsky <npostavs <at> users.sourceforge.net> writes:

> I managed to install from the DVD image, and doing 'apt-get -b source
> emacs25' succeeds in building all three lucid, nox, and x versions.
> The process doesn't finish completely because 'make check' fails (file
> notify tests didn't pass), but all three executables are functional
> (although I was only able to test with -nw, because 'startx' fails
> with "Unable to determine if running on a console").
>
> Also 'apt-get install emacs25' works, so it seems the package is
> building fine now, not just for me:
>
> In GNU Emacs 25.2.2 (i686-pc-gnu, GTK+ Version 3.22.3)
>  of 2017-07-11, modified by Debian built on ironforge

I'm therefore closing the bug.

Previous Next

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