bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

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

From: Svante Signell <svante.signell@gmail.com>
To: emacs-devel@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 :)

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 2 Nov 2016 08:20:59 -0700
> Cc: Svante Signell <svante.signell@gmail.com>
> 
> [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]
> 
> From: Svante Signell <svante.signell@gmail.com>
> To: emacs-devel@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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
> > 
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Wed, 2 Nov 2016 08:20:59 -0700
> > Cc: Svante Signell <svante.signell@gmail.com>
> > 
> > [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg000
> > 55.html]
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > To: emacs-devel@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.

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

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

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

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

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 09:48 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 12:06 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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@gmail.com>
> > > Cc: eggert@cs.ucla.edu, 24857@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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 13:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@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@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 16:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@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

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> Date: Fri, 11 Nov 2016 17:33:20 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, 24857@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

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1314 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

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

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]

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
> 
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

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

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Glenn Morris]

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.

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

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.

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Paul Eggert]

I tried to get a qemu VM running for GNU/Hurd on my platform (Fedora 24 
x86-64), and did not succeed.

The instructions in 
https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/ talk 
about running "apt-get install qemu-kvm". Obviously this won't work on 
Fedora. I'm not a big fan of virtualization to be honest, but after 
messing with it a bit I found that the following Unix shell commands 
sort-of worked:

sudo dnf install @virtualization

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

The latter command outputs the somewhat scary-looking:

WARNING: Image format was not specified for 'debian-hurd-20160824.img' 
and probing guessed raw.
          Automatically detecting the format is dangerous for raw 
images, write operations on block 0 will be restricted.
          Specify the 'raw' format explicitly to remove the restrictions.

and gives me a screen where I can log in as root and type the command 
"password demo" to change the password, and then from another terminal 
window I can run "ssh demo@localhost -p 2222" to login to GNU/Hurd, and 
after creating .ssh/authorized_keys with my key, I can run "scp -P 2222 
emacs.tar.gz demo@localhost:". (This "emacs.tar.gz" was created by 
running "make dist" followed by "tar cf emacs.tar.gz emacs-26.0.50" on 
my development machine, in the master branch.) Although all this is 
obvious if you're a VM expert and like messing with VMs, it's not 
written down in the instructions. (Plus, I hate having to type 
Ctrl-Alt-G all the time while configuring the VM -- that's not 
documented either.)

On GNU/Hurd I tried several ways to configure Emacs. None worked. I made 
the most progess with this:

tar xf emacs.tar.gz

cd emacs-26.0.50

./configure --without-x --with-gnutls=no

This failed as follows:

checking for library containing tputs... no
configure: error: The required function 'tputs' was not found in any 
library.
The following libraries were tried (in order):
   libtinfo, libncurses, libterminfo, libtermcap, libcurses
Please try installing whichever of these libraries is most appropriate
for your system, together with its header files.
For example, a libncurses-dev(el) or similar package.

At this point I gave up. I don't know where to grab GNU/Hurd packages 
from, and anyway this process is taking more of my time than I would 
like to spend.

Perhaps you could build a GNU/Hurd image that already has all the 
packages needed to develop programs like Emacs, and then send a complete 
standalone recipe that will let someone easily reproduce the Emacs 
problem even if they dislike messing with VMs.

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

Hi, adding emacs-devel to the recipients. I hope you don't mind.

On Wed, 2016-12-07 at 14:36 -0800, Paul Eggert wrote:
> I tried to get a qemu VM running for GNU/Hurd on my platform (Fedora 24 
> x86-64), and did not succeed.
> 
> The instructions in 
> https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/ talk 
> about running "apt-get install qemu-kvm". Obviously this won't work on 
> Fedora. I'm not a big fan of virtualization to be honest, but after 
> messing with it a bit I found that the following Unix shell commands 
> sort-of worked:
> 
> sudo dnf install @virtualization
> 
> qemu-kvm -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic -drive 
> file=debian-hurd-20160824.img,cache=writeback -m 1G

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

> The latter command outputs the somewhat scary-looking:
> 
> WARNING: Image format was not specified for 'debian-hurd-20160824.img' 
> and probing guessed raw.
>           Automatically detecting the format is dangerous for raw 
> images, write operations on block 0 will be restricted.
>           Specify the 'raw' format explicitly to remove the restrictions.

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.

> and gives me a screen where I can log in as root and type the command 
> "password demo" to change the password, and then from another terminal 
> window I can run "ssh demo@localhost -p 2222" to login to GNU/Hurd, and 
> after creating .ssh/authorized_keys with my key, I can run "scp -P 2222 
> emacs.tar.gz demo@localhost:". (This "emacs.tar.gz" was created by 
> running "make dist" followed by "tar cf emacs.tar.gz emacs-26.0.50" on 
> my development machine, in the master branch.) Although all this is 
> obvious if you're a VM expert and like messing with VMs, it's not 
> written down in the instructions.

