Re: Bug#35970: gnumach hangs because of Linux 2.0.36 adaptec drivers
[Guillem Jover 2005] > Can you reproduce #35970 with the latest gnumach packages? [Santiago Vila 2005] > > I don't know, and it is going to be quite difficult for me to check, because > the computer is currently running woody as a server for a lot of people... Is there any use keeping this issue open? I suspect the hardware in question has long since been retired and no-one is using the Adaptec driver any more. The upstream bug is also flagged with 'need more info', and if no-one can provide the info, it seem useless to keep the issue open. -- Happy hacking Petter Reinholdtsen
Bug#737759: hurd: Add init.d script to create /var/run/mtab
Package: hurd
Version: 1:0.5.git20140203-1
Severity: important
Tags: patch
At the moment in unstable when booting Hurd using sysvinit, df and
friends do not work because /var/run/mtab do not exist. It should point
to /proc/mounts, and this is done in /etc/hurd/rc when not booting using
sysvinit.
Instead of creating the symlink in /etc/hurd/rc, I suggest to create a
new init.d script to create this symlink, and drop the code from
/etc/hurd/rc. The following script is tested and found to be working
well. It creates /run/mtab because /var/run is a symlink to /run.
#! /bin/sh
### BEGIN INIT INFO
# Provides: hurd-mtab
# Required-Start:mountkernfs
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Create /run/mtab -> /proc/mount symlink on Hurd
### END INIT INFO
# Author: Petter Reinholdtsen
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/bin
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions
case "$1" in
start)
[ "$VERBOSE" != no ] && log_action_begin_msg "Creating /run/mtab
symlink"
ln -s /proc/mount /run/mtab
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_action_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_action_end_msg 1 ;;
esac
;;
stop|restart|force-reload|status)
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2flob2lz856@diskless.uio.no
Bug#737759: hurd: Add init.d script to create /var/run/mtab
Here is a more complete patch to implement my proposed change. It
drop the symlinking in /etc/hurd/rc and do it in an init.d scripts
instead.
--
Happy hacking
Petter Reinholdtsen
diff -ur hurd-0.5.git20140203/debian/patches/rc.patch
hurd-0.5.git20140203-pere/debian/patches/rc.patch
--- hurd-0.5.git20140203/debian/patches/rc.patch2014-02-03
22:42:04.0 +
+++ hurd-0.5.git20140203-pere/debian/patches/rc.patch 2014-02-06
08:27:47.0 +
@@ -3,9 +3,11 @@
daemons/rc.sh | 43 ---
1 file changed, 32 insertions(+), 11 deletions(-)
a/daemons/rc.sh
-+++ b/daemons/rc.sh
-@@ -19,14 +19,17 @@ then
+Index: hurd-0.5.git20140203/daemons/rc.sh
+===
+--- hurd-0.5.git20140203.orig/daemons/rc.sh2014-02-03 22:41:15.0
+
hurd-0.5.git20140203/daemons/rc.sh 2014-02-06 08:27:44.0 +
+@@ -19,14 +19,17 @@
echo Automatic boot in progress...
date
@@ -24,7 +26,7 @@
;;
# Filesystem modified, filesystem should be restarted
# Ideally we would only restart the filesystem
-@@ -85,12 +88,25 @@ if test -d /tmp; then
+@@ -90,12 +93,22 @@
fi
if test -d /var/run; then
@@ -47,13 +49,10 @@
+if ! test -e /proc/cmdline ; then
+ settrans -c /proc /hurd/procfs --compatible
+fi
-+
-+# This file must exist for e2fsck to work.
-+ln -s /proc/mounts /var/run/mtab
#echo -n restoring pty permissions...
#chmod 666 /dev/tty[pqrs]*
-@@ -104,15 +120,25 @@ touch /var/run/mtab
+@@ -109,15 +122,25 @@
chmod 664 /etc/motd
diff -ur hurd-0.5.git20140203/debian/rules
hurd-0.5.git20140203-pere/debian/rules
--- hurd-0.5.git20140203/debian/rules 2014-02-03 22:42:04.0 +
+++ hurd-0.5.git20140203-pere/debian/rules 2014-02-06 08:23:34.0
+
@@ -89,6 +89,7 @@
override_dh_installinit:
dh_installinit -phurd --name=hurd-console
+ dh_installinit -phurd --name=hurd-mtab
dh_installinit --remaining-packages
override_dh_installchangelogs:
diff -ur hurd-0.5.git20140203/debian/hurd-mtab.init
hurd-0.5.git20140203-pere/debian/hurd-mtab.init
--- /dev/null 2013-05-04 00:20:10.0 +
+++ hurd-0.5.git20140203-pere/debian/hurd-mtab.init 2014-02-06
08:23:09.0 +
@@ -0,0 +1,50 @@
+#! /bin/sh
+### BEGIN INIT INFO
+# Provides: hurd-mtab
+# Required-Start:mountkernfs
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+# Short-Description: Create /run/mtab -> /proc/mount symlink on Hurd
+### END INIT INFO
+
+# Author: Petter Reinholdtsen
+
+# PATH should only include /usr/* if it runs after the mountnfs.sh script
+PATH=/sbin:/bin
+
+# Load the VERBOSE setting and other rcS variables
+. /lib/init/vars.sh
+VERBOSE=yes
+
+# Define LSB log_* functions.
+# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
+# and status_of_proc is working.
+. /lib/lsb/init-functions
+
+#
+# Function that starts the daemon/service
+#
+do_start()
+{
+ ln -s /proc/mount /run/mtab
+}
+
+case "$1" in
+ start)
+ [ "$VERBOSE" != no ] && log_action_begin_msg "Creating /run/mtab
symlink"
+ do_start
+ case "$?" in
+ 0|1) [ "$VERBOSE" != no ] && log_action_end_msg 0 ;;
+ 2) [ "$VERBOSE" != no ] && log_action_end_msg 1 ;;
+ esac
+ ;;
+ stop|restart|force-reload|status)
+ ;;
+ *)
+ echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
+ exit 3
+ ;;
+esac
+
+:
Bug#737759: hurd: Add init.d script to create /var/run/mtab
[Samuel Thibault] > Well, I'm not sure we want to add an init script just for this while > simply building coreutils will fix the issue (and we have to get it > built at some point anyway). When I mentioned on IRC that it could > be brownpaperbag-fixed, I was thinking about just a one-liner in > some existing init script. Is it enough fixing coreutils? The comment in /etc/hurd/rc indicate that e2fsck also need a rebuild, and the fact that the code was there make me believe that tools on hurd are going to expect /var/run/mtab instead of /etc/mtab. /var/run/mtab and /run/mtab is in my opinion is a better location for the file, so starting from scratch I would have wanted Linux to keep it there too. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206115813.gf6...@diskless.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
Package: hurd Version: 1:0.5.git20140320-1 Severity: grave I am unable to upgrade my virtual test hurd machine because it hang completely during apt-get upgrade. I have to "cut the power" on the machine and reboot it to try to get going. After the boot, the machine hang again during boot. As the file system is messed up, I run fsck outside the virtual machine like this to fix it: kpartx -sa debian-hurd-20140211.img fsck -f -y /dev/mapper/loop0p1 kpartx -d debian-hurd-20140211.img To reproduce this, I start by downloading the debian-hurd-20130504.img.tar.gz file, unpack the image and boot it using virt-manager. In the booted image, I run 'dhclient /dev/eth0' to get a IP address, 'apt-get update' to fetch the package lists, install etckeeper to track changes in /etc, edit /etc/apt/sources.list to drop the CD source, and next try 'apt-get upgrade'. After a while the upgrade hang and the machine uses lots of CPU. To try to figure out exactly what went wrong, I tried instead of 'apt-get upgrade' to use apt-get --download-only upgrade' and then used dpkg -i on individual debs to see if I could find the trigger. Upgrading the hurd package caused the hang after the unpack message is printed. Run these commands on a fresh image to reproduce it: dhclient /dev/eth0 apt-get update apt-get install -y etckeeper vi /etc/apt/get/sources.list dpkg -i /var/cache/apt/packages/hurd_*.deb As far as I know, etckeeper is not vital to reproduce it, but mentioning it here in the hope that you consider installing it by default. :) I'm setting severity to grave, as this make the package useless and can cause data loss when I have to power off the machine and leave the file system in an inconsistent state. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2fla9chwd9q@diskless.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
I forgot to mention that I am using Wheezy on the host, so the virt-manager/kvm/qemu versions are from Wheezy. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323085525.gh30...@ulrik.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
I got some help from gg0 on IRC to debug this issue. He proposed to upgrade everything except hurd first, and this worked: apt-get update apt-mark hold hurd apt-get dist-upgrade apt-mark unhold hurd This reduced the amount of packages to upgrade to the minimum. Upgrading using apt-get dist-upgrade now also hung, but it was a lot quicker to test as I had snapshotted the freshly upgraded system. We tried adding a serial console (adding GRUB_CMDLINE_GNUMACH="console=com0" in /etc/default/grub and running update-grub) and see if anything showed up there. No messages showed up in the serial console when the system got stuck. I did however notice that the hang caused the machine to no longer respond to ping, and my ssh connections would stop working too. Last, I tried to upgrade over ssh (instead of the console I had tried initially, and then I got a bit more text before the machine went dead: root@debian:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be REMOVED: libdb5.1 The following NEW packages will be installed: login The following packages will be upgraded: db5.1-util hurd hurd-dev hurd-libs0.3 4 upgraded, 1 newly installed, 1 to remove and 0 not upgraded. Need to get 1351 kB/6117 kB of archives. After this operation, 2894 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://cdn.debian.net/debian/ sid/main login hurd-i386 1:4.1.5.1-1.1 [695 kB] Get:2 http://cdn.debian.net/debian/ sid/main db5.1-util hurd-i386 5.1.29-8 [656 kB] Fetched 1351 kB in 7s (177 kB/s) Reading changelogs... Done (Reading database ... 38608 files and directories currently installed.) Preparing to unpack .../hurd-dev_1%3a0.5.git20140320-1_hurd-i386.deb ... Unpacking hurd-dev (1:0.5.git20140320-1) over (1:0.5.git20140203-1) ... Preparing to unpack .../hurd-libs0.3_1%3a0.5.git20140320-1_hurd-i386.deb ... Unpacking hurd-libs0.3:hurd-i386 (1:0.5.git20140320-1) over (1:0.5.git20140203-1) ... Setting up hurd-libs0.3:hurd-i386 (1:0.5.git20140320-1) ... Processing triggers for libc-bin (2.18-3) ... (Reading database ... 38608 files and directories currently installed.) Preparing to unpack .../hurd_1%3a0.5.git20140320-1_hurd-i386.deb ... Unpacking hurd (1:0.5.git20140320-1) over (1:0.5.git20140203-1) ... Setting up hurd (1:0.5.git20140320-1) ... Installing new version of config file /etc/hurd/rc ... Installing new version of config file /etc/init.d/hurd-console ... Not sure how to continue, as gg0 is not able to reproduce the problem, but at least here it happen every time. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323195538.gf8...@ulrik.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
I managed to upgrade the hurd packages by building my own where the hurd-console init.d script no longer is started on package installation or stopped on package removal, and also commented out the hurd-console block in /var/lib/dpkg/info/hurd.prerm: root@debian:~# cat /var/lib/dpkg/info/hurd.prerm #!/bin/sh set -e if [ "$1" = remove ]; then update-alternatives --remove random /dev/random-hurd fi # Automatically added by dh_installinit #if [ -x "/etc/init.d/hurd-console" ]; then # invoke-rc.d hurd-console stop || exit $? #fi # End automatically added section root@debian:~# This made sure the console was not touched during upgrade, and now I was able to install the packages. But after boot, the machine got stuck trying to run the scripts in rc2.d/, and I was no longer able to log into the machine. So the "fix" is most likely not the correct one. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325092933.gp8...@ulrik.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
[Samuel Thibault] > To circumvent the issue, just disable the console completely in > /etc/defaults/hurd-console That worked too. After disabling it, rebooting, upgrading everything via ssh (worked just fine) and rebooting, I was still able to log in via ssh. Enabling hurd-console and rebooting caused the system to hang during boot in rc2.d again. :( -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325095210.gq8...@ulrik.uio.no
Bug#742392: hurd: Hang during apt-get upgrade from last image release
[Samuel Thibault] > Peter, could you try to put > http://dept-info.labri.fr/~thibault/tmp/vga.so.0.3 > into /usr/lib/hurd/console/ and start your Hurd console? That one does > work for me and on Richard's VMs. I tested, and it solved the hang for me too. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140326062813.gw8...@ulrik.uio.no
Bug#737759: hurd: Add init.d script to create /var/run/mtab
Is this issue still relevant, or should this bug be closed? If hurd do not want or need mtab, but instead patch tools to not need it, I believe it should be closed. -- Happy hacking Petter Reinholdtsen
Re: Debian Buster release to partially drop non-systemd support
[Benda Xu] > I was about to reply to this thread, but you have completely expressed > what I want to say: > > 1. systemd-shim is not necessary, even for DEs (except GNOME3). > 2. sysvinit-core is very stable and do not need new uploads. Thank you for expressing so well the cause of the fate for sysvinit in Debian. It seem clear its proponents believe everything is OK and no effort is needed to save sysvinit. If this continues, sysvinit in Debian will continue to rot and end up being removed. I know from maintaining the sysvinit set of packages that it require work to maintain them. There are hundreds of open bugs against the sysvinit packages in Debian already. -- Vennlig hilsen Petter Reinholdtsen
Re: Debian Buster release to partially drop non-systemd support
[Martin Pitt] > It's not only that. The sysvinit package *itself* doesn't actually do > much really. That's not to downplay your past involvement there of > course (e. g. developing insserv alone was a huge task), but the > *real* maintenance is in all the packages that *ship* SysV init > scripts. Sure. But for the common case, it do not need to be much, when using the /lib/init/init-d-script mechanism. Of the around 1000 packages with init.d scripts when I kept track of such things, around 900 did not need much logic at all to start its daemon. And as I wrote five years ago[1], the init.d script often do not have to be longer than this: #!/lib/init/init-d-script ### BEGIN INIT INFO # Provides: rsyslog # Required-Start:$remote_fs $time # Required-Stop: umountnfs $time # X-Stop-After: sendsigs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: enhanced syslogd # Description: Rsyslog is an enhanced multi-threaded syslogd. #It is quite compatible to stock sysklogd and can be #used as a drop-in replacement. ### END INIT INFO DESC="enhanced syslogd" DAEMON=/usr/sbin/rsyslogd [1] http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html > > SysV init leaves all the really hard problems to these, as it cannot > really do much by itself. That's a fact that people that keep yelling > "but SysV init was so easy!" keep finessing.. Absolutely. And the sysvinit boot system have lots of unsolved problems we never got around to figuring out, related to disk and other device setup. The main cause is the fact that the linux kernel is no longer predicatble and sequencial, but asynchonous. No amount of wishful thinking is going to bring is back to a world where static sequencing of boot events is going to handle all the interdependencies. To bad systemd do not work with kFreeBSD and Hurd, then we could use the same mechanism on all architectures. -- Happy hacking Petter Reinholdtsen
Re: Initscript dependency on mount
[Dmitry Bogatov] > I seek advice from previous maintainers and developers of hurd and bsd > ports, why this is so, This was implemented in sysvinit before my time, but I would guess it is implemented this way because it was implemented decades before [linux-any] appeared. :) -- Happy hacking Petter Reinholdtsen
Re: Hurd Debian-Installer: roadmap, tracking progress with the BTS
[Jérémie Koenig] > I would also welcome suggestions about using the BTS to track my > progress. If I understand correctly, I could: > * track the bugs which I work on with a usertag > * pre-file wishlist bugs on the packages which I will need to change > * have a toplevel "Hurd d-i" bug which is blocked by said bugs Of these, I prefer usertagging, as it provide a better list of bugs (sorted by severity and with more meta-info presented). > The kind of bugs I would be filing/tagging at first would be: > * debian-installer: native Hurd debian-installer > * busybox: Hurd support (see also #323670) > * genext2fs: support tuning the block size and creator OS (#562999) > * gnumach: initrd support > * ... > > More would be filed (especially against installer components) as I > progress. Would this be appropriate? Sound good to me. Perhaps you should get commit access if your changes proves to be good, but I leave that to your mentor and the d-i project manager to decide. :) Happy hacking, -- Petter Reinholdtsn -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flvdadxxii@login1.uio.no
Bug#1104617: boost1.88: Fixes for Hurd build problems (SA_NOCLDWAIT, cmd(), env(), exceptions)
Package: boost1.88
Version: 1.88.0-1
Severity: normal
X-Debbugs-CC: debian-hurd@lists.debian.org
User: debian-hurd@lists.debian.org
Usertags: hurd
I had a look at the build problem on Hurd reported on
https://buildd.debian.org/status/package.php?p=boost1.88 >, and
tracked down a fix.
The following patch got the package building. I am quite unsure if the
disabling of SA_NOCLDWAIT have side effects affecting boost library
clients, while the other changes seem safe enough.
diff --git a/debian/patches/1000-hurd.patch b/debian/patches/1000-hurd.patch
new file mode 100644
index ..8277502d
--- /dev/null
+++ b/debian/patches/1000-hurd.patch
@@ -0,0 +1,76 @@
+Description: Fixed build problems on GNU Hurd.
+ Disabled use of not implemented SA_NOCLDWAIT.
+ Corrected return value of fallback cmd() implementation.
+ Switched to Linux version of env() instead of trying to use MacOSX edition.
+Author: Petter Reinholdtsen
+Forwarded: no
+Last-Update: 2025-05-01
+---
+Index: boost1.88-1.88.0/libs/asio/include/boost/asio/detail/socket_types.hpp
+===
+--- boost1.88-1.88.0.orig/libs/asio/include/boost/asio/detail/socket_types.hpp
boost1.88-1.88.0/libs/asio/include/boost/asio/detail/socket_types.hpp
+@@ -414,7 +414,9 @@ const int max_iov_len = 16;
+ # endif
+ # define BOOST_ASIO_OS_DEF_SA_RESTART SA_RESTART
+ # define BOOST_ASIO_OS_DEF_SA_NOCLDSTOP SA_NOCLDSTOP
+-# define BOOST_ASIO_OS_DEF_SA_NOCLDWAIT SA_NOCLDWAIT
++# if defined(SA_NOCLDWAIT)
++# define BOOST_ASIO_OS_DEF_SA_NOCLDWAIT SA_NOCLDWAIT
++# endif /* defined(SA_NOCLDWAIT) */
+ #endif
+ const int custom_socket_option_level = 0xA510;
+ const int enable_connection_aborted_option = 1;
+Index: boost1.88-1.88.0/libs/asio/include/boost/asio/signal_set_base.hpp
+===
+--- boost1.88-1.88.0.orig/libs/asio/include/boost/asio/signal_set_base.hpp
boost1.88-1.88.0/libs/asio/include/boost/asio/signal_set_base.hpp
+@@ -65,7 +65,9 @@ public:
+ none = 0,
+ restart = BOOST_ASIO_OS_DEF(SA_RESTART),
+ no_child_stop = BOOST_ASIO_OS_DEF(SA_NOCLDSTOP),
++#if defined(SA_NOCLDWAIT)
+ no_child_wait = BOOST_ASIO_OS_DEF(SA_NOCLDWAIT),
++#endif /* defined(SA_NOCLDWAIT) */
+ dont_care = -1
+ };
+
+Index: boost1.88-1.88.0/libs/process/src/ext/cmd.cpp
+===
+--- boost1.88-1.88.0.orig/libs/process/src/ext/cmd.cpp
boost1.88-1.88.0/libs/process/src/ext/cmd.cpp
+@@ -403,10 +403,10 @@ shell cmd(boost::process::v2::pid_type p
+ }
+
+ #else
+-filesystem::path cmd(boost::process::v2::pid_type, error_code & ec)
++shell cmd(boost::process::v2::pid_type, error_code & ec)
+ {
+ BOOST_PROCESS_V2_ASSIGN_EC(ec, ENOTSUP, system_category());
+- return "";
++ return {};
+ }
+ #endif
+
+Index: boost1.88-1.88.0/libs/process/src/ext/env.cpp
+===
+--- boost1.88-1.88.0.orig/libs/process/src/ext/env.cpp
boost1.88-1.88.0/libs/process/src/ext/env.cpp
+@@ -246,7 +246,7 @@ env_view env(boost::process::v2::pid_typ
+ return {};
+ }
+
+-#elif (defined(__APPLE___) || defined(__MACH__)) && !TARGET_OS_IOS
++#elif (defined(__APPLE___) || defined(__MACH__)) && !TARGET_OS_IOS &&
!defined(__gnu_hurd__)
+
+ env_view env(boost::process::v2::pid_type pid, error_code & ec)
+ {
+@@ -309,7 +309,7 @@ env_view env(boost::process::v2::pid_typ
+ return ev;
+ }
+
+-#elif (defined(__linux__) || defined(__ANDROID__))
++#elif (defined(__linux__) || defined(__ANDROID__)) || defined(__gnu_hurd__)
+
+ env_view env(boost::process::v2::pid_type pid, error_code & ec)
+ {
diff --git a/debian/patches/series b/debian/patches/series
index 4f070ed4..53070e91 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ fix_extension.patch
30.patch
40.patch
60.patch
+1000-hurd.patch
diff --git a/debian/rules b/debian/rules
index 88c0ab15..923055bd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -150,7 +150,7 @@ JAM_OPT += pch=off
endif
# we dsable stacktrace from exceptions on some platforms due to possible
memory leaks. See #1102107
-ifneq (,$(filter $(DEB_HOST_ARCH), i386 alpha hppa m68k sh4))
+ifneq (,$(filter $(DEB_HOST_ARCH), i386 alpha hppa m68k sh4 hurd-i386))
JAM_OPT += boost.stacktrace.from_exception=off
endif
--
Happy hacking
Petter Reinholdtsen