It might be easier to use the debian tools:
apt-get update
apt-get dist-upgrade
apt-get build-dep emacs24/emacs25
apt-get source emacs24/emacs25
cd emacs24-24.5+1/emacs25-25.1+1
dpkg-buildpackage -b 2>&1 | tee ../build-whatever.log
...

> (Plus, I hate having to type 
> Ctrl-Alt-G all the time while configuring the VM -- that's not 
> documented either.)

Never used that? Ctrl-Alt toggles mouse focus though.

> On GNU/Hurd I tried several ways to configure Emacs. None worked. I made 
> the most progess with this:
> 
> tar xf emacs.tar.gz
> 
> cd emacs-26.0.50
> 
> ./configure --without-x --with-gnutls=no
> 
> This failed as follows:
> 
> checking for library containing tputs... no
> configure: error: The required function 'tputs' was not found in any 
> library.
> The following libraries were tried (in order):
>    libtinfo, libncurses, libterminfo, libtermcap, libcurses
> Please try installing whichever of these libraries is most appropriate
> for your system, together with its header files.
> For example, a libncurses-dev(el) or similar package.
> 
> At this point I gave up. I don't know where to grab GNU/Hurd packages 
> from, and anyway this process is taking more of my time than I would 
> like to spend.

See above.

> Perhaps you could build a GNU/Hurd image that already has all the 
> packages needed to develop programs like Emacs, and then send a complete 
> standalone recipe that will let someone easily reproduce the Emacs 
> problem even if they dislike messing with VMs.

Likewise.

Otherwise, you can git clone or download and build the tarball as you wrote
above. (With the dependencies installed)

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Paul Eggert]

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.

>
> 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?

> 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?

> 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.

> apt-get build-dep emacs24/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.

> apt-get source emacs24/emacs25

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

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.

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....).

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]

On 2016-12-07 17:36, Paul Eggert wrote:
> At this point I gave up. I don't know where to grab GNU/Hurd packages from, and anyway this process is taking more of my time than I would like to spend.

Hey Paul,

Maybe this helps? 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Paul Eggert]

On 12/07/2016 04:54 PM, Clément Pit--Claudel wrote:
> * …started Emacs and ran eww; browsed to gnu.org.

Wow, so it works with emacs-25 too? Thanks, that's good news. I guess we 
can close the bug report?

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Glenn Morris]

Clément Pit--Claudel wrote:

> * …compiled
>
>   make -j4

Do you have time to try deleting all the .elc files before you make,
which is closer to what the debian package build does?

bug#25081: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 445 bytes --]

On 2016-12-07 20:01, Paul Eggert wrote:
> On 12/07/2016 04:54 PM, Clément Pit--Claudel wrote:
>> * …started Emacs and ran eww; browsed to gnu.org.
> 
> Wow, so it works with emacs-25 too? Thanks, that's good news. I guess we can close the bug report?

Yes… except Svante says it doesn't work with the Debian packages :/ I couldn't test that, because apt-get dist-upgrade crashed the OS before it could complete in the provided VM.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Svante Signell]

(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.

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Paul Eggert]

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.

bug#24857: Sorry, reopening this bug

[Svante Signell]

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.

bug#24857: Sorry, reopening this bug

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Date: Thu, 08 Dec 2016 18:01:31 +0100
> Cc: 24857@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?

bug#24857: Sorry, reopening this bug

[Svante Signell]

On Thu, 2016-12-08 at 19:25 +0200, Eli Zaretskii wrote:
> > From: Svante Signell <svante.signell@gmail.com>
> > Date: Thu, 08 Dec 2016 18:01:31 +0100
> > Cc: 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

unblock 24655 by 24857
thanks

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 14 Jul 2017 05:21:44 -0700
> Cc: 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Sat, 2017-09-02 at 16:45 +0300, Eli Zaretskii wrote:
> unblock 24655 by 24857
> thanks
> 
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Fri, 14 Jul 2017 05:21:44 -0700
> > Cc: 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Sat, 2017-09-02 at 17:27 +0300, Eli Zaretskii wrote:
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: 24857@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?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@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.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

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

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Noam Postavsky]

Svante Signell <svante.signell@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.

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Noam Postavsky]

On Fri, Nov 4, 2016 at 4:17 PM, Svante Signell <svante.signell@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

bug#24857: Anybody needs help to set up a qemu VM for GNU/Hurd?

[Noam Postavsky]

close 24857 25.2
quit

Noam Postavsky <npostavs@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.